GNOME Bugzilla – Bug 133897
Internal GStreamer error: seek problem
Last modified: 2004-12-22 21:47:04 UTC
A select number of my MP3s refuse to play in rhythmbox, but play fine through gst-launch-ext. Rhythmbox complains with: Internal GStreamer error: seek problem. File a bug. When I run the pipeline listed in the rhythmbox README I get this: >gst-launch gnomevfssrc location=./opeth-patterns.mp3 ! spider ! volume ! osssink RUNNING pipeline ... ERROR: from element /pipeline0/spider0/id3tag1: Internal GStreamer error: seek problem. File a bug. Additional debug info: gstid3tag.c(892): gst_id3_tag_chain: /pipeline0/spider0/id3tag1: can't seek back to beginning from reading ID3v1 tag Execution ended after 29 iterations (sum 44247000 ns, average 1525758 ns, min 41000 ns, max 15571000 ns). I've posted one of the mp3s that have this behavior at: http://homepage.mac.com/joeldiaz/freebsd/opeth-patterns.mp3 iTunes reports the ID3 tag as version 2.3. Thanks, Joel
I also thought I might add that I'm running libmad-0.15.0b and libid3tag-0.15.0b. Joel
Yeah, gst-launch can't differentiate between tagged and untagged mp3s while spider can do that... Anyway, the problem is that you have 2 ID3 tags at the beginning of the file which is something id3tag can't cope with.
So is this considered a bug? Do I forward this along to someone else (the group responsible for libid3tag)?
It's a bug with the GStreamer id3tag element. Sorry if that wasn't clear :)
this is fixed in current cvs