[vdr] Re: Annoying EMERGENCY EXITs

[Oliver Endriss <o.endriss@gmx.de>]

Klaus Schmidinger wrote:
> Rene Bartsch wrote:
> > Am Die, 2003-06-10 um 22.20 schrieb Klaus Schmidinger:
> > ...
> > So VDR should check itself
>
> That's what it does with the watchdog timer ;-)
>
> > and if it is running well it shouldn't
> > restart but check the state of the driver.
>
> And how exactly do you suppose that should work?
> How do you "check the state of the driver"?
> If VDR is recording, and there is no more data coming
> in, chances are the driver has run into trouble.

Ack.

> > If driver has crashed it
> > should reload the driver only without restarting itself.
>
> I'd really like to see how that would work!
> To reload the driver VDR needs to close all its file handles
> and most likely to exit in order to allow the surrounding script to
> do the driver reload, in case it is not running as 'root'.

Right now this is the only fool-proof strategy.

> > And if both are
> > running fine it should do nothing and wait until reception is back
> > (maybe some info "DVB xy unavailable" in logs and on OSD)
>
> Maybe we should connect VDR to some weather station, so it "knows"
> when there is bad wheather ;-)

ROTFL. What about a bad-weather-plugin? :-)

> Get serious - how should VDR tell that "bad weather" is the cause of
> the problems? The only thing I could imagine that might work is to
> limit the time after which another emergency exit may happen.
> Please implement that, test it, and if it improves things, send a
> patch. But keep in mind that VDR can't look out the window to see
> what the current weather conditions are ;-)

Maybe vdr could monitor signal strength of the frontend to detect a 
signal loss. On the other hand I read in some threads that even a 
frontend can hang...

The best solution would be to handle driver problems in the driver. 
The main problem is to restore the complete state information when a 
card hangs. Currently the driver is not able to restore everything 
after an ARM crash (PIDs, filters, DiSEqC, ...). That's why a 
unload/load sequence is required.

Another possibility is to add some functions to the driver interface
- to query "card health" (i.e. ARM crashed, frontend hangs)
- to reset a single card

vdr could monitor the card health reported by the driver. If an error 
occurres, vdr would reset the card in question, re-tune and set all 
filters again. No need to unload/reload everything.
I'm aware that this means a lot of work on the driver, but I think it 
should be possible. Could vdr handle it this way?

> > In case one card fails but enough cards are left for recording, VDR
> > also shouldn't restart but wait for the recordings to end.
>
> As far as I can see emergency exits are only done if an ongoing
> recording is having trouble. So it makes no sense to me _not_ to do
> an emergency exit if recording A is having trouble on card 1, just
> because recording B is running fine on card 2. I'd rather have a
> short glitch in recording B and still get the rest of recording A
> than have an uninterrupted recording B and miss half or all of
> recording A.

Well, I think there are people who would rather have one good recording 
without glitches than two recordings with glitches. It's a matter of 
taste. Maybe error recovery strategy could be a setup option in 1.3.x?

Oliver


-- 
Info:
To unsubscribe send a mail to ecartis@linuxtv.org with "unsubscribe vdr" as subject.