Summary: | digikam.coredb: Core database: Album library path from config file is empty. Aborting update. | ||
---|---|---|---|
Product: | [Applications] digikam | Reporter: | arne anka <kde-bugs> |
Component: | Database-Engine | Assignee: | Digikam Developers <digikam-bugs-null> |
Status: | REPORTED --- | ||
Severity: | normal | CC: | caulier.gilles, metzpinguin |
Priority: | NOR | ||
Version: | 5.6.0 | ||
Target Milestone: | --- | ||
Platform: | Other | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: |
Description
arne anka
2018-04-12 20:34:18 UTC
Was the first start dialog displayed after starting digiKam the first time? Did you choose that the old configuration should be copied? The configuration file is now expected at a different location ($USER/.config). I think that we can not solve the problem with such an old database. The best way will be to create a new database. Maik as mentioned, I just hadn't used digikam for some time (about 6 months). there was no dialog whatsoever, just something about looking for something and the the error popup. apparently you expect some sort of user action, but I never got anything beyond the above and then the crash. "I think that we can not solve the problem with such an old database." it's not quite comprehensible for me how the database can be that old -- I use debian/sid and update almost every day. looks like some sort of communication trouble if you can make such large jumps without distributions noticing. anyway: "The best way will be to create a new database." care to elaborate? - how do I do that? - what files need to be deleted/moved? - what information will be lost? digikam should do exactly that, shouldn't it? notfiying me about the issue, offering to create a new db (and most importantly, clearly stating the consequences - what information will be lost?). from your description I still don't understand why digikam fails to solve the issue on its own. Remember: didgikam doesn't even START! whatever needs to be done is obviously more that digikam is able to handle and it doesn't tell me anything either. Only 6 months not used? The current update wants to switch from V4 to V8. The change from V4 to V5 was made 11 years ago. Could it be that your previous digiKam was so old? Or was the database replaced by importing from an outdated backup? Maik neither nor. apt's history log goes back until a year ago. first occurence of digikam in October: digikam:amd64 (4:5.3.0-1, 4:5.6.0-3) so, last known working version was at least 5.3 -- I doubt this was released 11 years ago. first bug: failure to handle the db version (if in fact it did even recognize the right version! that may still be the case!) second bug: crashing. third bug: no information how to solve the issue. I'm left with a message I cannot readily translate (what configuration file where? what album library path? is it the folder where the pictures aree stored? is it something else? what does a schema have to do with the pictures folder (back to: what is the album library path?) where is that database? how do I create an empty one? why can didgikam not do it by itself? WHERE is the configuration? how can it be broken all of a sudden? how am I supposed to do anything without useful information?) I know it's all very technical, but digiKam will not be able to solve this problem automatically. Let's go through the error log for explanation: Here is the core database: > DB Core Name: "/home/username/Pictures/digikam4.db" It has a very old version number (4): > digikam.coredb: Core database: have a structure version 4 DigiKam is trying to update the database, but the album path has not been saved to the program configuration for a long time: > digikam.coredb: Core database: Album library path from config file is empty. Here's another hint that the database is very old, the table "TagProperties" does not exist yet: > "SELECT tagid, property, value FROM TagProperties ORDER BY tagid, property;" > Error messages: "Unable to execute statement" "no such table: TagProperties" It is possible that the database was damaged by something, but I think it is old. The database could also not by digiKam-5.3.0. been used, the update would have started also here. Remove the database, digiKam will create a new one. Alternatively, they can look in their system for the current "digikam4.db" and put them in the settings. There will not be another solution. Maik 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. Best Regards Gilles Caulier Hi Arne and happy new year, Can you check if problem remain with digiKam 7.5.0 pre-release bundle available here : https://files.kde.org/digikam/ Thanks in advance Gilles Caulier @arne digiKam 8.0.0 is out. This report still valid ? Best regards arne, What's about this file using current 8.2.0 AppImage Linux bundle ? It's reproducible ? https://files.kde.org/digikam/ Note: bundle is now based on Qt 5.15.11 and KDE framework 5.110. Thanks in advance Gilles Caulier Gilles, we can close this. The album collection path has not been saved in the digikamrc for years. If the database version is so old (reset by a backup or due to a defect), an update is simply no longer possible. We should remove the really old database update code of the digiKam-0.x versions. Maik |