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 712181 - Seek issue : bad seek position
Seek issue : bad seek position
Status: RESOLVED FIXED
Product: rygel
Classification: Applications
Component: GstPlaybin plugin
0.20.x
Other Linux
: Normal normal
: ---
Assigned To: rygel-maint
rygel-maint
Depends on:
Blocks:
 
 
Reported: 2013-11-12 20:55 UTC by m.lathion
Modified: 2013-12-21 10:38 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
renderer: Treat ABS_TIME/REL_TIME the same (1.13 KB, patch)
2013-12-21 10:20 UTC, Jens Georg
committed Details | Review

Description m.lathion 2013-11-12 20:55:53 UTC
On v0.20.1 when seeking a file if I move the seek trackbar on controller when playing from 10% to for exemple 25% the trackbar indicator stay at 25% for 2-3 seconds and then jump to about 75% (with the stream playing at this position).
Seems a ration issue between song time and trackbar lenght.
I run rygel on Debian Jessie arch=armel(dist-upgraded from Wheezy) and I am able to reproduce the issue with different controller on different platform.
Comment 1 Jens Georg 2013-11-12 21:04:17 UTC
is that with gupnp-av-cp or some other tool?
Comment 2 m.lathion 2013-11-12 21:14:37 UTC
no only rygel in renderer mode.
Comment 3 Jens Georg 2013-11-15 21:52:44 UTC
No I mean which controller does show this behavior?
Comment 4 m.lathion 2013-11-17 07:59:00 UTC
Ho sorry. I've tried with foobar on windows, 8-Player and MediaConnect on iOS but now i've just tried with Upnp Inspector on Ubuntu and with this one it works ok.
It seems that on the device were the problem appear if I'm for exemple playing a stream at 00:25 and go with the trackbar to 01:00 the stream restart playing at 01:25 instead of 01:00
i.e. instead of restarting the stream at:
    Actual Time "00:25" + (Target Time "01:00" - Actual time"00:25") = 01:00 
it restart at: 
   Actual time (00:25) + Target time (01:00) = 01:25

Hope this is clear enough ;), in short the actual time is added to the target time when seeking...
Comment 5 Jens Georg 2013-11-17 13:15:46 UTC
Is that realy the playbin renderer or an MPRIS player connected to rygel? (I fixed something like this for MPRIS peers recently)
Comment 6 m.lathion 2013-11-17 14:56:37 UTC
Yes this is really the playbin renderer plugin.
The behaviour is also the same with Kinsky on linux.
Comment 7 Jens Georg 2013-11-18 09:56:44 UTC
Ah, of course. This is most likely a symptom of bug 686628. I suppose you don't happen to have the possibility to recheck with latest stable (0.20.2)?
Comment 8 Jens Georg 2013-11-18 10:12:54 UTC
Actually, that change was already included in 0.20.1. The code looks ok, it's using current time + value on REL_TIME and value-only with ABS_TIME and I can't imagine all clients to mix up REL_TIME and ABS_TIME :-/
Comment 9 m.lathion 2013-11-18 16:38:29 UTC
Ok, I forgot to mention here that seeking was working normally with all controller on v0.14.2, maybe it can help...
Comment 10 Jens Georg 2013-11-18 19:14:27 UTC
Uhhh, weird. Can reproduce with foobar, but not Helium.
Comment 11 Jens Georg 2013-11-18 19:19:06 UTC
Uhm. Technically what rygel does is correct. foobar issues a REL_TIME seek request but passes the absolute time :-/

Wow, things are quite broken out there... we might need more quirks :(
Comment 12 Jens Georg 2013-12-21 10:18:49 UTC
Turns out the fix in bug 686628 isn't correct.
Comment 13 Jens Georg 2013-12-21 10:20:09 UTC
Created attachment 264670 [details] [review]
renderer: Treat ABS_TIME/REL_TIME the same

Looks like the original fix wasn't correct, see

https://bugzilla.gnome.org/show_bug.cgi?id=686628#c3

Signed-off-by: Jens Georg <mail@jensge.org>
Comment 14 Jens Georg 2013-12-21 10:38:40 UTC
Attachment 264670 [details] pushed as fbf259c - renderer: Treat ABS_TIME/REL_TIME the same