[vdr] Re: Error handling vs. user friendliness.

[Rainer Zocholl <UseNet-Posting-Nospam-74308-@zocki.toppoint.de>]

Klaus.Schmidinger@cadsoft.de(Klaus Schmidinger)  03.01.05 13:38

>> - VDR does an "emergency exit" when it fails to tune to a channel.
>>   This renders VDR to be completely unusable as long as at least one
>>   bad channel entry exists.  A bad LNB, a broken cable or a bird in
>>   front of one of the LNBs would make VDR unusable, too.  Why not
>>   just ignore (or give a warning) on bad entreis?

>Are you sure it does this just when you tune to such a channel?

See the thread regarding HDTV.

Meanwhile i found a patch that allows to setup a default start up channel.
That relaxes such problem a bit.

>Normally it should only do this when it wants to record something
>and gets no useful data. 

Maybe the logfile entry should state that explicit?
I know you don't like selfexplaining (long) logfile entries,
but sometimes a "comprehensive" (maybe redundant) message lowers 
users frustations when they know why the reboot occured.

>In that case it does a restart in order to reload the driver.

Why can't vdr ask the DVB-drivers: "Do you have any signal?"
With DVB-T i get the "clear" logging: "Can't lock receiver"
when i drop the anntenna. But VDR is not rebooting or showing
a "no signal" mini-mpg or OSD text...

I remember that this reaction of VDR was strongly required in the beginning
of the project, years ago, as the drives and the arm firmware were not
so reliable as they are meanwhile.

>> - VDR restarts continously when there is no signal in one of the
>>   available frontends.  Therefore you can't put the box to a
>>   different location just to watch some recordings.  You will need
>>   to take the dish along, although you don't want to watch live TV.

>Are you sure there is no recording scheduled at such a time?

Of course all his timers are still active ;_)
As VDR is doing instant restarts, he has no chance 
to deactivate (all) timers. And too: He would never expect
that the rebooting is caused by timers! Else he would not
have asked. You know it because you programmed it, but the 
user can't have that knowledge.


>> Coming back to my question: Is this restrictive error handling by
>> intention?  Or is it just that nobody noticed those inconveniences
>> yet?

>Well, it's as it always is: whatever you do, there will be somebody
>complaining... ;-)

As long as they are complaining it's a good sign:
They are using it and want to help to make it better.
Else they would not complaint and just use another product...


>If the driver were really rock solid stable, there probably would be
>no reason for VDR to do any restarts, 

I was not aware that VDR is expecting that runvdr is reloading
the drivers...oops.

>because a lack of signal would just mean that there actually _is_ none. 

Some cards allows to read out signal quality.
How is that done?

>Unfortunately, at least in the past, it happened ever so often 
>that the driver just didn't deliver any data any more, 
>and only a driver reload fixed that. 

I think in the past that behaviour was OK.

I don't know, but i assume that the driver and firmware will have
some kind of "NOP" functions? Maybe "Get Version number"?
Maybe it makes sense to test it, and restart only if that calls fails?
Or maybe there are selftests that could be started?

>Ok, maybe we should touch some file and only do a reload if that file is
>older than some given value 

Maybe an easy workarround to avoid entrirely broken recordings 
only because an other timer has a problem.

Maybe it would be possible that VDR powercycles the entire
box after such a problem when no timer is active anymore?

Or it there a way to detect an "emerency exit" 
in the runvdr script so runvdr could powercyle it
if that was the 2 second in the last 2 minutes?


>(yet another setup option, I'm afraid...).

There is no free lunch...