On kubuntu 11.10 kde 4.8 amarok 2.5 1) Make a lot of change to a lot of files of your collection like : interpret - title - album -year -etc .. 4)Close amarok 2) Savagely remove your file from ~/.kde/share/apps/amarok/mysqle/amarok 3)Re-launch amarok 4)Scan all your collection 5)See all the change you made being lost... to me, it means that no information changed are actually saved into the mp3 file. Which is confirmed by a right clic on a preivously modified file in Dolphin Hence categorized as critical since, being given the amount of data that amarok handle (hence might loose) it might make users get the rid of amarok
Hi Maxime, can you please check if your audio files are modified at all. Please also check if they are write protected and can be modified by a normal user. If in doubt just send me the output of "ls -l" Cheers
Created attachment 69390 [details] This shows the metadata of a given track in Dolphin This are the metadata of one track where the re-scan of the collection did not worked properly. We clearly see followings information that amarok don't read Interpret:Cascada Album: Evacuate the dancefloor Track number 7 (Stueck)
Created attachment 69391 [details] The metadata of the same track in amrok. just after amarok rescan the full collection (once all mysqle files have been deleted) This are the metada as shown in amarok (see also the position of the track in the tree view) It shows, that for this track, amarok did not read properly the metadata stored in the file or even ignored them. The given metadata might have been read from the file name directly
I investigated a bit this evening. The bug might be more complex than I first thought 1)First of all that it does not write in ID3Tags is wrong, I have check in Dolphin for some other track and it does correspond to what is written in amarok I noticed that the track I checked yesterday are in fact deleted from the collection (in amarok but not on a Hard disk) hence there metadata were not edited which I thought was due by the fact that amarok does not save the information in ID3 Tag but apparently it does. 2)I am (pretty) sure that I did not deleted them myself from the collection. Also there might be a bug that delete track from the collection -> I will try to investigate on that 3)However, I retry to delete all the mysqle files and rescan the collection and I discovered something new Some files are indexing regarding to their actual metadata, as stored in the file itself (which is to me the right way to do things) Some other files are indexed regarding their filename, while they do have metada (those metadata are ignored and amarok replace it by its own Example on the screenshots Screenshots 1 is the metada as given by dolphin for a particular track where re-indexing did not worked properly As you can see the track is clearly identified by Interpred: Cascada Album name :Evacuate the dancefloor Track number:7 Those information should be used to index the track when re-creating the collection Instead, amarok display what is on the second screenshots. (To me, for some reason amarok ignored metadata and guessed metadata through filename) filename for this track /home/max/Music/Electro/Cascada/Cascada_-_Evacuate_The_Dancefloor/Cascada_-_Evacuate_The_Dancefloor_-_07_-_Breathless.mp3 ll in the directory where this file is : -rw------- 1 max max 7643731 2012-03-04 21:21 Cascada_-_Evacuate_The_Dancefloor_-_07_-_Breathless.mp3 To sum-up where we are about this bug 1)ID3tag saving does work 2)Scanning a collection by collecting ID3tag information seems to not work for some files 3)I suspect that at some point, editing the metadata or handling the collection has deleted files from my collection ( will try to investigate on it and open a dedicated bug report if necesseary)
Thank you for the fast feedback.
Could it be that you have done the following: In the file pane ("File") selected a local file and dragged it to the playlist. Then edited the track. Then moved the file to the collection. (or something like this) Can you reproduce the error by editing the track from the collection ("Local Music") and then rescanning? Or (instead of rescanning) updating ("touch <directory>") the directory (while "watch folder" is activated)
Inserting the track from the File pane and dragging to the playlist => No not that I know, at least not for all the tracks where I have a problem. But interesting one here: I try the following: 1) I start with the good collection 2) I edit the title of this given track ( just withdrawing the 's' at the end) 3) Full rescan (notice that I had "Zeichenerkennung fuer ID3 tag aktivieren" -> something like "Reckognize encoding in ID3 Tag?" ticked 4) After the full rescan, the track appear properly with good metadata while all other track of the collection where I had the problem are still indexed with wrong metadata 5)I choose a second track from the same artist and album but track number 1 6)I edit its album name,album interpret name and interpret name (BUT NOT THE TITLE) 7)Full rescan 8)The track appear with the wrong metadata (change made are lost) 9)I redo the same 5 and 6 but this time I edit the title (again withdraw one letter) 10)Full rescan 11)The track appear with GOOD metadata => it seems like writing the track title let a trace in ID3 tags or something somewhere that help amarok when re-reading the collection (or other way round, that not writing it hinder amarok from reading metadata properly) Note that the "watch folder was activated during this test" (in fact I have always had it activated) I did not test the "touch file" stuff. By this you mean unticking and re-ticking a file? If yes, I guess it would just perform a full re-scan as well
Thank you for the feedback.
Just to know: Is there ongoing work on that one? Do you manage to reproduce it? should I aske for people to try to reproduce it ?
Hi Maxime, all kinds of collection scanning problems were resolved in Amaork 2.6, could you please try to reproduce the bug with it?
*** Bug 301132 has been marked as a duplicate of this bug. ***
Hi, Indeed, it looks like it works better now . I will continue to use it and re-open if needed. We can consider it solved for now Thanks for the update and thanks for those who fixed it !