GNOME Bugzilla – Bug 631970
Rating not saved for specific tracks
Last modified: 2011-11-10 19:52:56 UTC
Sometimes the rating I assign to a track is not saved. It appears to be saved, in that the status bar count changes (when I have a query set to "rating=0"), but on a later rescan of the library that track will reappear with a 0 rating. It may have something to do with ampersands, as many of the tracks in my collection showing this behavior have an ampersand in the track or artist, and the debug log shows a URI where spaces have been encoded but ampersands have not. However not all such tracks have ampersands - some have commas, parens, or dashes, and some don't appear to have any characters which should be troublesome. In the attached banshee.log, generated via banshee-1 --debug, I don't find any useful information. However in the output which comes to the terminal from which banshee was started, I find: [8 Debug 11:28:59.034] Saving metadata for Rusted Root - Food & Creative Love (on When I Woke) <00:04:13.5340000> [file:///nasmedia/Music/Rusted%20Root/When%20I%20Woke/09.%20Food%20&%20Creative%20Love.mp3] [9 Debug 11:28:59.240] Watcher: sleeping 999ms [8 Debug 11:28:59.244] Updating file name for Rusted Root - Food & Creative Love (on When I Woke) <00:04:13.5340000> [file:///nasmedia/Music/Rusted%20Root/When%20I%20Woke/09.%20Food%20&%20Creative%20Love.mp3] [8 Debug 11:28:59.330] Finished - Saving Metadata to File That's what gives me the suspicion about the ampersand. The issue currently affects 124 tracks out of the 4800+ in my library.
Created attachment 172181 [details] Requested but unhelpful debug log
Created attachment 172182 [details] Terminal --debug output From an earlier run but the same problem on the same track.
After more fiddling around, I'm wondering if the rating actually does get saved, and it's the Rescan Library which somehow erases it. How can I get at the database with an external program?
I'm also seeing this bug. The steps I use to replicate it are: 1. Have a track with a comma in the filename (characters like + and & also trigger the bug). 2. Import the track for the first time, it appears in the unheard automatic playlist. Play count column shows empty for this track. 3. Play the track, so the playcount increases, track gets removed from the unheard playlist. 4. Rescan the library (or reimport the folder containing the track). The track with the comma in the name re-appears in the unheard playlist, and it's playcount column is cleared. If I rename the same song and remove the comma, everything works as expected. Previous to http://git.gnome.org/browse/banshee/commit/?id=aa40b95bf04ce2c89be391d34c19aec0850bba1e this track would appear as a duplicate in the library, so that commit fixed part of the problem but not all!
*** Bug 632617 has been marked as a duplicate of this bug. ***
Trying to track this down but monodevelop keeps hanging on me.
I can't get the bug to happen while running in monodevelop. Running outside monodevelop with --debug-sql, I find SQL where the ampersand has been encoded (the %26 between 'Goodbye' and 'Good' below) [2 Debug 06:55:55.296] Executed in 1ms SELECT CoreTracks.Rating,CoreTracks.LastStreamError,CoreTracks.TrackID,CoreTracks.PrimarySourceID,CoreTracks.ArtistID,CoreTracks.AlbumID,CoreTracks.TagSetID,CoreTracks.MusicBrainzID,CoreTracks.MimeType,CoreTracks.FileSize,CoreTracks.FileModifiedStamp,CoreTracks.LastSyncedStamp,CoreTracks.Attributes,CoreTracks.Title,CoreTracks.TitleSort,CoreTracks.TrackNumber,CoreTracks.TrackCount,CoreTracks.Disc,CoreTracks.DiscCount,CoreTracks.Duration,CoreTracks.Year,CoreTracks.Genre,CoreTracks.Composer,CoreTracks.Conductor,CoreTracks.Grouping,CoreTracks.Copyright,CoreTracks.LicenseUri,CoreTracks.Comment,CoreTracks.BPM,CoreTracks.BitRate,CoreTracks.SampleRate,CoreTracks.BitsPerSample,CoreTracks.Score,CoreTracks.PlayCount,CoreTracks.SkipCount,CoreTracks.ExternalID,CoreTracks.LastPlayedStamp,CoreTracks.LastSkippedStamp,CoreTracks.DateAddedStamp,CoreTracks.DateUpdatedStamp,CoreTracks.Uri,CoreArtists.Name,CoreArtists.NameSort,CoreAlbums.Title,CoreAlbums.TitleSort,CoreAlbums.ArtistName,CoreAlbums.ArtistNameSort,CoreAlbums.IsCompilation,CoreAlbums.MusicBrainzID,CoreArtists.MusicBrainzID FROM CoreTracks,CoreArtists,CoreAlbums WHERE CoreArtists.ArtistID = CoreTracks.ArtistID AND CoreAlbums.AlbumID = CoreTracks.AlbumID AND CoreTracks.PrimarySourceID = 1 AND CoreTracks.Uri = 'file:///nasmedia/Music/AC%3B%20DC/The%20Razors%20Edge/11.%20Goodbye%20%26%20Good%20Riddance%20To%20Bad%20Luck.mp3' LIMIT 1 whereas the Uri column of the CoreTracks database table does not have the ampersand encoded. Next the code executes an INSERT with the ampersand not encoded: [2 Debug 06:55:55.330] Executed in 2ms INSERT INTO CoreTracks (Rating,LastStreamError,PrimarySourceID,ArtistID,AlbumID,TagSetID,MusicBrainzID,MimeType,FileSize,FileModifiedStamp,LastSyncedStamp,Attributes,Title,TitleSort,MetadataHash,TrackNumber,TrackCount,Disc,DiscCount,Duration,Year,Genre,Composer,Conductor,Grouping,Copyright,LicenseUri,Comment,BPM,BitRate,SampleRate,BitsPerSample,Score,PlayCount,SkipCount,ExternalID,LastPlayedStamp,LastSkippedStamp,DateAddedStamp,DateUpdatedStamp,Uri,TitleSortKey,TitleLowered) VALUES (0,0,1,185,285,0,NULL,'taglib/mp3',2333322,1288094025,1288180555,5,'Goodbye & Good Riddance To Bad Luck',NULL,'508f01827c13fa5871abdd4fae97e8fb',11,0,0,0,194273,0,'Hard Rock',NULL,NULL,NULL,NULL,NULL,NULL,0,96,44100,0,0,0,0,0,NULL,NULL,1288180555,1288180555,'file:///nasmedia/Music/AC%3B%20DC/The%20Razors%20Edge/11.%20Goodbye%20&%20Good%20Riddance%20To%20Bad%20Luck.mp3',X'0E250E7C0E7C0E1A0E090EA70E210702072507020E250E7C0E7C0E1A07020E8A0E320E1A0E1A0E020E700E0A0E2107020E990E7C07020E090E020E1A07020E480E9F0E0A0E360101010100','goodbye good riddance to bad luck') So encoding URIs is definitely at issue. It's very strange that the problem doesn't occur inside the debugger.
If I run Nereid.exe built from source, outside of the debugger, the problem does not occur then either. (However it does not recognize that any extensions have been installed) As far as I can see everything ought to be going through Hyena SafeUri.cs which calls g_filename_to_uri, which calls g_escape_file_uri with UNSAFE_PATH, which means that it will not escape the ampersand. So I can't explain why it does escape it sometimes, but only with the release and only when doing Rescan.
I think I found the cause and a fix for this issue. In the GIO library used by the scanner, it uses a different URI escape function than SafeUri uses. A patch is attached and is only two lines of change. It works on my system. A new scan goes from detecting 2000 new files, to the proper 75 ACTUAL new files.
Created attachment 200667 [details] [review] Patch to fix URI escaping in GIO (rescan library) This applies against Banshee 2.2 and works in my own testing.
Created attachment 200668 [details] [review] Slight modification of Xepher's patch Hi Xepher, thanks so much for investigating this! Can you try this patch instead, which is just a slight modification from yours? (Don't worry, if I push it, it will still go with your name on it ;) )
Review of attachment 200668 [details] [review]: Works for me!
(In reply to comment #12) > Review of attachment 200668 [details] [review]: > > Works for me! Thanks for testing Xepher. Before committing the patch into Banshee would you mind testing if this patch also fixes bug 661100? (First you would need to see if you can reproduce the bug with the patch.) I ask you because I have the impression it's the same bug, but I cannot test myself because I cannot reproduce bug 661100.
Can confirm this patch fixes bug 661100. Tested against the stable-2.2 git branch.
Created attachment 201093 [details] [review] generated with git format-patch
Review of attachment 201093 [details] [review]: looks correct and has gotten fine user testing feedback, plus the commit comment is impressively informative. Do remember to put the closed bugs in the commit message header so they will show up in cgit and friends which makes it nice and easy to see what bugs were closed by a given commit. Seems like master + stable material to me. I won't set accepted-commit now has I don't feel I have the authority to do so.
(In reply to comment #18) > Do remember to put the closed bugs in the > commit message header so... You cannot always do this because you also have to respect the max length of the first line of the commit message (and for the first line it's even more difficult because you also have to put the conceptual area of the commit as a prefix -- in this case "Gio:"). (In reply to comment #18) > I won't set accepted-commit now has I don't feel I > have the authority to do so. I don't have that authority either, this is why I'm posting the patch on behalf of a contributor instead of just pushing it :)
Review of attachment 201093 [details] [review]: Thanks for the patch, and the great commit message ! I committed it with a change: I used the SafeUri.FilenameToUri static method instead of creating SafeUri instance that will be immediately discarded. Less unneeded allocations is always good for performance. :)
This problem has been fixed in the development version. The fix will be available in the next major software release. Thank you for your bug report.