Talking through this a bit: I think the error is very generic and there is likely to be more than one cause. It's obviously a pain to troubleshoot since it doesn't happen consistently.
There is one case that I can reproduce every time with the hardware I'm using.
- Put Android device to sleep.
- Reboot HDMI streamer (power cycle or reboot from the web GUI). Note: make sure you don't have a video preview running in the web ui after the reboot as that will start the stream before Channels does.
- Tune channel via Channels app.
This will cause generate a "connection lost" error in Channels as the video stream will temporarily drop out when it switches from the "no signal" image to the actual video stream. The stopbmitune.sh script executes because the stream drops out at the HDMI encoder level.
For this one specific issue I don't see any place where one could insert a pause to correct it. In the current implementation the entire tuning process is triggered by the http request to load the video stream so we can't perform any actions prior to that connection being established.
The Channels Team has expressed in the past that they don't want to open the can of worms that would be automatic retries so that's likely out.
The proxy app could perhaps be modified to always return a video stream even if the source is unavailable? This seems to be common among the other plugins (MLB, ESPN, etc). I think this is probably the best path forward as it won't require changes to Channels itself.
@tmm1 if you don't mind me asking, do you have intentions of continuing development of this proof-of-concept code you shared? I might be interested in contributing (or starting a separate, greenfield project) to take some of the ideas we've have learned and put them in a more robust platform. I however, wouldn't want to do so if you were anticipating adding this natively to Channels.
