Timeshift

[perexg]

A discussion about broken timeshift implementation in kodi.

If I understand the kodi's player code right, the player has no knowledge about the timeshift behavior. It just does these operations: READ, SEEK(UTC), SPEED(unit 100 - negative backward). Unfortunately, there is no signalization back to the player that the timeshift buffer is empty when user press fast-forward or rewind so the player tries to send more SEEK commands without going to SPEED(100). This causes massive interactions with TVH backend which tries to seek to nowhere and some packets are dropped (TVH sends all errors back through HTSP!). Note that VDR PVR plugin does not support fast-forward/rewind at all.

I believe that the core kodi player must be improved to be notified that fast-forward and rewind is no more possible to go back to SPEED(100). Another option is to support only PAUSE as the VDR PVR plugin does at the moment.

[Jalle19]

Is tvheadend able to notify the client that the current position is at the end of the buffer? Or can the client detect it reliably? If so we could probably add a method to inform Kodi that it should stop fast forwarding and switch to normal playback speed.

[perexg]

I doubt that the out-of-buffer state can be detected by client reliably, because there's always a delay for the request processing. TVH sends two messages when the out-of-buffer state occurs:

Basic example: pause to start timeshift, then play and fast-forward.. Kodi player tries to play at SPEED(200) after EOB until user forces standard SPEED(100) (standard play):

[  TRACE]:timeshift: ts 4 seek to 16485597 (fd 63) read msg (nil) (0)
[  TRACE]:timeshift: ts 4 seek to 16485597 (fd 63) (incomplete)
[  DEBUG]:timeshift: ts 4 skip 81584000 requested 7342560
[  DEBUG]:timeshift: ts 4 skip last_time 1232714136662 pts_delta 1232639678986
[  DEBUG]:timeshift: ts 4 skip to 1232721262986 from 1232714136662
[  DEBUG]:timeshift: ts 4 skip failed
1) [  DEBUG]:htsp: ::ffff:127.0.0.1 [ admin2 | Kodi Media Center ] - subscription skip
1) [  TRACE]:htsp-sub: ::ffff:127.0.0.1 [ admin2 | Kodi Media Center ] - subscription 4 '{"method":"subscriptionSkip","subscriptionId":4,"error":1}'
[  DEBUG]:timeshift: ts 4 eob revert to live mode
2) [  DEBUG]:htsp: ::ffff:127.0.0.1 [ admin2 | Kodi Media Center ] - subscription speed
2) [  TRACE]:htsp-sub: ::ffff:127.0.0.1 [ admin2 | Kodi Media Center ] - subscription 4 '{"method":"subscriptionSpeed","subscriptionId":4,"speed":100}'

Analysis:

1. TVH notifies that skip failed.. pvr.hts CHTSPDemuxer::ParseSubscriptionSkip sets INVALID_SEEKTIME so CHTSPDemuxer::Seek fails with false
2. TVH notifies that the SPEED should be 100 (normal playback) ; CHTSPDemuxer::ParseSubscriptionSpeed does nothing

[Jalle19]

You're right, we only log the requested speed in https://github.com/kodi-pvr/pvr.hts/blob/master/src/HTSPDemuxer.cpp#L514. So we should react on this and send a subscriptionSpeed message back to the server? My only concern with this is that the Kodi player would be stuck in fast-forward state even though the playback speed may be back to normal. We need some way to trigger Kodi to stop fast forwarding.

@FernetMenta how would you propose we handle a situation like this? We'd need a new API method, right? But is it in your opinion okay for an addon to be able to control the player in this way?

[perexg]

The speed was already changed on the server. The mentioned routine should control the player's speed to let users notify that the playing state / speed changed.

[Jalle19]

Okay, I see now.

[Jalle19]

@FernetMenta apparently we also need a way to tell Kodi to switch to "pause" when the user rewinds so far back that the timeshift buffer ends. At the moment it stalls and behaves weirdly until the user fast forwards a bit.

@perexg how instantly does Kodi have to react to these situations? I doubt the call to trigger the player to change can be done completely synchronously.

[perexg]

There are no requirements from the TVH side, it's just about to break the bad requests from the player which does not make sense.

[Jalle19]

Closing this since the proposed changes have been merged. Thanks @perexg for helping us out!