[linux-dvb] Re: New CVS Driver and OSD crashes with vdr -a - WORKAROUND

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

Klaus Schmidinger wrote:
> 
> Guido Fiala wrote:
> >
> > On Thursday, 23. August 2001 19:30, you wrote:
> > > At 18:25 23.08.2001 +0200, Stephan Schreiber wrote:
> > > >However, the sound of the previously tuned channel is being played after
> > > >the firmware reload, but no picture, and vdr does no longer react to
> > > >ctrl-c or the remote control.
> > >
> > > Oops.
> > > It is even stranger actually:
> > > It just crashed again, this time I was not in FF mode however.
> > > After the dvb driver has done its "reboot", vdr plays the sound of the
> > > RECORDING while no longer responding to commands.
> > > It actually resumes the replay.......only there's no picture and the sound
> > > stutters.... :-O
> >
> > Have that one with an older driver and vdr 0.9x too - but it seems really
> > to appear only if vdr is startet with "-a ac3dec" only, even on non-DD
> > recordings.
> >
> > @Klaus: so it's maybe not the driver?
> 
> I've been doing a lot of experimenting now and I found out (or can confirm,
> respectively) the following:
> 
> - it doesn't depend on what command is given to the '-a...' option
>   (the simplest case is '-a"cat > /dev/null"')
> 
> - it doesn't depend on whether the recording that is replayed actually contains
>   any Dolby Digital data (the mere presence of the pipe causes it)
> 
> - opening the pipe during the initialization of cDvbApi does NOT cure the
>   problem (as Andreas Vittig claimed in his posting
>   http://linuxtv.org/mailinglists/linux-dvb/current/msg00399.html), it just
>   happens a little later (though I don't have any idea why that should make
>   any difference at all)
> 
> Ok, so what's left?
> 
> While poking around in dvbapi.c I once disabled creating the siProcessor thread,
> and BINGO! The problem was gone!
> 
> So for a quick workaround I suggest everybody who is experiencing this
> problem should comment out these lines in dvbapi.c:
> 
> --- dvbapi.c    2001/08/19 15:09:48     1.109
> +++ dvbapi.c    2001/08/24 16:06:34
> @@ -2358,9 +2358,11 @@
>    // We only check the devices that must be present - the others will be checked before accessing them:
> 
>    if (((fd_qpskfe >= 0 && fd_sec >= 0) || fd_qamfe >= 0) && fd_demuxv >= 0 && fd_demuxa1 >= 0 && fd_demuxa2 >= 0 && fd_demuxd1 >= 0 && fd_demuxd2 >= 0 && fd_demuxt >= 0) {
> +     /*XXX
>       siProcessor = new cSIProcessor(OstName(DEV_OST_DEMUX, n));
>       if (!dvbApi[0]) // only the first one shall set the system time
>          siProcessor->SetUseTSTime(Setup.SetSystemTime);
> +        XXX*/
>       }
>    else
>       esyslog(LOG_ERR, "ERROR: can't open video device %d", n);
> 
> This will completely disable the EPG for the moment, but at least it shouldn't
> crash any more. I'll have to see how I can dynamically enable/disable this in order
> to come up with a final solution.
> 
> Please let me know if this actually makes the problem go away.
> 
> I still wonder what connection might be between the presence of a pipe and the
> EIT processing thread. Must be something mystical...

I have now further narrowed the problem down, and it would appear that
it does not happen until the SIProcessor thread actually allocates the
filters in cSIProcessor::SetStatus(). Once these are allocated, the problem
can occur.

VDR does close the filter handles before replaying (because the EIT processing
once caused dirsturbances when replaying), so I would have assumed that the
filters would be shut down, too. But apparently that is not the case: calling
close(filters[a].handle) in cSIProcessor::ShutDownFilters() does NOT shut
down the filters. So I inserted

  ioctl(filters[a].handle, DMX_STOP)

before calling close(), but that resulted in

  kernel: Unable to handle kernel NULL pointer dereference...

and I had to actually reboot my machine, since the dvb.o module could no
longer be rmmod'ed.

The bottom line now is: how is an application supposed to shut down a filter
that has been allocated the way VDR's cSIProcessor::AddFilter() (see eit.c)
does it?

Can one of the driver developers please give me a hint here?

Klaus
-- 
_______________________________________________________________

Klaus Schmidinger                       Phone: +49-8635-6989-10
CadSoft Computer GmbH                   Fax:   +49-8635-6989-40
Hofmark 2                               Email:   kls@cadsoft.de
D-84568 Pleiskirchen, Germany           URL:     www.cadsoft.de
_______________________________________________________________


-- 
Info:
To unsubscribe send a mail to listar@linuxtv.org with "unsubscribe linux-dvb" as subject.