[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