[mythtv] [mythtv-commits] Ticket #10765: HD-PVR: Rework SignalMonitor to avoid reading from device

[Michael T. Dean]

On 05/31/2012 02:04 PM, Dan Wilga wrote:
> On 5/31/12 10:59 AM, John P Poet wrote:
>> I proposed integrating the HD-PVR killer into the myth code, and the 
>> idea was rejected -- too specialized.
> I'm with Tom on this. I think it would be a good idea for the BE to 
> see if the recording is zero bytes long (or perhaps sticking at the 
> current size for too long) and trigger a system event. It seems to me 
> that this would detect the HDPVR needing a reboot condition, as well 
> as a host of DVB issues that seem to result in zero-length recordings.
>
> Using an event, one could write a script to use X10 to power cycle the 
> HDPVR, reload kernel modules, or just send a warning email. And if 
> this was accompanied by an automatic reschedule of the failed 
> recording, that would be the icing on the cake (mmmm... caaake).
>
> I know people have done versions of this using external scripts, but I 
> think having it built-into the BE would be more robust.

The HDPVR Killer scripts already use events.  See the README at the 
bottom of:

https://github.com/Beirdo/hdpvr-killer/tree/master/src

(see, also, http://www.hdpvrkillerdevice.com/ and the rest of the 
repo).  The only difference between its approach and the one you 
mentioned is that the backend would unilaterally decide--meaning the 
backend defines the one and only meaning for--when a recording is 
considered failed, rather than allowing users to define what they 
consider a failed recording.  The script could easily force delete the 
failed recording, which (if done properly, using the protocol, versus 
directly) would trigger a reschedule.

IMHO, how a user wants to deal with a temporary failure of the hardware 
is likely to vary significantly.  So, it seems that a script that allows 
user-customization is a good approach.

Mike