Differences

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

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision		Previous revision
Next revisionBoth sides next revision
dvr_api [2019/10/10 19:52] – nedsdvr_api [2020/10/25 01:37] – 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 from: https://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. | 
  
-Returns: Video 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 (higher) byte 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: 2024/02/07 03:05