GNOME Bugzilla – Bug 613433
editing properties sometimes succeeds in ui, but in reality file isn't changed
Last modified: 2010-03-21 21:26:09 UTC
For MP3 files track properties (e.g. artist) can be changed and this seamingly goes without problems. However, for some files this actually fails and Rhythmbox gives no error message whatsoever. So, in the interface it looks fine, i.e. the properties are changed, but after I start Rhythmbox next time, all such properties are back to old values. It doesn't print anything in stderr either, I verified. This is true only for some files. For others, properties can be edited fine and they are indeed updated in the files and new values are properly retrieved when Rhythmbox starts next time. Expected: if property updating fails for any reason, Rhythmbox gives at least a generic error message _and_ doesn't misleadingly update properties in UI. Tested with 0.12.7.
This usually happens with mp3 files that have either ape and id3 tags, or multiple sets of id3 tags. Output from 'gst-launch-0.10 -t filesrc location=/path/to/file.mp3 ! decodebin ! fakesink' would tell us which.
It seems that no matter which MP3 I supply as argument I get this: ERROR: pipeline could not be constructed: Unrecoverable syntax error while parsing pipeline filesrc=...
That should be 'filesrc location=/path/to/file.mp3', not 'filesrc=/path/to/mp3'.
Sorry, my mistake. When command line is corrected, I get this one of the files for which Rhythmbox only pretends to change properties: Setting pipeline to PAUSED ... Pipeline is PREROLLING ... FOUND TAG : found by element "id3demux0". artist: nine inch nails title: getting smaller album: with teeth date: 2005-01-01 track number: 9 genre: Other image: buffer of 34150 bytes, type: image/jpeg, image-type=(GstTagImageType)GST_TAG_IMAGE_TYPE_UNDEFINED container format: ID3 tag FOUND TAG : found by element "id3demux1". title: getting smaller artist: nine inch nails ID3v2 frame: buffer of 15 bytes, type: application/x-gst-id3v2-tyer-frame, version=(int)4 : buffer of 25 bytes, type: application/x-gst-id3v2-tenc-frame, version=(int)4 : buffer of 15 bytes, type: application/x-gst-id3v2-uslt-frame, version=(int)4 : buffer of 20 bytes, type: application/x-gst-id3v2-rvad-frame, version=(int)4 : buffer of 11 bytes, type: application/x-gst-id3v2-tsop-frame, version=(int)4 : buffer of 11 bytes, type: application/x-gst-id3v2-tcom-frame, version=(int)4 comment: 00008AD0 00008A96 0001DBEB 0003098D extended comment: iTunes_CDDB_1[en]=B50D260D+252615+13+150+23797+40442+54505+70382+86975+109097+134425+154160+170320+188557+205390+229737 : iTunes_CDDB_TrackNumber[en]=9 album: with teeth date: 2005-01-01 beats per minute: 0.000000 container format: ID3 tag FOUND TAG : found by element "mpegaudioparse0". audio codec: MPEG 1 Audio, Layer 3 (MP3) FOUND TAG : found by element "mpegaudioparse0". bitrate: 320000 has crc: FALSE channel mode: stereo FOUND TAG : found by element "flump3dec0". audio codec: MPEG 1 Audio, Layer 3 (MP3) FOUND TAG : found by element "flump3dec0". bitrate: 320000 Pipeline is PREROLLED ... Setting pipeline to PLAYING ... New clock: GstSystemClock Got EOS from element "pipeline0". Execution ended after 4639063573 ns. Setting pipeline to PAUSED ... Setting pipeline to READY ... Setting pipeline to NULL ... Freeing pipeline ...
To clarify: I see two bugs here. First is that it is unable to change properties; however this might be a bug in some library and not even a bug in Rhythmbox. Second, and more importantly, Rhythmbox _pretends_ that everything is fine by a) not giving any error message at all; and b) changing properties in UI as if they were indeed changed. The second point is indeniably a bug in Rhytmbox itself, though it may be facilitated by some library's swallowing up and never reporting an error.
This file has two sets of ID3 tags. *** This bug has been marked as a duplicate of bug 424629 ***