GNOME Bugzilla – Bug 626803
Banshee failes to read/import RATING:BANSHEE-comment
Last modified: 2010-09-01 20:50:02 UTC
Originally reported at: https://bugs.launchpad.net/bugs/617017 Binary package hint: banshee Ubuntu-Release: Ubuntu 10.04.1 LTS Banshee-Version: Banshee 1.6.1-1~lucid1 What I expected to happen: When I activate the option 'Saving Metadata to File' in 'Edit' -> 'Preferences'-menu, Banshee writes (among other comments) a field named RATING:BANSHEE into the vorbiscomment metadata container of my OGG Vorbis music files. When I close Banshee, delete the file ~/.config/banshee-1/banshee.db, then reopen Banshee and import my music all the metadata written to my music files - including the rating (RATING:BANSHEE-comment) - should be read/importet. What happened instead: When I close Banshee, delete the file ~/.config/banshee-1/banshee.db, then reopen Banshee and import my music the ratings seem to be lost. When I check the metadata of my music files by using 'vorbiscomment -l example.oga' I can see that the comment 'BANSHEE:RATING=X.X' still exists - so I assume Banshee is able to write this comment but failes to read/import it.
Maybe a side effect: I rate my music and create smart playlists (e.g. '3 stars and more') - the smart playlist '5 stars' contains my favorites. Now and then (I don't know how to reproduce this) the number of my favorites changes (jumps up) without any action from me... Now I checked the suddenly changed ratings with 'vorbiscomment -l example.oga' and found out that the rating hasn't really changed. That means: Banshee gives me wrong ratings. For example a song with a rating of 5 stars inside Banshee has the tag 'RATING:BANSHEE=0.8' which sould be 4 stars. However, when I change the rating of this file now inside Banshee this change is written to the metadata of the file immediately. Let's say I change the rating to 'no star' (no rating) - the tag changes to 'RATING:BANSHEE=0.5' or I change the rating to 4 stars & the tag changes to 'RATING:BANSHEE=0.8' (so the changes written to the file are correct). I allready tried to solve the problem by - rescanning the music library folder - recover my database as described in the faqs (http://banshee.fm/support/faq/) but both actions had no result on the (wrong) ratings shown by banshee. The last thing I tried was to move the whole folder ~/.config/bashee-1 the get rid of the 'broken' banshee-database; and that's how I recovered this bug (in the original report above). When I do so and reimport my music files all of them get a 5-star-rating inside banshee - however, the rating-tag in the metadata of the files hasn't changed at all. I can't get banshee to show me the correct ratings. The only way would be to rate all the files again - even though the 'RATING:BANSHEE'-tags are correct. Please tell me if you need more information on this.
Sounds related or possibly a dupe of bug #615351 and/or bug #628379
Yes, bug #628379 seems to be a duplicate (FLAC uses the same metadata format, vorbiscomment). I can also confirm that after playing a track with a wrong displayed rating, the correct rating in the vorbiscomment-metadata is changed (see 'Actual Results' in bug #628379).
Created attachment 169288 [details] debug log, C locale
Created attachment 169289 [details] Debug log, es_AR.utf8 locale.
I'm marking my bug #628379 as duplicate of this one. I use Ubuntu Maverick and Banshee 1.7.3 (for some reason 1.7.4 is not in this release yet) and this bug is still here. Something weird: Using The 'C' locale ratings are imported properly. I'm attaching debug logs with my current locale (es_AR.utf8) and the C locale. I started banshee with LC_ALL=C banshee --debug --redirect-log, then added a song to the filesystem queque. Noticed how the rating was imported correctly, played it, fast-fowarded to the end, and then closed banshee using the Media menu. Then I repeated the process without setting the LC_ALL variable. In the log: C locale, line 124: [1 Debug 17:02:37.156] FSQ Enqueue: /home/agustin/02. Kid X.flac [6 Debug 17:02:37.343] Importing Ogg Rating=4(0.8) and Playcount=5(5) from File "/home/agustin/02. Kid X.flac" [1 Debug 17:02:37.398] Player state change: Idle -> Loading [1 Debug 17:02:37.521] Player state change: Loading -> Loaded [1 Debug 17:02:37.525] (libbanshee:player) [gapless] Triggering track-change signal [1 Info 17:02:37.578] Uncached artwork size 217 requested [1 Debug 17:02:37.597] Player state change: Loaded -> Playing [1 Debug 17:02:37.639] Creating Pango.Layout, configuring Cairo.Context [1 Debug 17:02:37.639] Creating Pango.Layout, configuring Cairo.Context [1 Debug 17:02:38.243] Starting - Saving Metadata to File [7 Debug 17:02:38.245] Finished - Saving Metadata to File es_AR.utf8 locale, line 129: [1 Debug 17:06:34.773] FSQ Enqueue: /home/agustin/02. Kid X.flac [7 Debug 17:06:34.968] Importing Ogg Rating=5(0.8) and Playcount=5(5) from File "/home/agustin/02. Kid X.flac" [1 Debug 17:06:35.128] Player state change: Idle -> Loading [1 Debug 17:06:35.245] Player state change: Loading -> Loaded [1 Debug 17:06:35.268] (libbanshee:player) [gapless] Triggering track-change signal [1 Info 17:06:35.386] Uncached artwork size 217 requested [1 Debug 17:06:35.405] Player state change: Loaded -> Playing [1 Debug 17:06:35.450] Creating Pango.Layout, configuring Cairo.Context [1 Debug 17:06:35.450] Creating Pango.Layout, configuring Cairo.Context Gtk-Message: (for origin information, set GTK_DEBUG): failed to retrieve property `GtkWidget::visited-link-color' of type `GdkColor' from rc file value "((GString*) 0x7f5eac56dc40)" of type `GString' [repeated many times, the hex number changes] Please tell me if there is anything else I can provide.
*** Bug 628379 has been marked as a duplicate of this bug. ***
Great, thanks! Really helped to know it worked in C but not your locale -- should be fixed in master and the upcoming 1.7.5
Awesome! Thank *you* :) and great work! You got the bug fixed a day after I reported it. That's why I love Open Source :D