You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I am helping to test this branch of Tvheadend (https://github.com/spdfrk/tvheadend/tree/iptv_features) which is intended to implement remote time changing via RSTP protocol. The concept is simple: the time change is done on server side instead of local side. Only one SDP command is needed to PLAY, PAUSE, STOP, or skip forward (positive values) or backward (negative values). The same philosophy is followed for speed change (-2x, -4x, -8x, -16x, -32x or 2x, 4x, 8x, 16x, 32x) sending a SCALE message with the desired speed. No need to do anything locally! Just play whatever server sends.
After trying a lot, it was possible to skip back and forth on Kodi with Tvheadend as the backend, but not speed changes on the server side.
Looking at the logs, the speed functions in TVH as well as in pvr.hts are only reached when pause / "un-pause" commands are sent. The speed commands are encoded in pvr.hts as skip / seek commands and are passed to the TVH backend in the same way (it appears that skip and seek are the same in pvr.hts and TVH).
Could this be fixed?
I tried the "local" time shift functions (the ones that use local files or RAM) and they work fine because, skip commands to change the speed are sent repeatedly (I think the idea is to change speed by making fast skips). How can I change the function in pvr.hts that is used when a speed change command is received from Kodi?
I think this change could potentially break a lot of things in TVH and pvr.hts because remote speed change is implemented with a different concept, in my opinion. Luckly, when remote time shifting is enabled, local timeshifting is disabled, but this behavior should also be replicated in pvr.hts...
Thanks a lot for your time and effort!!
Francisco
The text was updated successfully, but these errors were encountered:
The speed commands are encoded in pvr.hts as skip / seek commands and are passed to the TVH backend in the same way (it appears that skip and seek are the same in pvr.hts and TVH).
Could this be fixed?
The only person on this planet who could be able to answer this is @FernetMenta
Hello everyone,
I am helping to test this branch of Tvheadend (https://github.com/spdfrk/tvheadend/tree/iptv_features) which is intended to implement remote time changing via RSTP protocol. The concept is simple: the time change is done on server side instead of local side. Only one SDP command is needed to PLAY, PAUSE, STOP, or skip forward (positive values) or backward (negative values). The same philosophy is followed for speed change (-2x, -4x, -8x, -16x, -32x or 2x, 4x, 8x, 16x, 32x) sending a SCALE message with the desired speed. No need to do anything locally! Just play whatever server sends.
After trying a lot, it was possible to skip back and forth on Kodi with Tvheadend as the backend, but not speed changes on the server side.
Looking at the logs, the speed functions in TVH as well as in pvr.hts are only reached when pause / "un-pause" commands are sent. The speed commands are encoded in pvr.hts as skip / seek commands and are passed to the TVH backend in the same way (it appears that skip and seek are the same in pvr.hts and TVH).
Could this be fixed?
I tried the "local" time shift functions (the ones that use local files or RAM) and they work fine because, skip commands to change the speed are sent repeatedly (I think the idea is to change speed by making fast skips). How can I change the function in pvr.hts that is used when a speed change command is received from Kodi?
I think this change could potentially break a lot of things in TVH and pvr.hts because remote speed change is implemented with a different concept, in my opinion. Luckly, when remote time shifting is enabled, local timeshifting is disabled, but this behavior should also be replicated in pvr.hts...
Thanks a lot for your time and effort!!
Francisco
The text was updated successfully, but these errors were encountered: