Mailing List archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[linux-dvb] Re: Latest CVS driver and CA recordings



Ralph Metzler wrote:
> 
> Klaus Schmidinger writes:
>  > I was hoping to be able to finalize the NAPI adaptation of VDR
>  > this weekend, but there are apparently still some severe problems
>  > in the latest CVS driver with encrypted channels.
>  >
>  > The biggest problems are with the ORF channels. Sometimes I don't get
>  > a picture on the video output of the DVB card (no matter whether I
>  > do a recording or just tune to that channel). When I do a recording
>  > it sometimes works fine, on other occasions the data coming from the
>  > Transport Stream contains video and audio packets (0xE0 and 0xC0),
>  > but inside these packets there are no "00 00 01" markers (there _is_
>  > a lot of data in the packets, but nothing that could be detected as
>  > "picture_header", "slice" or the like).
> 
> I could not find this error anymore on any of the encrypted channels
> I could test it with but this currently does not include ORF.
> Do you have this problem only on ORF or also still on other channels?
> 
> 
>  > Also, when switching between encrypted channels, I often get segfaults
>  > inside 'ioctl()'.
> 
> Well, a ksymoops dump would tell me a lot more than "it segfaults".
> Which ioctl() calls cause the segfault?
> 
> I also don't understand how a channel being encrypted could make a
> difference inside an ioctl().
> Outside of the firmware there is no longer any difference between
> encrypted an unencrypted channels.
> If the firmware would make problems or crash in this case I could
> at least understand it.

Well, looks like I know a little more now: since I have three DVB
cards and my CAM is in the third card, I always watch encrypted channels
in "Transfer Mode", i.e. grabbing the data from the third card and
replaying it on the first card. When I set my third card as the
"primary interface" no such segfault has happened yet. So it would appear
the problem doesn't primarily have to do with encrypted channels (that
was a misinterpretation on my side), but rather with the fact that
there is a "recording" (actually the live signal from another card, but
in this context this is just the same) being replayed on a card, and then
that replay is stopped and the channel is switched. Maybe there is some
"race condition" or someting like that here? Perhaps with your knowledge
of the driver's internals you could think of a place where it might be
a problem if the channel is switched immediately after stopping a replay.

The ORF problem, however, still exists even if I don't use "Transfer Mode",
but directly watch it on the card that contains the CAM. ORF1 sometimes
even works, but ORF2 hasn't worked a single time so far with the new driver.

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.



Home | Main Index | Thread Index