Digital TV doesn't really deal well with marginal signals. I mean real TVs do - if the signal drops out the receiver will resynch but something will be lost. (Analog just got "scribbly").
Dish's digitization of the OTA signal isn't very robust. If the signal drops below what the OTA dongle can capture the live signal capture gets stuck and sometimes will even go backwards in time trying to resync. Meanwhile sound and picture can get hopelessly disconnected. Sometimes backing up 10 seconds will return sound. Other times the whole screen will blink to green bars and the time (sometimes 10s of seconds) is lost. Sometimes a error box shows, don't remember exactly but it says "content lost". This occurs both on the native Hopper 3 and with wireless Joeys.
Playing back a recorded OTA signal is really interesting. The same artifacts occur and backing up can sometimes repair the sound. Pretty much a recorded version behaves the same as a live OTA.
In both cases (live and recorded) the player will most often ride through the disruption and resynch.
Note these are NOT outages, but rather "scribbles" when the screen pixelates. The OTA never says "signal lost" due to a true signal drop, but more like when the stream gets a bunch of ECC errors and the content is discarded for a brief period.
However the experience when watching such programming (either live or recorded) with a Dish Anywhere app is nowhere as robust. The playback via a tablet or phone is wholly intolerant of the signal loss. In order of frequency:
1. The app loses synch with the Hopper, and puts up the buffering spinner and sometimes "rides through"
2.. The app loses synch completely and requires a reconnection. In all but a few rare cases the reconnection is unsuccessful because #3 happened.
3. The app loses contact completely with the hopper because the Hopper reboots.
4. When using skip forward or backward if the time lands in the middle of a dropout, bad things happen, typically a Hopper reboot.
5. Some percentage of the time (say 20%) instead of rebooting the Hopper becomes unresponsive. Sometimes a program on the live channel will continue to play but the remote is horribly unresponsive (minutes to do anything if ever) or totally unresponsive, requiring a red-button reset. I've done embedded systems for 40 years and know a high priority infinite loop when I see one.
Is there a system log somewhere that explains the cause of the crash? My guess is that it's a memory fault caused by an unchecked out of bounds handle or pointer access...
Dish's digitization of the OTA signal isn't very robust. If the signal drops below what the OTA dongle can capture the live signal capture gets stuck and sometimes will even go backwards in time trying to resync. Meanwhile sound and picture can get hopelessly disconnected. Sometimes backing up 10 seconds will return sound. Other times the whole screen will blink to green bars and the time (sometimes 10s of seconds) is lost. Sometimes a error box shows, don't remember exactly but it says "content lost". This occurs both on the native Hopper 3 and with wireless Joeys.
Playing back a recorded OTA signal is really interesting. The same artifacts occur and backing up can sometimes repair the sound. Pretty much a recorded version behaves the same as a live OTA.
In both cases (live and recorded) the player will most often ride through the disruption and resynch.
Note these are NOT outages, but rather "scribbles" when the screen pixelates. The OTA never says "signal lost" due to a true signal drop, but more like when the stream gets a bunch of ECC errors and the content is discarded for a brief period.
However the experience when watching such programming (either live or recorded) with a Dish Anywhere app is nowhere as robust. The playback via a tablet or phone is wholly intolerant of the signal loss. In order of frequency:
1. The app loses synch with the Hopper, and puts up the buffering spinner and sometimes "rides through"
2.. The app loses synch completely and requires a reconnection. In all but a few rare cases the reconnection is unsuccessful because #3 happened.
3. The app loses contact completely with the hopper because the Hopper reboots.
4. When using skip forward or backward if the time lands in the middle of a dropout, bad things happen, typically a Hopper reboot.
5. Some percentage of the time (say 20%) instead of rebooting the Hopper becomes unresponsive. Sometimes a program on the live channel will continue to play but the remote is horribly unresponsive (minutes to do anything if ever) or totally unresponsive, requiring a red-button reset. I've done embedded systems for 40 years and know a high priority infinite loop when I see one.
Is there a system log somewhere that explains the cause of the crash? My guess is that it's a memory fault caused by an unchecked out of bounds handle or pointer access...
