I just started up DigiKam without my photos primary external USB drive connected to find my albums vanished and all references to photos vanished in the albums, date view type window and left. After bit of investigation I realised that I had an alternate drive connected (same type and size) and thought maybe it had confused this for the photos drive then decided there were no photos anymore! I disconnected the alternate drive and connected my photos drive instead. Restarted DigiKam and suddenly the start up DB maintenance starts a process finding new photos and I see my external drive light flashing away. I can only conclude that DigiKam is confusing these drives (same manufacturer and size) and NOT relying on unique serials of each drive. They are actually named differently and this did not help. Seems like a pretty major bug.
I have not looked at it yet. If both hard drives return the same UUID (in Windows this is a volume serial number), digiKam can not do anything. I suspect that the disks were not reformatted and have the same factory image with the same volume serial number. Presumably the problem will be solved if the disks are formatted. Maik
Confirmed using CMD 'vol G:' that both drives have the same Volume Serial numbers. Although different names. I also however checked the HD serial number using CMD 'wmic diskdrive get serialnumber'and confirmed these are different. It seems then that DigiKam should be basing its identification on the HD serial and NOT the Volume serial. This behaviour should probably be corrected in the software?
If i'm not too wrong, this job is delegate to KF5::Solid API. Sound like the Windows code in this framework component is not enough. Gilles Caulier
Q : Which digiKam version do you use and Which KF5 version is used in background. Look in Help/Components Info for details. Gilles Caulier
Yes, KF5::Solid is used for that. But it is completely correct to use the volume serial number, it should/must be different. So you have to reformat one of both hard drives. Maik
As a justification, imagine they have to clone the hard drive because it starts to fail. If the hard disk serial number were used, also a completely new reading of the new disk starts. With the volume serial number the new hard disk would be accepted immediately. Maik
I am using Digikam 5.9.0 Buid date Mar 18 2018; The drives (WD Elements) were bought fresh and Bitlocked; no formatting at the time. Is it not the case that if the volume serial of external drives can be the same out of factory as these apparently were then this is not the best serial identifier to be pinning Digikam onto? Therefore it may well be a common matrix to use but I think we could do better by instead using the HD serial which apparently is more unique? I think most users would be both surprised at having separate HD's confused and messing with DigiKam database; and also surprised that a cloned HD be able to fool Digikam into thinking it was the original?
In fact a 'migrate database volume reference' tool might well be also a good idea for moving over to a backup device.
The volume serial number is used for identification: https://en.wikipedia.org/wiki/Volume_serial_number Another point is we do not have access to the hard disk serial number via the KF5::Solid API. Native extra code would be necessary. Maik
Can you reproduce the dysfunction using the last digiKam 6.0.0-beta3 just released ? https://www.digikam.org/news/2018-12-30-6.0.0-beta3_release_announcement/
Hi, Can you check if this problem still exist with last weekly bundle build of digiKam 7.0.0 available here: https://files.kde.org/digikam/ Thanks in advance Gilles Caulier
digiKam 7.0.0 stable release is now published: https://www.digikam.org/news/2020-07-19-7.0.0_release_announcement/ We need a fresh feedback on this file using this version. Thanks in advance Gilles Caulier
*** Bug 441019 has been marked as a duplicate of this bug. ***
*** Bug 441539 has been marked as a duplicate of this bug. ***
Hi Nathan and happy new year, What about this file using current 7.5.0 pre-release Windows installer available here : https://files.kde.org/digikam/ Thanks in advance Gilles Caulier
@Nathan, digiKam 8.0.0 is out. This entry still valid with this release ? Best regards Gilles Caulier
Git commit f48fc133ec0f0e5656d4d21fff52278e3d81a636 by Maik Qualmann. Committed on 09/09/2023 at 21:28. Pushed by mqualmann into branch 'master'. use a UUID file for the primary detection of the right collection - The UUID file is saved in the ".dtrash" folder as "digikam.uuid". - The "digikam.uuid" file can be deleted, the detection goes back to the previous mechanisms, it will be created again at startup. - This commit also fixes a problem when creating the DTrash folder/info directories. Related: bug 470556, bug 452299, bug 345391 FIXED-IN: 8.2.0 M +9 -1 NEWS M +1 -1 core/libs/database/collection/collectionmanager.cpp M +8 -8 core/libs/database/collection/collectionmanager_album.cpp M +117 -82 core/libs/database/collection/collectionmanager_location.cpp M +125 -3 core/libs/database/collection/collectionmanager_p.cpp M +7 -0 core/libs/database/collection/collectionmanager_p.h M +20 -9 core/libs/dtrash/dtrash.cpp https://invent.kde.org/graphics/digikam/-/commit/f48fc133ec0f0e5656d4d21fff52278e3d81a636