[mythtv-users] Myth problem or HDPVR probmem?

Alan Young ayoung at teleport.com
Mon Feb 14 22:24:19 UTC 2011


Michael T. Dean wrote:
> And, critically, that if they're /not/ in good working order, that the 
> drivers will report an error.
>
> The drivers /are not/ reporting an error--therefore, MythTV does not 
> report (or assume) an error.
>
> You're only assuming that the lack of data to write is an error.
If I start a ftp or browser download, the file is opened, but nothing is 
ever written to it, is that an error?  Yes.

If i start a recorder and the ringbuffer never changes and no data flows 
from the buffer to the file, that's the same situation as a download.

> For users whose digital channels disappear at times of the day, recording a 
> show that comes at the beginning of the broadcast period may, in fact, 
> include a period of no data.
>
>   
Hmmm... no frames of static?  No blank frames?

> I don't know about others, but I'm leary of having MythTV just assume 
> there are problems and react...
Signal monitor?

> How long do you wait until you say it's a problem?
Make it user settable per recording device option then.

> If you decide there's a problem, what do you do?
Easy.  Send system event  - "recording failed" or "device failed" or 
something like that.
> Switch this recording to a new input, then mark the current input as 
> unavailable and reschedule?
Mark the input as failed like it does now for errors.
> How long does the input get marked as unavailable?
Let the event driven the script setup by the mythtv user decide.

Maybe have a event to re-enable the input.  The recovery script can send 
it when it thinks the device is ok - if that ever happens.  If not, 
well, the script can decide if it wants to reboot the backend.
> Do you want to continuously poll the recorder, trying to 
> start recordings on it until one succeeds?  Do you, instead, want to 
> mark the input as unavailable until the user notices the log message or 
> missed recordings and investigates and fixes the STB/capture 
> device/connections/...?
>
> And these are only a few of the decisions you'd have to make to 
> implement a "MythTV is smarter than V4L/DVB and all hardware " 
> functionality.  I vote that if someone can make a case that it is an 
> error, the drivers be fixed to notice--and report--the error properly.  
> MythTV is an application, not a hardware interface layer.
>   
Robust / good applications detect system environmental failures.  
Granted, they may not all gracefully recover, but they do write a 
message, return a error code, etc.

Alan


More information about the mythtv-users mailing list