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

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

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

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.