GNOME Bugzilla – Bug 381857
[id3v2mux] crashes trying to write empty frames
Last modified: 2014-12-02 01:32:17 UTC
Please describe the problem: When trying to write tags for a particular album, I get the message "an internal Gstreamer error occured. File a bug". I can make some files from the album available if you want them. Steps to reproduce: Actual results: Expected results: Does this happen every time? Other information:
Created attachment 77576 [details] Debug output from rhythmbox Here is the debug output from Rhythmbox that is generated when I view a file's properties, type the new tags in, and then close the property window.
It seems Rhythmbox has actually written corrupt tags to the files. I previously set tags for all files in the album together, which appeared to succeed. Rhythmbox itself seems able to display the new tags from the file, but eyeD3 throws an error: 01 - The Post War Dream.mp3 [ 3.46 MB ] -------------------------------------------------------------------------------- Traceback (most recent call last):
+ Trace 91254
retval = main();
retval = app.handleFile(a);
audioFile = eyeD3.tag.Mp3AudioFile(f, self.opts.tagVersion);
hasTag = tag.link(f, tagVersion);
padding = self.__loadV2Tag(f);
padding = self.frames.parse(fp, self.header);
self.addFrame(createFrame(frameHeader, data));
f = TextFrame(frameHeader, data = data);
self._set(data, frameHeader);
self.encoding = data[0];
and kid3 and tagtool both silently ignore the tags and behave as if there are no tags set.
This is probably a gstreamer problem, what versions of gstreamer and the gstreamer plugins are you using?
gstreamer-tools 0.10.10-2 gstreamer0.10-alsa 0.10.10-2 gstreamer0.10-doc 0.10.10-2 gstreamer0.10-ffmpeg 0.10.1-2 gstreamer0.10-gnomevfs 0.10.10-2 gstreamer0.10-pitfdll 0.9.1.1+cvs20060515-1 gstreamer0.10-plugins-bad 0.10.3-3 gstreamer0.10-plugins-base 0.10.10-2 gstreamer0.10-plugins-base-apps 0.10.10-2 gstreamer0.10-plugins-base-doc 0.10.10-2 gstreamer0.10-plugins-good 0.10.4-3 gstreamer0.10-plugins-good-doc 0.10.4-3 gstreamer0.10-plugins-ugly 0.10.4-4 gstreamer0.10-plugins-ugly-doc 0.10.4-4 gstreamer0.10-tools 0.10.10-2 gstreamer0.10-x 0.10.10-2 libgstreamer-plugins-base0.10-0 0.10.10-2 libgstreamer-plugins-base0.10-dev 0.10.10-2 libgstreamer0.10-0 0.10.10-2 libgstreamer0.10-dev 0.10.10-2 totem-gstreamer 2.16.4-1
Can you reliably reproduce the corruption and/or post a fragment of the file before and after the corruption?
I am copying the file as it was before and after I originally tagged it to <http://robots.org.uk/stuff/381857/>.
rhythmbox writes id3v2 v2.4 tags, and libid3 (as used by kid3, tagtool, easytag, etc.) only supports id3v2 up to v2.3. ex falso (using mutagen) and cowbell (using taglib) read the v2.4 tags correctly. I'm not sure what's going on with eyed3. The "internal GStreamer problem" message means that the metadata reader process crashed. Might be related to bug 374036? To get a stack trace from the metadata helper: - run rhythmbox-metadata in gdb - copy the dbus address it prints to stdout (unix:abstract=/tmp/dbus-...) - elsewhere, export RB_DBUS_METADATA_ADDRESS=unix:abstract=/tmp/dbus-... - run rhythmbox - do whatever it is that crashes the metadata helper
Ok, so I don't need to be alarmed that other tagging programs fail to read the tags. :) I ran eyeD3 in a debugger and noticed that there are _two_ TRCK frames. The second one is empty (well, full of 0x00 bytes). eyeD3 seems to discard all the null bytes, and it's left with an empty string. I'll forward this to the eyeD3 maintainer--but is it proper that Rhythmbox wrote out two TRCK frames in the first place? 00000000 49 44 33 04 00 00 00 00 0a 21 54 49 54 32 00 00 |ID3......!TIT2..| 00000010 00 28 00 00 03 54 68 65 20 46 69 6e 61 6c 20 43 |.(...The Final C| 00000020 75 74 20 2d 20 30 31 20 2d 20 54 68 65 20 50 6f |ut - 01 - The Po| 00000030 73 74 20 57 61 72 20 44 72 65 61 6d 54 50 45 31 |st War DreamTPE1| 00000040 00 00 00 0b 00 00 03 50 69 6e 6b 20 46 6c 6f 79 |.......Pink Floy| 00000050 64 54 41 4c 42 00 00 00 0e 00 00 03 54 68 65 20 |dTALB.......The | 00000060 46 69 6e 61 6c 20 43 75 74 54 44 52 43 00 00 00 |Final CutTDRC...| 00000070 05 00 00 03 31 39 38 33 54 43 4f 4e 00 00 00 05 |....1983TCON....| 00000080 00 00 03 52 6f 63 6b 55 46 49 44 00 00 00 17 00 |...RockUFID.....| 00000090 00 68 74 74 70 3a 2f 2f 6d 75 73 69 63 62 72 61 |.http://musicbra| 000000a0 69 6e 7a 2e 6f 72 67 00 54 52 43 4b 00 00 00 02 |inz.org.TRCK....| 000000b0 00 00 03 30 54 50 4f 53 00 00 00 02 00 00 03 30 |...0TPOS.......0| 000000c0 54 52 43 4b 00 00 00 00 00 00 54 45 4e 43 00 00 |TRCK......TENC..| 000000d0 00 00 00 00 57 58 58 58 00 00 00 02 00 00 00 00 |....WXXX........| 000000e0 54 43 4f 50 00 00 00 00 00 00 54 4f 50 45 00 00 |TCOP......TOPE..| 000000f0 00 00 00 00 54 43 4f 4d 00 00 00 00 00 00 43 4f |....TCOM......CO| 00000100 4d 4d 00 00 00 05 00 00 03 00 01 00 00 54 43 4f |MM...........TCO| 00000110 4e 00 00 00 00 00 00 54 44 52 43 00 00 00 00 00 |N......TDRC.....| 00000120 00 54 41 4c 42 00 00 00 00 00 00 00 00 00 00 00 |.TALB...........| 00000130 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| I'll try to get a backtrace from the failing importer shortly.
Here's the backtrace from the metadata reading process: (gdb) bt full
+ Trace 91538
I can rebuild libtag/rhythmbox/gstreamer with debugging symbols if you need more info.
Debug symbols for gst-plugins-good and taglib would be helpful.
+ Trace 91610
FYI, that's taglib 1.4, unpatched, if you want to look at the source.
Looks like id3v2mux isn't checking for ID3v2::FrameFactory::createFrame() returning NULL. I'll have to look at what data is being passed in to figure out why that's happening.
Not sure why it has so many empty frames to write (8 of the 11 frames it tries to add through add_id3v2frame_tag are empty), but that's what's causing the problem. Moving to gst-plugins-good, and a patch will be along shortly.
Created attachment 77696 [details] [review] trivial patch
Ta, committed: * ext/taglib/gstid3v2mux.cc: Don't attempt to write a NULL frame into the ID3 tag set when the createFrame method returned NULL. Fixes: #381857 Patch by: Jonathan Matthew <jonathan at 0kaolin wh9 net >
*** Bug 449827 has been marked as a duplicate of this bug. ***