Have being using Kphotoalbum since 4.6.x with the same database. Suddenly it stopped working (with that database), just don't initialize and an error window is displayed: ------------------------------------------------------------------------------------ Error while reading database file - KPhotoAlbum An error was encountered on line 187, column 315: Error reading next element Additional error information: Attribute redefined. ------------------------------------------------------------------------------------ Found the problem is <image> tags have the attribute "Media_.20Type" duplicated as in this example: <image file="201512fromMint17.2/Aut_0006.jpg" label="Aut_0006" startDate="1996-12-31T22:00:00" endDate="1996-12-31T22:00:00" angle="0" md5sum="d6805cb540e63b579dac94b7e058414b" width="640" height="480" Folder="0" Media_.20Type="0" Folder="117" Media_.20Type="2"> Reproducible: Always Steps to Reproduce: 1. Use my wrong database (which have all the <image> tags with the attribute "Media_.20Type" duplicated. 2. Try to open the program Actual Results: See the error. Being unable to use KPhotoAlbum, it automatically close with the error (no usable database indeed) Expected Results: Use KPhotoAlbum normally, but as the database is unreadable by the xml parser, might add some workaround: 1. A warning of the error in database found. 2. Options for the user: a. to repair the error b. to create a new database file xml parser fails because there is invalid xml: ------------------------------------------------------------------------------------ Error while reading database file - KPhotoAlbum An error was encountered on line 187, column 315: Error reading next element Additional error information: Attribute redefined. ------------------------------------------------------------------------------------ I found the problem is <image> tags have the attribute "Media_.20Type" duplicated as in this example: <image file="201512fromMint17.2/Aut_0006.jpg" label="Aut_0006" startDate="1996-12-31T22:00:00" endDate="1996-12-31T22:00:00" angle="0" md5sum="d6805cb540e63b579dac94b7e058414b" width="640" height="480" Folder="0" Media_.20Type="0" Folder="117" Media_.20Type="2">
Created attachment 97735 [details] Screenshot of the error.
The snippet from your index.xml file shows more problems: Not only the "Media Type", but also the "Folder" attribute is written twice. The bigger problem, however, is that these two categories are saved at all. These two categories are computed from the file name and should not be stored in index.xml by KPhotoAlbum. I take it that this error occurred after an upgrade to KPhotoAlbum? Do you know which version you used before? Which language settings / locale are you using?
Can you reproduce this with an older version of your index.xml? KPA stores backups of it automatically, they are named like index.xml~xxxx~.zip, where xxxx is a number. It would be very interesting if you could tell us which version messed it up, and under which circumstances (is this reproducable? Did you switch locales? Doing so was actually a problem before KPA 4.7). As Johannes said, those categories shouldn't be found in index.xml at all …
(In reply to Johannes Zarl-Zierl from comment #2) > The snippet from your index.xml file shows more problems: > > Not only the "Media Type", but also the "Folder" attribute is written twice. > The bigger problem, however, is that these two categories are saved at all. > These two categories are computed from the file name and should not be > stored in index.xml by KPhotoAlbum. > > I take it that this error occurred after an upgrade to KPhotoAlbum? Do you > know which version you used before? > > Which language settings / locale are you using? Yes, you're right, also "Folder" attribute is found twice. AFAIK the problem began after upgrading from 4.7 to 4.7.1, but not sure if it was after first execution or a couple of them. I've also tried to downgrade KPhotoAlbum to 4.6 or 4.5 but using the same database leads to the same error. At last I tried to use different databases from the backup files, and only the latest is wrong, so I guess the new attributes where written by the last version: 4.7.1
(In reply to Tobias Leupold from comment #3) > Can you reproduce this with an older version of your index.xml? KPA stores > backups of it automatically, they are named like index.xml~xxxx~.zip, where > xxxx is a number. It would be very interesting if you could tell us which > version messed it up, and under which circumstances (is this reproducable? > Did you switch locales? Doing so was actually a problem before KPA 4.7). > > As Johannes said, those categories shouldn't be found in index.xml at all … Yes, sure, I have done some more tests and tried all the previous backups (unzipped and renamed to index.xml to make sure is the one used by KPhotoAlbum): index.xml~0126~.zip: no problem. Line#2: <KPhotoAlbum version="6" compressed="1"> index.xml~0127~.zip: no problem. Line#2: <KPhotoAlbum version="6" compressed="1"> index.xml~0128~.zip: no problem. Line#2: <KPhotoAlbum version="6" compressed="1"> index.xml~0129~.zip: crash. Line#2: <KPhotoAlbum version="7" compressed="1"> index.xml~0130~.zip: crash. Line#2: <KPhotoAlbum version="7" compressed="1"> So the problem appears to have arrived from version 7 onwards, but if backup 0129 was wrong... how the database was opened correctly and then saved again wrongly? Is the backup written on every save operation but the error arises only on KPhotoAlbum startup? Maybe I switched locales (en_US > es_ES), but can't remember. I think the locale change was long before the problem, but I can't remember. I don't know any other relevant circumstances, just doing basic stuff like tagging Photos, save, and on next run... Crash! My basic system info: Linux WS-MANJARO 3.18.27-1-MANJARO #1 SMP PREEMPT Tue Feb 16 22:53:23 UTC 2016 x86_64 GNU/Linux By the way, is it safe to delete all the duplicated attributes from my last database in order not to lose changes?
Thanks for the detailed info! > By the way, is it safe to delete all the duplicated attributes from my last database in order not to lose changes? Yes, this is safe. You can remove both the "Folder" and the "Media Type" attributes from the file without data loss.
Could you try taking the latest v6 database (index.xml~0128~.zip), open it with KPA 4.7.1, save it (it will be v7 afterwards) and see what happens? Probably, it wouldn't be a bad idea if you saved your backups somewhere else, not that KPA will finally overwrite then while we are tracking this down …
Created attachment 97770 [details] database file that worked (0128) and stopped working after saving
Thanks for posting the database. This makes it much easier to see what's going on here. I can reproduce it when I use the C locale. I get a doubled "Folder" and "Media Type" category and the read error you described appears after saving. When using my (German) locale, I also get the doubled categories, but one is called "Folder" and one "Ordner", which is the translation. Same for the "Media Type" one. The translated one is the "real" special category, the other one is empty. When saving the database using a non-C locale, no reading error occurs, probably due to the different names.
Just for the moment: A workaround would be: open the v6 database with KPA 4.7.1. You get doubled "Folder" and "Media Type" categories, one is the real one one is empty for each. Delete the empty ones (the "real" ones are not shown in the category settings and can't be deleted). Save the database. Doing so, the read error does not occur anymore here.
Git commit 1d32f069207ddbf044f379f057ac51405b3b016e by Johannes Zarl-Zierl. Committed on 08/03/2016 at 22:53. Pushed by johanneszarl into branch 'master'. Prevent duplication of special categories. Take care that a category in the index.xml file cannot have the same name as the "Folder" or "Media type" category. This prevents the creation of an ill-formed xml file in these cases. M +8 -2 XMLDB/FileReader.cpp http://commits.kde.org/kphotoalbum/1d32f069207ddbf044f379f057ac51405b3b016e