GNOME Bugzilla – Bug 588377
Don't block main thread in _seek()
Last modified: 2010-08-05 09:35:53 UTC
Open a file with totem. Move the slider slowly while playing from the left to the right. While moving the slider you will see that the slider stops repeatedly for some ms. During these interruptions totem changes the position of the stream. I think the slider should have its own thread so that the movement is not interrupted by other code. In Rythmbox there are no such interruptions. Rhythmbox will not change the position of the stream before you stop moving the slider. This is not really a bug. It is rather not a nice behaviour. This bug was originally reported at https://bugs.launchpad.net/ubuntu/+source/totem/+bug/323980
(In reply to comment #0) > In Rythmbox there are no such interruptions. Rhythmbox will not change the > position of the stream before you stop moving the slider. Except that Rhythmbox doesn't play videos, and you do want scrubbing for videos. It's most likely a problem with the source medium, or the computer being too slow.
Totem also shows this behaviour while playing audio files. The difference is that Rhythmbox will not change the position of the stream before you stop moving the slider.
I don't believe that this has something to do with the computer's speed. It's a Core Duo 2.2 GHz with 2 GB RAM and a 7200 rpm HD. Furthermore I tested it with the same audio file on the same computer and Rhythmbox doesn't have these interruptions. Perhaps Rhythmbox has its own thread for the GUI so that GUI is not freezed while waiting for the source medium.
Sigh. Rhythmbox DOES NOT DO SCRUBBING. The problem is that when seeking we do a blocking gst_element_get_state(), which would make the seeking feel stuttery.
Created attachment 156552 [details] [review] Don't block main thread in _seek() Instead keep hold of the last seek request and apply it when we've been told that the previous one finished, or apply it straight away if the previous seek took longer than 1/10th of a second.
Johannes, could you please test the attached patch? It's against Totem master.
(In reply to comment #5) > Created an attachment (id=156552) [details] [review] > Don't block main thread in _seek() > > Instead keep hold of the last seek request and apply it > when we've been told that the previous one finished, or > apply it straight away if the previous seek took longer than > 1/10th of a second. The delayed seek (after the previous one has finished) will be overwritten immediately by a new seek. Instead any new seeks should wait again on the delayed seek to finish or the timeout to happen. Other than that the patch looks good
See also bug 613351
Created attachment 156575 [details] [review] Don't block main thread in _seek() Instead keep hold of the last seek request and apply it when we've been told that the previous one finished, or apply it straight away if the previous seek took longer than 1/10th of a second.
New patch fixes the bug Sebastian mentioned in comment 7.
Looks good to me :)
Any news on this for the 2.31 branch/master? ;)
master is still 2.30.x Will probably branch after the next 2.30.x release.
Attachment 156575 [details] pushed as e55b44c - Don't block main thread in _seek()
BTW, it seems I forgot to push this onto master, and it only lived in the gnome-2-30 branch, which made merging a bit tedious. Testing in the gnome-2-32 branch and/or master would be appreciated (to see if I didn't break anything with Alexander's "accurate" seeking patch).