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

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

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?

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

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

> 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.  Then I had a hard time to find out which entries
were actually bad.

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

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

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