[vdr] recommended CAM settings??
hi, I just want to know what the recommended CAM settings are for vdr-1.7.14 I'm using an alphacrypt light smartcard: unitymedia in most cases CAM and smartcard are working correctly, but sometimes the vdr cannot decrypt the channels diretlty after channel switch I'm not sure if this is a timing problem or not maybe, I have to change some CAM settings any recommendations? thanks marco -- AMMEC - Accessible MultiMedia Entertainment Center http://www.ammec.de Support Telefon: +49 6421 968255 ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] ERROR: driver buffer overflow on device 1
> > I have experienced this problem several times today while on HD h264 > > channels. Like previously posted: > > > > Mar 12 15:02:23 vdr: [20675] buffer usage: 70% (tid=20674) > > Mar 12 15:02:24 vdr: [20675] buffer usage: 80% (tid=20674) > > Mar 12 15:02:24 vdr: [20675] buffer usage: 90% (tid=20674) > > Mar 12 15:02:25 vdr: [20675] buffer usage: 100% (tid=20674) > > > > VDR was unresponsive and had to be restarted to fix. > > > > Best regards, > > Derek > > Sorry, forgot to mention this is with VDR-1.7.13... > >>> > >>> > >>> I confirm - with vdr 1.7.13 still have the same issue > >> > >> I assume, you both use vdr-xine. It would be a good idea to > >> create a backtrace in that situation to rule out vdr-xine as > >> source of this issue. > > > > yes, I'm using the vdr-xine 093 > > please advice how should I use backtrace > > When VDR is unresponsive, type something like that: > > gdb /path/to/vdr `pidof vdr` > > At the gdb prompt, issue the following command: > > thread apply all bt > > and provide the output. but with my buffer overflow problem the vdr is working without any deadlock. I can such messages only in syslog. That's why I can't do backtrace Goga ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] ERROR: driver buffer overflow on device 1
Hi, Am 21.03.2010 16:36, schrieb Peter Odéus: >> Would you be so kind and create a backtrace of xine when this >> happens again. And provide an "unwrapped" backtrace, e. g. by >> attaching the backtrace as a text file, which makes it easier to >> read, especially as xine has much more threads. > > I would happily do that if you can guide on how to backtrace xine. When xine is unresponsive, type something like that: gdb /path/to/xine `pidof xine` At the gdb prompt, issue the following command: thread apply all bt and provide the output. Bye. -- Dipl.-Inform. (FH) Reinhard Nissl mailto:rni...@gmx.de ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] ERROR: driver buffer overflow on device 1
On Sun, Mar 21, 2010 at 8:58 AM, Reinhard Nissl wrote: > Would you be so kind and create a backtrace of xine when this > happens again. And provide an "unwrapped" backtrace, e. g. by > attaching the backtrace as a text file, which makes it easier to > read, especially as xine has much more threads. I would happily do that if you can guide on how to backtrace xine. /Peter ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] ERROR: driver buffer overflow on device 1
Hi, Am 18.03.2010 13:43, schrieb peter: Does this happen too when not using vdpau? >> >> I'm not using vdpau (haven't got the hardware for it). >> >> vdr-1.7.10 >> xine-lib-1.2 >> >> The problem occurs when running xine with dxr3 output (xine --verbose=1 -V >> dxr3 -A alsa vdr:/tmp/vdr-xi/stream) >> >> Mar 18 13:26:43 vdr-desktop kernel: [ 6250.760298] em8300-0: adjusting scr: >> 30791 >> Mar 18 13:26:45 vdr-desktop kernel: [ 6252.872307] em8300-0: adjusting scr: >> 125823 >> Mar 18 13:27:05 vdr-desktop vdr: [4159] buffer usage: 70% (tid=4158) >> Mar 18 13:27:06 vdr-desktop vdr: [4159] buffer usage: 80% (tid=4158) >> Mar 18 13:27:06 vdr-desktop vdr: [4159] buffer usage: 90% (tid=4158) >> Mar 18 13:27:07 vdr-desktop vdr: [4159] buffer usage: 100% (tid=4158) >> Mar 18 13:27:18 vdr-desktop vdr: [4159] ERROR: driver buffer overflow on >> device 1 >> Mar 18 13:27:18 vdr-desktop vdr: [4159] buffer usage: 30% (tid=4158) >> Mar 18 13:27:18 vdr-desktop vdr: [4158] ERROR: skipped 11 bytes to sync on >> TS packet on device 1 >> Mar 18 13:27:18 vdr-desktop vdr: [4158] TS continuity error (3) >> Mar 18 13:27:18 vdr-desktop vdr: [4158] TS continuity error (11) >> Mar 18 13:27:18 vdr-desktop vdr: [4158] cAudioRepacker(0xC0): skipped 312 >> bytes while syncing on next audio frame >> >> However: >> >> When running without dxr3 (xine --verbose=1 -V xshm -A alsa >> vdr:/tmp/vdr-xine/stream) everything is fine. >> >> Here's gdb output from a bad run: Well, vdr-xine is writing to xine and blocks as xine doesn't read any input data. Would you be so kind and create a backtrace of xine when this happens again. And provide an "unwrapped" backtrace, e. g. by attaching the backtrace as a text file, which makes it easier to read, especially as xine has much more threads. Bye. -- Dipl.-Inform. (FH) Reinhard Nissl mailto:rni...@gmx.de ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
