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

[Klaus Schmidinger <Klaus.Schmidinger@cadsoft.de>]

Josef Wolf wrote:
> Hello!
>
> Am I the only one who finds VDR's error handling strategies somewhat
> inconvenient?  Here are some examples:
>
> - VDR refuses to start up when some programmed recording timer refers to
>   an unknown channel.  I stumbled over this when I programmed a short
>   test recording and reorganized channels.conf thereafter.
>
>   Is there any reason _not_ to just ignore (or give a warning) on bad
>   recording timer entries?
Yes, the reason are people complaining if a recording is not done
in such a case ;-)

> - VDR refuses to start up when there are "duplicated data" in channels.conf.
>   What is the reason for this restriction?  Why can't I have a program
>   multiple times in channels.conf?  Or why not to just ignore duplicated
>   entries?
Channel entries have to be unique, otherwise a timer wouldn't know which
channel it refers to. Therefore such cases are caught right up front.

> - 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?
Normally it should only do this when it wants to record something
and gets no useful data. In that case it does a restart in order to
reload the driver.

> - 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?

> - Streamdev-server restarts VDR when one of the clients fails to keep up
>   with the data rate.  The effect is that all clients and recordings are
>   interrupted.  Why not just kick off the offending client and keep
>   running?
I guess that's not VDR's problem.

> I have seen some more "emergency exits" (e.g. constantly restarting as long
> as a specific recording is active), but I could not figure out the reason.
>
> It seems to me that VDR's error handling is way too restrictive.  In some
> situations this error handling strategy even makes VDR look/feel _very_
> unstable.  Please compare with a set-top-receiver.  Programming a bad
> channel will make this specific channel unusable but will not render the
> whole box to be unusable.
>
> 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... ;-)

If the driver were really rock solid stable, there probably would be
no reason for VDR to do any restarts, because a lack of signal would
just mean that there actually _is_ none. 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. Ok, maybe we should
touch some file and only do a reload if that file is older than some given
value (yet another setup option, I'm afraid...).

Klaus