After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 732862 - seek in m4a with ID3 tag: GStreamer-critical gst_segment_do_seek
seek in m4a with ID3 tag: GStreamer-critical gst_segment_do_seek
Status: RESOLVED OBSOLETE
Product: GStreamer
Classification: Platform
Component: dont know
unspecified
Other Linux
: Normal normal
: NONE
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2014-07-07 17:37 UTC by Stéphane
Modified: 2014-07-16 13:35 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Stéphane 2014-07-07 17:37:34 UTC
Hi,

I can't seek in many of my mp3, running totem with UBuntu 14.04.

I get the following error in the console when clicking in the progress bar of the song :

GStreamer-CRITICAL **: gst_segment_do_seek: assertion 'segment->format == format' failed

The playback from 00:00 is ok until the end of the MP3. This affects lots of MP3, so it is not a corrupted MP3 file.

The program hangs and it is not possible to get it running back (turns grey after some seconds, and I must force quit)

I've attached one of the MP3 that triggers this error. Can someone try to read it ?
Comment 2 Tim-Philipp Müller 2014-07-08 17:14:13 UTC
Thanks for the bug report and the sample file.

Could you also make a full debug log like this from a terminal/command line window:


 $ GST_DEBUG=*:6 totem /path/to/file.mp3  2>dbg.log
 ... start playing and then seek to reproduce the problem ...
 .... then hit Control-C to terminate the application (or force quit via the window manager)

Then compress the log with
 $ xz -9 dbg.log

and if possible make it available via your owncloud account (it's probably too large for bugzilla).

Thanks!
Comment 3 Stéphane 2014-07-08 19:21:26 UTC
I did want you propose and produce this log file :

https://cloud.vergeylen.eu/owncloud/public.php?service=files&t=fa73d0ca7eaa15054649e41be6d4bc7a

It was run with the same mp3 as before.

Good luck !
Comment 4 Tim-Philipp Müller 2014-07-10 22:34:28 UTC
I've had problems accessing this. The server was not reachable the first couple of days, and now it says there's no /owncloud directory.
Comment 5 Stéphane 2014-07-15 16:00:26 UTC
Very sorry that the file was not available.

Here are updated links !

- for the MP3 file :
https://cloud.vergeylen.eu/public.php?service=files&t=f311f9cd1c43630d3b084b8a61a05fd8

- For the log :
https://cloud.vergeylen.eu/public.php?service=files&t=fa73d0ca7eaa15054649e41be6d4bc7a

(please don't care about the SSL certificate error, there is no issue actually)
Comment 6 Tim-Philipp Müller 2014-07-16 13:35:58 UTC
Thanks.

So this isn't actually an mp3 but an m4a file (containing AAC) with an ID3 tag.

I can reproduce the issue with 1.2.x, but it seems to work fine for me with git master (i.e. the soon-to-be-released 1.4.x). Not sure what exact patch fixed it though.