Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
dvr_api [2019/10/10 19:52]
neds
dvr_api [2020/10/25 01:37] (current)
neds
Line 1: Line 1:
 ======HDHomeRun DVR development guide====== ======HDHomeRun DVR development guide======
  
-=====Live TV===== +<​WRAP ​center info
-<​WRAP ​indent+This is a mirror of the documentation fromhttps://github.com/Silicondust/documentation/wiki
-The record engine supports buffering live TV with automatic tuner sharing. +
- +
-====API URL==== +
-<WRAP indent>​ +
-<​code><​storage engine BaseURL>/​auto/​v<​channel number>?<​parameters></​code>​ +
- +
-Example<​code>​http://10.20.20.162:​4999/auto/v2.1?<​parameters><​/code>+
 </​WRAP>​ </​WRAP>​
-====Parameters==== 
-<WRAP indent> 
-^ Parameter ^ Type ^ Description ^ 
-| ClientID | GUID | Unique ID to identify the player. | 
-| SessionID | hex32 | Unique ID to identify the channel request. | 
  
-ReturnsVideo stream from the requested channel.  +  * [[:DVR API:Live TV]] 
- +  ​* [[:DVR API:DVR recording rules]] 
-If the app supports multiple running instances on the same computer each instance must have a unique ClientID. The ClientID does not need to be persistent across app launches. A valid implementation is to choose a ClientID when an instance of the app is launched. +  ​* [[:DVR API:​Poke ​record engine|Poke record engine (after rule change)]] 
- +  ​* [[:DVR API:​Deleting recordings]] 
-If the app supports picture-in-picture then each "​picture"​ must have a different ClientID so that changing channel on one "​picture"​ does not cancel and free the tuner being used by the other "​picture"​. +  ​* [[:DVR API:​Record ​engine ​status]]
- +
-The SessionID must be unique for each new request of a channel. This allows the record engine to differentiate between a new request vs a seek within the existing session. +
-</​WRAP>​ +
-====Seeking==== +
-<WRAP indent> +
-  ​- Close the existing HTTP connection that is streaming video. +
-  ​- Issue a new HTTP request specifying the desired starting byte offset in the RANGE header. The ClientID and SessionID parameters of the URL must be the same as the original HTTP request. +
- +
-When attempting to seek beyond the current live point the record engine ​will return success and will indicate the actual (lower) byte position in the HTTP Content-Range response header. +
- +
-The record engine ​automatically limits the amount of back history that is available for a channel to avoid running the DVR out of disk space when a client is left playing a channel for an extended period of time. When attempting to seek back to a byte position that is before the oldest still-available data the record engine will return success and will indicate the actual ​(higherbyte position in the HTTP Content-Range response header. +
-</​WRAP>​ +
-====Changing channel==== +
-<WRAP indent> +
-  ​- Close the existing HTTP connection that is streaming video. +
-  ​- Issue a new HTTP connection to request the new channel. Use the same ClientID but a new SessionID. +
- +
-The same ClientID tells the record ​engine ​that the previous channel is not longer of interest. Required to avoid tying up a new tuner with each channel change. +
- +
-The new SessionID tells the record engine that this is a new request rather than a seek request. Required to handle the situation where the user leaves live TV mode, then a short while later goes back into live TV mode. +
-</​WRAP>​ +
-</​WRAP>​+
  • Last modified: 2019/10/10 19:52