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

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

Josef Wolf wrote:
> 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 ;-)
Not a bad idea... ;-)

> In this situation VDR completely refuses to start up.  How can the
> recording be done when VDR don't start up?
By refusing to start up it forces the user to fix the problem.
How did that offending timer get in there in the first place?

> > > - 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.
But the PIDs might well be different - and then you don't get anything
recorded. Believe me, channels _MUST_ be unique.

There will be user definable favourite channel lists later, and there
you will be able to have the same channel as many times as you like.
But the central "channels.conf" can only contain unique channels.

> > > - 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.
Well, in that case VDR just tunes to the transponder and, if it gets
a lock, starts parsing SI data. I don't see where this would cause
an emergency exit.

> > > - 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 :-)
I guess the author of the streamdev plugin should comment on this.

> > 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?
That's oh so very true...

> > 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.
Well, if you don't want restarts at all, just comment out these lines
in VDR/vdr.c:

        // Handle emergency exits:
        if (cThread::EmergencyExit()) {
           esyslog("emergency exit requested - shutting down");
           break;
           }

Klaus