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 337681 - Seeking problem with MP3s in banshee and rhythmbox
Seeking problem with MP3s in banshee and rhythmbox
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins-ugly
0.10.4
Other Linux
: Normal normal
: 0.10.7
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2006-04-07 21:22 UTC by Sebastian Dröge (slomo)
Modified: 2007-11-15 21:52 UTC
See Also:
GNOME target: ---
GNOME version: ---


Description Sebastian Dröge (slomo) 2006-04-07 21:22:25 UTC 
Hi,
when seeking within MP3s in banshee or rhythmbox (but not totem) weird things happen: when selecting "previous" after some seconds (which would restart the song) the sound is muted for a moment and then the song continues playing from the current position and not from the beginning. This happens always.

For this sample it happens when selecting previous at around 5 seconds: http://librarian.launchpad.net/1914299/08.Moby_Dick.mp3


Bye

PS: and another problem which is probably known already... when seeking in some MP3s the position jumps to something completely different than what was selected. The problem is mostly with VBR files it seems

Ubuntu Bug: https://launchpad.net/distros/ubuntu/+source/gst-plugins-ugly0.10/+bug/33804
Comment 1 Christophe Fergeau 2007-06-08 08:00:11 UTC 
your PS: is bug #308312
Comment 2 Jan Schmidt 2007-06-08 08:57:12 UTC 
I can't reproduce the 'hitting the back button doesn't seek to the start' problem,
but from the extra information in the upstream bug, it's almost certainly fixed by this in CVS:

2007-05-25  Jan Schmidt  <thaytan@mad.scientist.com>

        * gst/id3demux/gstid3demux.c: (gst_id3demux_reset),
        (gst_id3demux_send_new_segment), (gst_id3demux_chain),
        (gst_id3demux_sink_event):
        * gst/id3demux/gstid3demux.h:
        * gst/apetag/gsttagdemux.c: (gst_tag_demux_reset),
        (gst_tag_demux_chain), (gst_tag_demux_sink_event),
        (gst_tag_demux_send_new_segment):
        Handle and adjust new-segment events so that downstream really
        sees a stream with the tag pieces stripped off the front and back.
        Fixes strangeness in seeking when mp3 decoders use the new-segment
        byte position to estimate their current playback position timestamp
        and then the arriving buffers don't match up.
Comment 3 Jan Schmidt 2007-06-08 08:59:48 UTC 
heh, I also just noticed the date on the original comment :)
Comment 4 Sebastian Dröge (slomo) 2007-06-10 21:31:00 UTC 
I can't reproduce it anymore with CVS, seems to be fixed somewhere since last year :)