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
Next revision Both sides next revision
dvr_api [2019/10/10 19:49]
neds [API URL]
dvr_api [2020/10/25 01:37]
neds
Line 1: Line 1:
 ======HDHomeRun DVR development guide====== ======HDHomeRun DVR development guide======
  
-=====Live TV=====+<WRAP center info> 
 +This is a mirror of the documentation from: https://​github.com/​Silicondust/​documentation/​wiki 
 +</​WRAP>​
  
-The record engine supports buffering live TV with automatic tuner sharing. +  * [[:DVR API:​Live ​TV]] 
- +  * [[:​DVR ​API:DVR recording rules]] 
-====API URL==== +  * [[:DVR API:Poke record engine|Poke record engine (after rule change)]] 
- +  * [[:DVR API:​Deleting recordings]] 
-<​code><​storage engine BaseURL>/​auto/​v<​channel number>?<​parameters></​code>​ +  ​* [[:DVR API:​Record ​engine ​status]]
- +
-Example<​code>​http://​10.20.20.162:​4999/​auto/​v2.1?<​parameters></​code>​ +
- +
-====Parameters==== +
- +
-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. +
- +
-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. +
- +
-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"​. +
- +
-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. +
- +
-====Seeking==== +
-  - 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 ​(lowerbyte 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. +
- +
-====Changing channel==== +
- +
-  ​- 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.+
  • Last modified: 2024/02/07 03:05