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

[Josef Wolf <jw@raven.inka.de>]

On Mon, Jan 03, 2005 at 01:38:53PM +0100, Klaus Schmidinger wrote:

> >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 ;-)

Hmm, this sounds like curing a headache by cutting the head off ;-)

In this situation VDR completely refuses to start up.  How can the
recording be done when VDR don't start up?

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

Ough?  Can you please explain this in a way that such simple-minded
people like me understand the problem?  A timer identifies the channel
by tuning parameters plus service-id.  And those parameters don't change
no matter how many duplicates your channels.conf contains.

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

Pretty much.  This was with a completely empty timers.conf.  The tuning
attempt is probably initiated by EPG scans.

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

Well, I'm not sure.  I would expect plugin-writers to adopt their error
handling philosophy from the main VDR philosophy.  Therefore I am not sure
whether this behaviour is by intention :-)

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

But when the driver is instable, then the _driver_ should be fixed?

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

But when only one of my 300 channels.conf entries fails to get a proper
tune, then there is a high probability that it simply contains a broken
entry.  Restarting every couple of seconds will not improve the situation
in any way.  It will just render the whole box to be completely unusable.

> 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...).

Oh, and it would not be a complete solution.  It would just reduce the
frequency of the restarts.

-- 
No software patents!
-- Josef Wolf -- jw@raven.inka.de --