Differences
This shows you the differences between two versions of the page.
| Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
| dvr_api [2019/10/10 19:52] – neds | dvr_api [2024/02/07 03:05] (current) – neds | ||
|---|---|---|---|
| Line 1: | Line 1: | ||
| - | ======HDHomeRun DVR development guide====== | + | ======HDHomeRun DVR Development Guide====== |
| - | =====Live TV===== | + | < |
| - | < | + | 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> | + | |
| - | < | + | |
| - | + | ||
| - | Example: < | + | |
| </ | </ | ||
| - | ====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]] | ||
| + | * [[:DVR API:Poke record engine|Poke record engine (after rule change)]] | ||
| + | * [[:DVR API: | ||
| + | * [[:DVR API:Record engine status]] | ||
| - | 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. | + | {{tag>development}} |
| - | + | ||
| - | If the app supports picture-in-picture then each " | + | |
| - | + | ||
| - | 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==== | + | |
| - | <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. | + | |
| - | </ | + | |
| - | ====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> | + | |