GNOME Bugzilla – Bug 401782
Remove support for obsolete id3mux plugin: it can corrupt ID3 tags
Last modified: 2007-03-02 13:00:46 UTC
Summary: Rhythmbox pops up a dialog box when it scans for changes in my music library about a gstreamer error when saving meta information. After this, there are errors in the library listing within rhythmbox, and the ID3 tags for some files are corrupted. Steps to reproduce: This happens when I close rhythmbox, use another program (in this case, EasyTag) to edit the tags on some files, then start up rhythmbox again. Only some files are affected, if I edit tags on several files at once, the chances are higher that there are errors reported. Actual results: Some of the media files have their ID3 tags stripped or corrupted (as confirmed from easytag), these files' entry within the Rhythmbox library are corrupted, with either artist name or song title as a series of dots (unprintable characters?) Expected results: Rhythmbox should correctly import the changes in the library. Software version: rhythmbox.x86_64 0.9.7-1.fc6 (latest version updated using Yum under Fedora Core 6) gstreamer.x86_64 0.10.10-2.fc6 Other information: Why is rhythmbox attempting to *write* meta information when importing music? It is messing up my library, which I generally keep rather well maintained. If it matters, the library is fairly large, over 7000 files.
The "corrupted" ID3 tags you are seeing in easytag are most likely ID3v2.4 tags which gstreamer writes, and which easytag cannot read because it will only read/write up to ID3v2.3 tags. If you check with a ID3v2-4-compliant tagger such as exfalso (a subset of the quodlibet package: http://www.sacredchao.net/quodlibet) you'll probably see the correct information in the tags. Can you check this? As to the fact that tags get written at all, ist that I suspect that for some reason when the import runs it attempts write the information in the rhythmbox GUI back out to the tags. The fact that rhythmbox is trying to write out any tags at all that you haven't explicitly ask to retag is a bug.
Created attachment 81410 [details] Screenshot of ID3 v2.4 compliant reader, showing corrupted tags This is an example of a corrupted tag after running Rhythmbox and it performs an automatic update of it's own library. Other programs like EasyTag don't show anything at all (all blank fields) Rhythmbox shows similar fields, with many 'dots' instead of readable characters. Each time I start up Rhythmbox, more files get damaged this way.
Well that would be a bug too. What versions of gstreamer-plugins-good are you using? Can you upload a portion of one of the original (unimported) file along with a portion of the corrupted files that resulted from an initial import, or otherwise make them available somewhere?
There might also have been a wrong charset issue in the original tags which resulted in an attempt to write those (inccorect) tags back out to the file, see the last question here: http://live.gnome.org/Rhythmbox/FAQ
I'm using gstreamer-plugins-good version 0.10.4-1.fc6 (I get this from Yum -- is there another way?) I'm not sure if it's an issue with character sets, since firstly this happens to random files each time I start Rhythmbox. Secondly, in many cases, I had just updated the tags with EasyTag (like for example changed the year for all files or added a disc number). I don't have the unimported file any more, I only had one copy whose tag got munged (hopefully not the audio part too). Also, I usually find files with names like filename.mp35663FA scattered around in the directories where I keep my music. These are all zero-byte files.
Can you reimport/rip some tracks from a CD to mp3 using rhythmbox or sound-juicer, then make backup copies of those mp3s and try: 1. Retagging in rhythmbox 2. Retag in easytag, followed by retagging in rhythmbox At each step of the way make backups of each file before and after the retagging so that each can be inspected using gst-inspect.
Attach the before and after results for both 1) and 2) using: gst-inspect -t playbin uri=file:///path/to/your/foobar.mp3
Here's what I tried: 0.1 Used gconf-editor to change the rhythmbox library path to a NULL string, since I didn't want it messing up even more files. 0.2 Verified by opening rhythmbox, it still showed all the files in my library, and started scanning for something, popped up a few error boxes and corrupted a few more files. 1. Ripped 4 tracks from the CD "Rush - Roll the Bones" with sound-juicer. Status: all OK. sound-juicer did not add any tags of its own. 2. Made 3 copies of the said files. Moved 1 copy to the directory tree configured as my music library. Marked one copy 'original', turned off write permissions for that copy. 3. Used rhythmbox to edit the tags on one copy. For two files (02 - Bravado.mp3 and 03 - Roll The Bones.mp3), things were ok (tags were apparently written). For two other files (01 - Dreamline.mp3 and 04 - Face Up.mp3), an error box popped up, saying "Error saving song information: Internal GStreamer problem; file a bug" and no tags were written. Upon inspection, the directory with this copy had two additional files: 01 - Dreamline.mp3D2784C and 04 - Face Up.mp3F4F84D, both of which were zero-byte files. 4. I used easytag to add tags to the third copy of the files. No problems, wrote the tags fine. 5. Tried to run gst-inspect -t playbin uri=file:///mnt/media/Music/rb_test/rhythmbox/01\ -\ Dreamline.mp3 and got the answer "Error initializing: Unknown option -t" 6. Tried to run gst-inspect uri=file:///mnt/media/Music/rb_test/rhythmbox/01\ -\ Dreamline.mp3 and got "No such element or plugin 'uri=file:///mnt/media/Music/rb_test/rhythmbox/01 - Dreamline.mp3'" 7. Tried to run gst-inspect /mnt/media/Music/rb_test/rhythmbox/01\ -\ Dreamline.mp3 and got "Could not load plugin file: Opening module failed" 8. Tried to do man gst-inspect to get more information, got "No manual entry for gst-inspect" 9. Got same results as steps 5-7 when running the commands on the control files (marked read-only) and the files tagged with easytag 10. Currently listening to music using xine, while trying not to look at the monitor to avoid the ugly purple GUI.
Sorry, (In reply to comment #8) > Here's what I tried: > 5. Tried to run gst-inspect -t playbin > uri=file:///mnt/media/Music/rb_test/rhythmbox/01\ -\ Dreamline.mp3 and > got the answer "Error initializing: Unknown option -t" Sorry, my mistake, please replace all occurences "gst-inspect" with "gst-launch" in my original comment. gst-inspect inspects the list of plugins, gst-launch creates a gstreamer pipeline. I use both of them so frequently that I occasionally mix them up.
Also what version of sound-juicer are you using to rip the tracks?
Apologies for not replying sooner, I've been trying to hit "reply" to the email bugzilla puts out. Anyway, here are the results: 1) After running Rhythmbox on a file which Rhythmbox reported an error on Setting pipeline to PAUSED ... Pipeline is PREROLLING ... FOUND TAG : found by element "mad0". layer: 3 mode: joint emphasis: none audio codec: MPEG-1 layer 3 bitrate: 128000 Pipeline is PREROLLED ... Setting pipeline to PLAYING ... New clock: audioclock0 Got EOS from element "playbin0". Execution ended after 278361016000 ns. Setting pipeline to PAUSED ... Setting pipeline to READY ... Setting pipeline to NULL ... FREEING pipeline ... 2) After running Easytag on the same file Setting pipeline to PAUSED ... Pipeline is PREROLLING ... FOUND TAG : found by element "id3demux0". title: Dreamline artist: Rush album: Roll the Bones track number: 0 duration: 278000000000 FOUND TAG : found by element "mad0". layer: 3 mode: joint emphasis: none audio codec: MPEG-1 layer 3 bitrate: 128000 Pipeline is PREROLLED ... Setting pipeline to PLAYING ... New clock: audioclock0 Got EOS from element "playbin0". Execution ended after 278349112000 ns. Setting pipeline to PAUSED ... Setting pipeline to READY ... Setting pipeline to NULL ... FREEING pipeline ... 3) Original (same file) Setting pipeline to PAUSED ... Pipeline is PREROLLING ... FOUND TAG : found by element "mad0". layer: 3 mode: joint emphasis: none audio codec: MPEG-1 layer 3 bitrate: 128000 Pipeline is PREROLLED ... Setting pipeline to PLAYING ... New clock: audioclock0 Got EOS from element "playbin0". Execution ended after 278354948000 ns. Setting pipeline to PAUSED ... Setting pipeline to READY ... Setting pipeline to NULL ... FREEING pipeline ... 4) After running Rhythmbox on a file which Rhythmbox correctly handled Setting pipeline to PAUSED ... Pipeline is PREROLLING ... FOUND TAG : found by element "id3demux0". ID3v2 frame: buffer of 48 bytes, type: application/x-gst-id3v2-tit2-frame, version=(int)4 : buffer of 44 bytes, type: application/x-gst-id3v2-tpe1-frame, version=(int)4 : buffer of 44 bytes, type: application/x-gst-id3v2-talb-frame, version=(int)4 : buffer of 47 bytes, type: application/x-gst-id3v2-tcon-frame, version=(int)4 : buffer of 51 bytes, type: application/x-gst-id3v2-trck-frame, version=(int)4 : buffer of 69 bytes, type: application/x-gst-id3v2-tpos-frame, version=(int)4 FOUND TAG : found by element "mad0". layer: 3 mode: joint emphasis: none audio codec: MPEG-1 layer 3 bitrate: 128000 Pipeline is PREROLLED ... Setting pipeline to PLAYING ... New clock: audioclock0 Got EOS from element "playbin0". Execution ended after 276133067000 ns. Setting pipeline to PAUSED ... Setting pipeline to READY ... Setting pipeline to NULL ... FREEING pipeline ... 5) Easytag results Setting pipeline to PAUSED ... Pipeline is PREROLLING ... FOUND TAG : found by element "id3demux0". title: Bravado artist: Rush album: Roll the Bones track number: 0 duration: 276000000000 FOUND TAG : found by element "mad0". layer: 3 mode: joint emphasis: none audio codec: MPEG-1 layer 3 bitrate: 128000 Pipeline is PREROLLED ... Setting pipeline to PLAYING ... New clock: audioclock0 Got EOS from element "playbin0". Execution ended after 276136525000 ns. Setting pipeline to PAUSED ... Setting pipeline to READY ... Setting pipeline to NULL ... FREEING pipeline ... 6) Original Setting pipeline to PAUSED ... Pipeline is PREROLLING ... FOUND TAG : found by element "mad0". layer: 3 mode: joint emphasis: none audio codec: MPEG-1 layer 3 bitrate: 128000 Pipeline is PREROLLED ... Setting pipeline to PLAYING ... New clock: audioclock0 Got EOS from element "playbin0". Execution ended after 276143246000 ns. Setting pipeline to PAUSED ... Setting pipeline to READY ... Setting pipeline to NULL ... FREEING pipeline ... Sound Juicer version: 2.16.3
If the original file shown in (3) and (6) was ripped by sound-juicer, it appears that sound-juicer is not tagging the files correctly in the first place. It maybe that your gstreamer pipeline in sound-juicer isn't correctly including the tagging for mp3 files, mine looks like this: " audio/x-raw-int,rate=44100,channels=2 ! lame name=enc vbr=4 preset=1001 ! xingmux ! id3v2mux" id3v2mux does the tag writing and xingmux writes the duration headers for the variable bit rate encoding. (4) also looks weird because it's returning "binary blobs" like application/x-gst-id3v2-tit2-frame where it should simply show the title as in (5). Was the pipeline shown in (4) done after retagging in rhythmbox? Because it looks like gstreamer has done something odd to the tags.
I checked the pipeline in sound-juicer, it's indeed not configured for ID3 tagging. It's currently set to audio/x-raw-int,rate=44100,channels=2 ! lame name=enc I tried adding the settings you mentioned (including vbr options and id3v2mux), but I got the same results (no mention of id3 tags on running gst-launch). (4) was done by taking a copy of the track ripped by Sound Juicer, opening it in Rhythmbox and changing the ID3 tag there. Of four files I tested with, two worked, while two caused Rhythmbox to put up an error box saying "Error saving song information: Internal GStreamer problem; file a bug". (4) was from one of the tracks that worked. I'm not sure how to show the pipeline that rhythmbox uses.
What do you get if you run: gst-inspect id3v2mux gst-inspect xingmux gst-inspect lame It seems like something might be up with your gstreamer installation. What exact packages are you using? rpm -q gstreamer gstreamer-plugins-base gstreamer-plugins-good gstreamer-plugins-ugly gstreamer-plugins-bad (you'll need gstreamer-plugins-bad if you using xingmux, if you remove the VBR options, you can skip xingmux and therefore gstreamer-plugins-bad).
Created attachment 82930 [details] Output of gst-inspect lame
gst-inspect id3v2mux gst-inspect xingmux, both return "No such element or plugin". Here is the result of the rpm query: gstreamer-0.10.10-2.fc6 gstreamer-plugins-base-0.10.10-1.fc6 gstreamer-plugins-good-0.10.4-3.fc6 gstreamer-plugins-ugly-0.10.5-1.lvn6 package gstreamer-plugins-bad is not installed These are all 64-bit packages, as are Sound Juicer and rhythmbox.
Hmm, well, lack of id3v2mux would definitely affect the ability to rewrite tags. ;) We may be getting closer the the heart of the problem, it *should* be part of gstreamer-plugins-good. But, hmm, lo and behold it's missing from mine too. It *should* be in /usr/lib/gstreamer-0.10/libgsttaglib.so. But: rpm -ql gstreamer-plugins-good|grep taglib returns nothing. This would also explain the gstreamer errors. OK, I'm pretty sure I know the exact source of the problem. The problem is that gstreamer-plugins-good is part of Core, but the id3v2mux needs taglib which is part of Extras, and Core packages can't depend on Extras packages. Grrr (although this problem should go away in Fedora 7 where Core + Extras will merge). I don't see the problem because I also build (in a separate directory) a complete gstreamer/plugins system from CVS. For the moment I recommend the custom packages from http://gstreamer.freedesktop.org/download/fedora5.html which will replace the official Fedora ones, but should also pull in the appropriate requirements (such as taglib) from Extras. (It's possible also that the handling of the binary tags in gstreamer might be affected on a 64 bit system, but more likely the missing id3v2mux plugin is the culprit).
Filed a bug in the downstream distribution: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=229312 It is still odd that it attempted to rewrite the file with the missing id3v2mux plugin. It should refuse to do *anything* to the file until the plugin is installed. *That* part is a rhythmbox bug.
(In reply to comment #13) > Of four files I tested with, two worked Were these two files that "worked" OGG files by some chance?
Checking with folks on IRC, it appears that if id3v2mux is not present it will try id3mux which is known to be buggy, it's part of the mad plugin, you'll probably see it if you run: gst-inspect id3mux
(In reply to comment #20) > id3mux which is known to be buggy, Specifically I think you're seeing this: bug #323658.
Updating summary to reflect underlying rhythmbox problem.
> For the moment I recommend the custom packages I'm a bit wary of using these, since it landed me in 'package hell' at one point (when I used FC5). > Were these two files that "worked" OGG files by some chance? Unless ogg supports wrapping up an mp3 inside (like avi can, for example), this is an mp3 file. gst-launch reports it as an MP3, and also I extracted all four files at the same time with Sound Juicer, with the same gst pipeline. I also could not find plugins-bad in the standard repos (core, extras) or livna.
(In reply to comment #23) > > For the moment I recommend the custom packages > I'm a bit wary of using these, since it landed me in 'package hell' at one > point (when I used FC5). Works fine for me on FC6. Just make sure you only install exactly what you need and no more. i.e. don't install the gstreamer-universe package. I just add the repo and let it upgrade gstreamer/gstreamer-python/gstreamer-plugins-{base,good,ulgy} then manually "yum install gstreamer-plugins-bad". It should only upgrade a few packages. Basically your choices are to: 1. Use the above packages to make sure you are retagging using id3v2mux 2. Build gstreamer-plugins-good/-ugly from source or CVS and make sure you have taglib-devel installed before you start 3. Avoid retagging using rhythmbox completely until such time as Fedora ships with gst-plugins-good built against the taglib package (should be in Fedora 7). > Unless ogg supports wrapping up an mp3 inside (like avi can, for example), this > is an mp3 file. gst-launch reports it as an MP3, and also I extracted all four > files at the same time with Sound Juicer, with the same gst pipeline. OK, not an OGG, the reason it probably worked is that occasionally id3mux retags without an error, but it usually screws up the tags. > I also could not find plugins-bad in the standard repos (core, extras) or > livna. plugins-bad isn't shipped by anyone except the aforementioned gstreamer packages.
I've removed id3mux support from SVN (and the 0.9.8 release) since it's damaging files. So I guess this is "fixed".
Does someone know the reason why rhythmbox was trying to retag my files even though I didn't ask it to? It gave me these errors when I started up the program after retagging some files in Easytag, after which it proceeded to mess up the tags in the updated files (see the original bug summary)
(In reply to comment #26) > Does someone know the reason why rhythmbox was trying to retag my files even > though I didn't ask it to? It gave me these errors when I started up the > program after retagging some files in Easytag, after which it proceeded to mess > up the tags in the updated files (see the original bug summary) I don't know exactly why, but I believe that rhythmbox will try and make the tags in the files match those in the db or vice versa (depending on how new the timestamp on the file is relative to the timestamp in the db). If you had changed the files outside rhythmbox but while it was running, it may have got into some race condition.