Question regarding using ClientID and SessionID on Recorded TV PlayURLs

Want to write your own code to work with a HDHomeRun or work with the HDHomeRun DVR? We are happy to help with concepts, APIs, best practices.
Posts: 615
Joined: Wed Oct 01, 2008 8:46 pm

Question regarding using ClientID and SessionID on Recorded TV PlayURLs

Postby djp952 » Sun Dec 03, 2017 12:19 pm

Hello, I have a question regarding the use of the ClientID and SessionID parameters in conjunction with accessing recordings on the HDHomeRun RECORD engine.

As documented in the API, I supply ClientID and SessionID parameters when accessing Live TV channels via the BaseURL. However, when accessing recorded streams via their PlayURL I do not currently supply these. What I have noticed is that when a recording is in-progress the PlayURL returns a live stream, as in the Content-Range: header <range-end> is set to the INT64_MAX and the <size> is unknown ("*").

Code: Select all

Content-Range: bytes 0-9223372036854775806/*

In order to allow the HDHomeRun RECORD engine to properly handle the stream while the recording is in progress across multiple clients, should I be providing ClientID and SessionID parameters to the PlayURL? If yes, is it harmful to always send them even if the recording has completed and now has a fixed Content-Range?

Side question: I have thus far interpreted the SessionID "hex32" format to mean a series of 32 hexadecimal characters, or a 128-bit value. Is this interpretation correct, or was "hex32" intended to indicate a hexidecimal 32-bit value (8 characters)? Adding some samples to the documentation may be helpful for others to ensure the ClientID and SessionIDs are formed properly.

As always, thanks for your time!

Posts: 14823
Joined: Tue Jan 13, 2004 9:39 am

Re: Question regarding using ClientID and SessionID on Recorded TV PlayURLs

Postby nickk » Sat Dec 30, 2017 12:51 am


When you issue a http request for a new channel, the ClientID is how the storage engine knows you no longer care about the previous channel so it can free up the tuner, likely using it for the new request. ie the ClientID needs to be the same for each new request. Sending a ClientID when requesting a recording is harmless.

BTW - If you want to do stream two channels to the same app (picture-in-picture?) simply use two different ClientIDs.

The SessionID is so the storage engine knows the request is a seek within the existing session vs the user has stopped the channel, then started the same channel again. It is a 32-bit (8 nibble/hex-character) number with a 0x prefix.

The Content-Range for a completed recording will indicate the actual position and actual length.

For a recording in progress the length is unknown ("*") but we still need to indicate the range that is being delivered (the http standard doesn't allow an unknown range end). The storage engine returns a max-length number is returned to meet this requirement while not limiting the amount of data that can be delivered.


Return to “Development Support”

Who is online

Users browsing this forum: No registered users and 1 guest