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

["Andreas Vitting" <Andreas@huji.de>]

Hi all!
now i'm back from holidays, i have done many, many tests with the OSD crash.
Here my results:
The function (for example) SetOSDBlock is very time consumption (and i think
it disabled interrupts and/or the kernel scheduler for the pipe-childrens).
It takes so much time, that the vdr program fills up the buffer - and when
the buffer is filled, the signal SIGPIPE is generated (because of the reader
is not there to empty the buffer). Klaus, if you catch this signal, your
program goes on - but w/o ac3 sound. The child of the pipe becomes a zombie.
The zombie is related to the program used for decoding the ac3 sound. I have
written (from play-ac3.c) a complete new version for the emu10k1 to handle
all the errors to avoid broken pipes (perhaps some other programs works
too??). For example the ac3 decoder must be able to check crc words from the
ac3 stream to reread if the crc check fails (and the check fails everytime
the osd is called). If it doesn't it gets sometimes e.g. a wrong framesize
(depends on the location of the error) and this gets to a memory overflow,
page fault or anything else.

Does anybody knows if the child of the popen has a lower priority in the
scheduler as the main program ???
Why doesn't the kernel call the child program if many osd functions are
called ???

Bye,
Andreas
-
-----Ursprüngliche Nachricht-----
Von: linux-dvb-bounce@linuxtv.org
[mailto:linux-dvb-bounce@linuxtv.org]Im Auftrag von Klaus Schmidinger
Gesendet: Freitag, 24. August 2001 18:13
An: Linux-DVB
Betreff: [linux-dvb] Re: New CVS Driver and OSD crashes with vdr -a -
WORKAROUND


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.



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