How could that break tuner rollover?
All it's doing is inserting null packets until it picks up a stream.
I guess theoretically one can add a timeout. But Channel's DVR has a 15-second timeout, so if it never picks up a stream within those 15 seconds it should roll over. I don't believe the null packets are actually counted as video data. I think it's just kind of buffering.
ok, i didn't sleep at motel6 so I don't really know. 
just logically in my head it threw flags.. hope it works for you.
so far my extra home command seems to be working for me, but would be much quicker if I set my ospreys to just stay on home at wake instead of tuning the last channel. (I'll play more this weekend)
I am going to try to add maybe like a timeout or something.
You do make a valid point. It would retry forever.
@Shaggylive I added a 15-second timeout so it doesn't retry forever. I'm building the Docker container and testing right now to confirm that everything is solid. But that is a good point. Thank you so much for bringing that up. I really appreciate it. That made the PR a lot safer.
Edit: confirmed that the fix I wrote still works with the timeout added. If the encoder hasn't produced any real bytes for 15 seconds straight, the reader gives up and closes so Channels DVR sees EOF and can react normally.
Edit 1: I tested the timeout by starting a stream and immediately cutting the HDMI input on my encoder, and it did work. It attempted to stream 3 times and then gracefully closed the connection after 18 seconds. If anyone's running into this issue, feel free to pull my image and let me know if it's helpful at all. I really hope this benefits others. 