Purpose of libhdhomerun keep-alive packets?

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.
Post Reply
djp952
Posts: 991
Joined: Wed Oct 01, 2008 8:46 pm
Device ID: 131EB7F7;131ED0E0
Location: Elkridge, MD

Purpose of libhdhomerun keep-alive packets?

Post by djp952 » Thu Jul 18, 2019 8:42 pm

Hi, I was wondering if you could indicate why libhdhomerun sends keep-alive packets to the tuner every second or so while it's streaming? I only have HDHomeRun PRIME devices available, but have noted that streams will still be broadcast over RTP/UDP seemingly indefinitely without this packet being sent, whether or not any client is actually listening.

My reason for asking is that without modifications to libhdhomerun to expose the lockkey value that was generated by hdhomerun_device_tuner_lockkey_request(), it's not feasible to duplicate this functionality exactly as it used by hdhomerun_video_thread_send_keepalive().

Does the value sent via port 5004 have to match the random number originally used to generate the lock key, or can any value (like zero) be sent to trigger whatever functionality the keep-alive packet enables?

Thanks!

gtb
Expert
Posts: 3996
Joined: Thu Oct 06, 2011 1:00 pm
Location: Sunnyvale, CA USA

Re: Purpose of libhdhomerun keep-alive packets?

Post by gtb » Thu Jul 18, 2019 8:49 pm

For almost all use cases one should probably move to using the new streaming protocols (HTTP) which address a number of limitations of the legacy protocols (including many of the real world problems on (especially) residential networks with UDP protocols).

djp952
Posts: 991
Joined: Wed Oct 01, 2008 8:46 pm
Device ID: 131EB7F7;131ED0E0
Location: Elkridge, MD

Re: Purpose of libhdhomerun keep-alive packets?

Post by djp952 » Fri Jul 19, 2019 8:10 pm

gtb wrote:
Thu Jul 18, 2019 8:49 pm
For almost all use cases one should probably move to using the new streaming protocols (HTTP) which address a number of limitations of the legacy protocols (including many of the real world problems on (especially) residential networks with UDP protocols).
Understood, and that's the primary way to do things. I am satisfying a user request to implement legacy UDP as it provides slightly better performance in his use case. The application is Kodi, and when HTTP/TCP connections are insufficient the inherent retries cause buffering. UDP (and RTP) without the network-level retries causes pixelation when packets are missed, of course, but this is preferred.

My question is that libhdhomerun sends keep-alives to the tuner every second, and it will be difficult to mimic this without forking libhdhomerun to get the same lockkey value it's using. I already have an RTP/UDP implementation via libhdhomerun however I was able to slightly improve the overall performance by doing it a different way. The keep-alives are the missing piece. I can leave them out and see how it goes, or just fork libhdhomerun to get the lockkey value I need.

I sincerely appreciate the response, however I would still like to understand the need for the keep-alive packets if possible :) Thank you!

gtb
Expert
Posts: 3996
Joined: Thu Oct 06, 2011 1:00 pm
Location: Sunnyvale, CA USA

Re: Purpose of libhdhomerun keep-alive packets?

Post by gtb » Fri Jul 19, 2019 9:31 pm

cam timeouts are one obvious reason for keep-alive packets.

nickk
Silicondust
Posts: 15621
Joined: Tue Jan 13, 2004 9:39 am

Re: Purpose of libhdhomerun keep-alive packets?

Post by nickk » Sat Jul 20, 2019 9:14 am

The HDHomeRun supports streaming video over HTTP as well as UDP and RTP over UDP.

If an app tells the HDHomeRun to stream via UDP or RTP then the app is terminated without it telling the HDHomeRun to stop the PC is meant to send an ICMP port unreachable packet so the HDHomeRun knows to stop. The problem - most PC based software firewalls prevent ICMP port unreachable packets from being sent and the HDHomeRun has no way to know anything is wrong on the PC side. The HDHomeRun continues to do its job - you come back a week later to find it is still happily streaming video to a non-existent app and tying up a tuner.

The HDHomeRun has an optional feature where you can send a keepalive packet from the app to the HDHomeRun. Once the HDHomeRun receives the first keepalive packet it starts a keepalive timer... if it receives another keepalive packet within 10s it resets the timer, otherwise it stops streaming.

The device layer of libhdhomerun automatically uses keepalive support when use the hdhomerun_device_stream_start() api. You can see in the implementation of this api it calls hdhomerun_video_set_keepalive() which enables the use of keepalive packets. A keepalive packet is sent every second.

All the modern apps use HTTP.

Nick

djp952
Posts: 991
Joined: Wed Oct 01, 2008 8:46 pm
Device ID: 131EB7F7;131ED0E0
Location: Elkridge, MD

Re: Purpose of libhdhomerun keep-alive packets?

Post by djp952 » Sun Jul 21, 2019 8:26 pm

Thank you! I did note that sending a packet to the device is needed to allow the stream to be received with the Windows firewall in place. Any packet seemed to suffice, but I did use port 5004, just with a zero for the lockkey value. Still worked :)

For now, I've pushed my implementation to the back-burner since I was unable to note any real world performance gains over the RTP/UDP implementation already in place in libhdhomerun. I was able to shave a couple % from the overall CPU utilization by eliminating the worker thread, but it didn't amount to enough to be worth it.

As time allows I will fork libhdhomerun to get the proper value to send and make sure it works in case it turns out that somebody may actually benefit from the change.

As always, I appreciate the response and am appreciative of how well libhdhomerun works and that you are still maintaining it. So -- thanks again!

Post Reply