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

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

Josef Wolf wrote:
> On Mon, Jan 03, 2005 at 04:23:28PM +0100, Klaus Schmidinger wrote:
>
>
> > > > > 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 ;-)
> > > 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.
>
> This helps only when the user is actually _able_ to fix it.  For instance,
> I might not notice your "warning" simply because I'm not at home.  Or my
> wife/children are not able to fix it when I am on vacation.  She would
> kick me out of the house should such a thing happen while I am on
> vacation, preventing her to watch TV. ;-)
>
> It might be a good idea to show a warning in the OSD or some such.  But
> it is (IMHO) a bad idea to completely refuse to run.  Do you think it is a
> good idea having the refrigerator to automatically switch off just because
> the milk got sour?
So, since apparently everybody wants VDR to absolutely start, no matter
what, I guess the only thing I can do is make it drop entries from
channels.conf that are not unique (only the first one remains, which
shouldn't be a problem if the user has "Update channels" set to at
least "names and PIDs"), and drop timers for which there is no channel
in channels.conf (this actually _is_ a problem, because then a programmed
recording will _not_ take place).

> > How did that offending timer get in there in the first place?
>
> I started a recording, forgot about it, and started to throw away
> channels.conf entries I am not interested in.
I doubt that, because VDR won't let you delete a channel which has
a timer programmed on it - or did you find a way to actually do this?

> > > > > - 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.
>
> Ah, I wondered for a long time why the PIDs must be included in
> channels.conf and can not just be picked from the PMT.  Now I see.
Actually as of version 1.3.0 is _is_ taken from the PMT (if "Update channels"
is set to at least "names and PIDs").

> > 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.
>
> This will let you have duplicates in your favourite list.  But it will
> not help with the problem I actually had:  Since I could not find an
> up-to-date channels.conf for Hotbird (S13.0E), I decided to run scan
> by myself.  The scan utility put some duplicate/broken entries into
> the channels.conf.
I'd call that a bug in the scan utility.

> Then I had a hard time to find out which entries
> were actually bad.
Didn't VDR list the offending line numbers in the log file?

> > > > > - 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.
>
> When it do _not_ get a lock.
If it doesn't get a log, it simply doesn't start setting filters.

Take a look at the VDR source, where cThread::EmergencyExit(true) is called.
These are only in combination with recordings, not mere EPG scans.

> > > > 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:
>
> Oh, you misunderstood me.  I _want_ emergency exits for _fatal_ errors
> like not finding a channels.conf or or not finding any input devices or
> some such.  But a bad timers entry is not a fatal error.
Well, then what about just dropping offending lines in channels.conf
and timers.conf? With log messages, of course...

Klaus