GNOME Bugzilla – Bug 301313
[decodebin] seek while reading (non-existant) ID3v2 tag during autoplugging
Last modified: 2005-04-22 15:01:03 UTC
Here's something that happens with a file that allegedly has an ID3v2 and an ID3v1 tag: % gst-launch-0.8 -v filesrc location=foo.mp3 ! decodebin ! alsasink RUNNING pipeline ... /pipeline0/filesrc0.src: caps = application/octet-stream /pipeline0/decodebin0/typefind.sink: caps = application/octet-stream /pipeline0/filesrc0.src: active = TRUE /pipeline0/decodebin0/typefind.sink: active = TRUE /pipeline0/decodebin0/typefind.src: active = TRUE /pipeline0/decodebin0/id3demuxbin0/id3demux0.src: caps = application/octet-stream /pipeline0/decodebin0/id3demuxbin0/typefindelement0.sink: caps = application/octet-stream /pipeline0/decodebin0/id3demuxbin0/id3demux0.sink: active = TRUE /pipeline0/decodebin0/id3demuxbin0/id3demux0.src: active = TRUE /pipeline0/decodebin0/id3demuxbin0/typefindelement0.sink: active = TRUE /pipeline0/decodebin0/id3demuxbin0/typefindelement0.src: active = TRUE /pipeline0/decodebin0/typefind.src: caps = application/x-id3 /pipeline0/decodebin0/id3demuxbin0/id3demux0.sink: caps = application/x-id3 ERROR (0x80508f0 - 309442:56:06.148946000) id3tag(31799) gstid3tag.c(881):gst_id3_tag_handle_event:<id3demux0> Got seek to 6050010 during ID3v2 tag reading (allowed was 0) ERROR: from element /pipeline0/decodebin0/id3demuxbin0/id3demux0: Internal GStreamer error: event problem. File a bug. Additional debug info: gstid3tag.c(881): gst_id3_tag_handle_event: /pipeline0/decodebin0/id3demuxbin0/id3demux0: Got seek to 6050010 during ID3v2 tag reading (allowed was 0) /pipeline0/decodebin0/id3demuxbin0/id3demux0.sink: active = FALSE /pipeline0/decodebin0/id3demuxbin0/id3demux0.src: active = FALSE (process:31799): GStreamer-WARNING **: push on peer of pad typefind:src but peer is not active ERROR (0x80508f0 - 309442:56:06.175299000) scheduler(31799) gstoptimalscheduler.c(2797):gst_opt_scheduler_iterate:<GstOptScheduler@0x8116d18> in error state Execution ended after 30 iterations (sum 235970000 ns, average 7865666 ns, min 56000 ns, max 90578000 ns). The odd thing is that it doesn't really seem to have an ID3v2 tag, at least not at the beginning, nor at the end. There's only an ID3v1 tag at the end, and some lyrics stuff before that. Hexdump of the beginning: 00000000 ff fb b0 04 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00000020 00 00 00 00 49 6e 66 6f 00 00 00 0f 00 00 25 b1 |....Info......%.| 00000030 00 5c 50 a6 00 03 06 08 0b 0e 10 13 15 18 1a 1d |.\P.............| 00000040 1f 22 25 27 2a 2c 2f 31 34 36 39 3b 3e 41 43 46 |."%'*,/1469;>ACF| 00000050 48 4b 4d 50 52 55 57 5a 5d 5f 62 64 67 69 6c 6e |HKMPRUWZ]_bdgiln| 00000060 71 73 76 79 7b 7e 80 83 85 88 8a 8d 8f 92 95 97 |qsvy{~..........| 00000070 9a 9c 9f a1 a4 a6 a9 ab ae b1 b3 b6 b8 bb bd c0 |................| 00000080 c2 c5 c8 ca cd cf d2 d4 d7 d9 dc de e1 e4 e6 e9 |................| 00000090 eb ee f0 f3 f5 f8 fa fd 00 00 00 37 4c 41 4d 45 |...........7LAME| 000000a0 33 2e 39 31 20 01 bc 00 00 00 00 00 00 00 00 02 |3.91 ...........| 000000b0 c0 24 07 50 45 00 00 00 00 5c 50 a6 eb 5d de 83 |.$.PE....\P..]..| 000000c0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 00000270 00 00 ff fb b0 04 00 00 00 00 00 69 06 00 00 00 |...........i....| 00000280 00 00 0d 20 c0 00 00 00 00 01 a4 1c 00 00 00 00 |... ............| 00000290 00 34 83 80 00 00 4c 41 4d 45 33 2e 39 31 55 55 |.4....LAME3.91UU| 000002a0 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 |UUUUUUUUUUUUUUUU| * 000002e0 55 55 55 55 55 4c 41 4d 45 33 2e 39 31 55 55 55 |UUUUULAME3.91UUU| 000002f0 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 |UUUUUUUUUUUUUUUU| Hexdump of the end: 005c4ea0 55 55 55 55 55 55 55 4c 41 4d 45 33 2e 39 31 55 |UUUUUUULAME3.91U| 005c4eb0 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 55 |UUUUUUUUUUUUUUUU| * 005c50a0 55 55 55 55 55 55 4c 59 52 49 43 53 42 45 47 49 |UUUUUULYRICSBEGI| 005c50b0 4e 49 4e 44 30 30 30 30 32 30 30 43 52 43 30 30 |NIND0000200CRC00| 005c50c0 30 30 38 31 46 42 35 32 43 34 35 30 30 30 30 33 |0081FB52C4500003| 005c50d0 37 4c 59 52 49 43 53 32 30 30 54 41 47 4d 69 73 |7LYRICS200TAGMis| 005c50e0 73 79 20 51 75 65 65 6e 73 73 20 47 6f 6e 6e 61 |sy Queenss Gonna| 005c50f0 20 44 69 65 00 00 00 00 00 00 00 54 6f 6b 5f 54 | Die.......Tok_T| 005c5100 6f 6b 5f 56 73 5f 53 6f 66 66 79 5f 4f 00 00 00 |ok_Vs_Soffy_O...| 005c5110 00 00 00 00 00 00 00 00 00 54 6f 6b 20 54 6f 6b |.........Tok Tok| 005c5120 20 76 73 20 53 6f 66 66 79 20 4f 2d 50 72 6f 6d | vs Soffy O-Prom| 005c5130 6f 2d 43 44 2d 00 00 32 30 30 32 42 65 61 6d 2e |o-CD-..2002Beam.| 005c5140 74 6f 2f 73 74 61 6e 64 61 72 64 00 00 00 00 00 |to/standard.....| 005c5150 00 00 00 00 00 00 00 00 01 34 |.........4| 005c515a Cheers -Tim
Created attachment 45474 [details] gst-debug log The file is available at: http://sceptic.centricular.net/bug-301313.mp3 (server might not be running all the time, poke me on IRC if it is not). Cheers -Tim
Looks like it's not just a one-off. I get this with a lot of mp3 files, none of which have an ID3v2 tag; and they all seem to have a clean mpeg sync at the beginning as well. => bumping priority. Cheers -Tim
FWIW, if I revert these recent event caching changes to gsttypefindelement.[ch] in the core, everything works fine again: 2005-04-17 Ronald S. Bultje <rbultje@ronald.bitfreak.net> * gst/elements/gsttypefindelement.c: (gst_type_find_element_init), (push_buffer_store), (gst_type_find_element_handle_event), (gst_type_find_element_change_state): Allow event caching while typefinding so we don't lose events. * gst/elements/gsttypefindelement.h: Allow event caching while typefinding so we don't lose events. Cheers -Tim
I'll check. Probably did something stupid...
Fixed, I indeed did something stupid.