GNOME Bugzilla – Bug 304308
Time slider behaves incorrectly
Last modified: 2007-09-14 15:32:04 UTC
Please describe the problem: When using the time slider, totem displays "Seek to: (time)" However, that time is wrong. Steps to reproduce: 1. Open a movie with totem 2. Play the movie a little bit 3. Click pause 4. Click and drag the slider and look at the "Seek to: (time)" displayed in the status bar to find a spot on a track. Actual results: I was a minute or two off from where I wanted to be. (I had an hour long xvid file) Expected results: It should go to where "Seek to:" says.. Does this happen every time? yes Other information: I've only tried xinelib...
The ubuntu bugzilla has a bug about this too: http://bugzilla.ubuntu.com/show_bug.cgi?id=16276 That happens using totem 1.2.0 with libxine 1.0.1
The Ubuntu bug is a different problem (it's bug #129671). The problem is that the seek is done on a 1<->65535 scale, rather than based on time. Should be easy to fix, but might break for quite a few demuxers...
2007-09-14 Bastien Nocera <hadess@hadess.net> * src/backend/bacon-video-widget-gst-0.10.c: (bacon_video_widget_class_init), (got_time_tick), (bacon_video_widget_get_property), (bacon_video_widget_seek): * src/backend/bacon-video-widget-xine.c: (bacon_video_widget_class_init), (bacon_video_widget_tick_send), (bacon_video_widget_play), (bacon_video_widget_seek), (bacon_video_widget_seek_time), (bacon_video_widget_get_property), (bacon_video_widget_get_position), (bacon_video_widget_get_current_time): * src/backend/bacon-video-widget.h: * src/backend/baconvideowidget-marshal.list: * src/totem-video-thumbnailer.c: (capture_interesting_frame): * src/totem.c: (update_current_time): Update the xine-lib and GStreamer backends to use doubles for the current fraction position, to avoid loss of precision, fix PROP_POSITION being a gint64 when it was a double (or rather float as before), fix _get_position in the xine-lib backend to not return value > 1.0 In the xine-lib backend, when seeking by fraction, try to seek by time instead, gives better precision for most demuxers (Closes: #304308)