2012-11-05, 21:34
@adamsutton: the dvdplayer changes are only used to prevent pausing and seeking when the PVR addon reports that it is not supported.
The situation before was that all commands to seek/pause were blocked at the application level and in the skin (which was also seen as a hack).
Your change is indeed a missing piece for the current timeshift support.
The change in the DVDPlayer is needed to support also the timeshift case were XBMC is just playing a stream like RTSP. In that case, XBMC does all the playback stuff.
In all cases FernetMenta is right about the problem around stream changes. I'm preventing rewind/fast forward across channel switches in the MediaPortal and ForTheRecord addons,
What is not covered is the possible changes in for example audio streams (2.0 to 5.1) while playing a channel (but that was also not covered before for PVR addons that don't do the demuxing).
I've seen the commit from Elupus that continuously scans for stream changes, but this only takes into account the case in which the PVR addon delivers an already demuxed stream to XBMC.
The challenge for a proper timeshift capable PVR API is to handle at least all four current Live TV playback cases (wit examples of the pvr addons):
1) Live TV playback via a fixed stream url (url is known before tuning the channel) (pvr demo addon)
2) Live TV playback via a stream url that is returned by the addon after tuning the channel (MediaPortal in ffmpeg RTSP mode)
3) Live TV playback of a raw stream delivered by the addon (MediaPortal in TSReader mode / ForTheRecord)
4) Live TV playback demuxed streams delivered by the addon (TVHeadend, VDR)
The actual way in which the backend supports timeshifting is also dependent on the backend. Some have always a timeshfit buffer while others need to start a recording and might need to switch to a different stream url/demuxer to play the delayed Live TV stream.
In all cases we would need to handle changes in streams and stream order.
The situation before was that all commands to seek/pause were blocked at the application level and in the skin (which was also seen as a hack).
Your change is indeed a missing piece for the current timeshift support.
The change in the DVDPlayer is needed to support also the timeshift case were XBMC is just playing a stream like RTSP. In that case, XBMC does all the playback stuff.
In all cases FernetMenta is right about the problem around stream changes. I'm preventing rewind/fast forward across channel switches in the MediaPortal and ForTheRecord addons,
What is not covered is the possible changes in for example audio streams (2.0 to 5.1) while playing a channel (but that was also not covered before for PVR addons that don't do the demuxing).
I've seen the commit from Elupus that continuously scans for stream changes, but this only takes into account the case in which the PVR addon delivers an already demuxed stream to XBMC.
The challenge for a proper timeshift capable PVR API is to handle at least all four current Live TV playback cases (wit examples of the pvr addons):
1) Live TV playback via a fixed stream url (url is known before tuning the channel) (pvr demo addon)
2) Live TV playback via a stream url that is returned by the addon after tuning the channel (MediaPortal in ffmpeg RTSP mode)
3) Live TV playback of a raw stream delivered by the addon (MediaPortal in TSReader mode / ForTheRecord)
4) Live TV playback demuxed streams delivered by the addon (TVHeadend, VDR)
The actual way in which the backend supports timeshifting is also dependent on the backend. Some have always a timeshfit buffer while others need to start a recording and might need to switch to a different stream url/demuxer to play the delayed Live TV stream.
In all cases we would need to handle changes in streams and stream order.