| Summary: | digikam didn't detect my local collection anymore after replacing internal harddisk | ||
|---|---|---|---|
| Product: | [Applications] digikam | Reporter: | Martin Steigerwald <Martin> |
| Component: | Database-Media | Assignee: | Digikam Developers <digikam-bugs-null> |
| Status: | RESOLVED UPSTREAM | ||
| Severity: | normal | CC: | caulier.gilles, mailto.mikes |
| Priority: | NOR | ||
| Version: | 1.2.0 | ||
| Target Milestone: | --- | ||
| Platform: | Debian unstable | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | 1.4.0 | |
| Sentry Crash Report: | |||
| Attachments: | solid-hardware list details | ||
|
Description
Martin Steigerwald
2010-07-05 22:05:10 UTC
This problem have been already reproted in this room. Marcel manage it already... Gilles Caulier Normally, if the harddisk is gone but a different one at the same path is now available, this one will be presented preselected as your choice. Migration could be done automatically, but we prefer to ask the user here. See bug #175923. Now to find out why it does not work for you, I'd need the output of solid-hardware list details and the AlbumsRoots table of your database, preferably prior to the changes. Is that in 1.2.0 already? There seems to be no newer package available for Debian at the moment. I still have old digikam4.db on an external eSATA disk from prior to moving to the new internal disk. I can try with that one and the old digikamrc as well. Created attachment 48623 [details]
solid-hardware list details
Well one more difference is: On the old hardisk /home was a partition, on the new it is a logical volume. I am using LVM for new installation since current kernels support write barrier through LVM as well.
> I am using LVM for new installation since current
> kernels support write barrier through LVM as well.
Here you go: Solid, or rather HAL, now fails to recognize your /home partition at all (look for StorageAccess in the solid output. Only /boot is recognized).
See the last comment in 175923. You are not the first one with such problems.
I have a similar Problem now with Digikam 4.2 after changing the filesystem from NTFS to ext4 because I thought that would be a wise decision...; Unfortunately Digikam now didnt find any pictures. The first I thought the error was that the changed name of the disk is the cause. But reverting this doesnt help. Now I see all my collections in the configuration dialogue but I cant dit them and change the path or edit irt at least. Although it's the same path but I think the UUID has changed...and I assume thats the problem ? I also didn't have a clue where digikam stores the paths to the collections. Having that path editable would be wonderful. What can I do to save my 80.000 pictures and several thousand tagged pics ? :-o Mike, yes it's UUID registered in database. But, as i tested recently, when you change disk or re-format it, UUID will be changed, and digiKam will not found the collection and will ask to relocate databse registration with new place/UUID. As Marcel said, look comment #2 Gilles Caulier Thanks Marcel and Gilles for your veeery quick response ;-) Wow... appreciate that ! The strange thing is I was asked 2 options and neither of them seems to be appropriate: it was one of my collections that could be 1.) moved to removable state or 2.) do nothing. Neither helped. So I was let alone with no collections that were displayed..; I found several similar incidents in the net and luckily I found the hint with the sqlitebrowser. I also saw the problem with HAL but I dont think anything is broken but instead Manjaro is a rolling Release and maybe it handles some things differently regarding disks : for example my disks are mounted in "/run/media/USERNAME/DISKNAME" thats different to Ubuntu.. ; But however: now its working. The good thing is that solving problems leads to more knowledge...at least sometimes ;-) |