Because of many problems with three different TV cards I had prevoiusly - I bought one which claims full linux support - Qbox II by TBS. After a few hours I have card working, hovewer I have a problem too. When I'm recording it seems ok, but when I'm watching through streamdev + VLC, there are errors about buffer overflow. Often it causes viewing to stop after a minute or so. I suspect there is need to set some larger buffers but I don't know where.
Aug 21 23:09:45 wuwek vdr: [5018] Streamdev: Accepted new client (HTTP) 192.168.1.10:2734 Aug 21 23:09:45 wuwek vdr: [5018] CAM 1: assigned to device 1 Aug 21 23:09:47 wuwek vdr: [5009] max. latency time 3 seconds Aug 21 23:09:51 wuwek vdr: [5030] streamdev-writer thread started (pid=5009, tid=5030) Aug 21 23:09:51 wuwek vdr: [5031] streamdev-livestreaming thread started (pid=5009, tid=5031) Aug 21 23:09:51 wuwek vdr: [5018] DVBAPI: 0.0 set CAM decrypt (SID 4807, caLm 4, HasCaDescriptors 0) Aug 21 23:09:52 wuwek vdr: [5032] receiver on device 1 thread started (pid=5009, tid=5032) Aug 21 23:09:52 wuwek vdr: [5033] TS buffer on device 1 thread started (pid=5009, tid=5033) Aug 21 23:09:52 wuwek vdr: [5018] Streamdev: Accepted new client (HTTP) 192.168.1.10:2737 Aug 21 23:09:52 wuwek vdr: [5030] ERROR: streamdev-server: couldn't send 48504 bytes: Połączenie zerwane przez drugą stronę Aug 21 23:09:52 wuwek vdr: [5030] streamdev-writer thread ended (pid=5009, tid=5030) Aug 21 23:09:53 wuwek vdr: [5018] client (HTTP) 192.168.1.10:2734 has closed connection Aug 21 23:09:53 wuwek vdr: [5018] streamdev-server: closing HTTP connection to 192.168.1.10:2734 Aug 21 23:09:53 wuwek vdr: [5031] streamdev-livestreaming thread ended (pid=5009, tid=5031) Aug 21 23:09:54 wuwek vdr: [5018] DVBAPI: 0.0 set CAM decrypt (SID 4807, caLm 5, HasCaDescriptors 0) Aug 21 23:09:54 wuwek vdr: [5018] buffer stats: 48692 (1%) used Aug 21 23:09:54 wuwek vdr: [5034] streamdev-writer thread started (pid=5009, tid=5034) Aug 21 23:09:54 wuwek vdr: [5035] streamdev-livestreaming thread started (pid=5009, tid=5035) Aug 21 23:09:54 wuwek vdr: [5033] TS buffer on device 1 thread ended (pid=5009, tid=5033) Aug 21 23:09:54 wuwek vdr: [5032] buffer stats: 50384 (1%) used Aug 21 23:09:54 wuwek vdr: [5032] receiver on device 1 thread ended (pid=5009, tid=5032) Aug 21 23:09:54 wuwek vdr: [5018] DVBAPI: 0.0 set CAM decrypt (SID 4807, caLm 4, HasCaDescriptors 0) Aug 21 23:09:54 wuwek vdr: [5036] receiver on device 1 thread started (pid=5009, tid=5036) Aug 21 23:09:54 wuwek vdr: [5037] TS buffer on device 1 thread started (pid=5009, tid=5037) Aug 21 23:09:54 wuwek vdr: [5015] Adding pid 208 (type 0xc0) RegDesc not found -> assume AC-3 Aug 21 23:09:54 wuwek vdr: [5015] Adding pid 213 (type 0xc1) RegDesc not found -> assume AC-3 Aug 21 23:09:54 wuwek vdr: [5015] Adding pid 1200 (type 0xc6) RegDesc not found -> assume AC-3 Aug 21 23:09:54 wuwek vdr: [5015] Adding pid 666 (type 0xc0) RegDesc not found -> assume AC-3 Aug 21 23:09:54 wuwek vdr: [5015] Adding pid 667 (type 0xc1) RegDesc not found -> assume AC-3 Aug 21 23:09:56 wuwek vdr: [5015] ERROR: 1 ring buffer overflow (188 bytes dropped) Aug 21 23:10:02 wuwek vdr: [5015] ERROR: 8 ring buffer overflows (1504 bytes dropped) Aug 21 23:10:09 wuwek vdr: [5015] ERROR: 10 ring buffer overflows (1880 bytes dropped) Aug 21 23:10:15 wuwek vdr: [5015] ERROR: 7 ring buffer overflows (1316 bytes dropped)
Marx
Ps. I know why I get: ERROR: streamdev: protocol violation (VTP) from 127.0.0.1:37275 It's from vdradmin-am which seems incompatible with VDR 1.7.28
Hi,
Am 22.08.2012 13:24, schrieb Marx:
Because of many problems with three different TV cards I had prevoiusly - I bought one which claims full linux support - Qbox II by TBS. After a few hours I have card working, hovewer I have a problem too. When I'm recording it seems ok, but when I'm watching through streamdev + VLC, there are errors about buffer overflow. Often it causes viewing to stop after a minute or so. I suspect there is need to set some larger buffers but I don't know where.
I have similar issues when using vlc (on Windows) and streamdev. I can watch 10 to 15 minutes without any problem and then vdr logs ring buffer overflows (just tested with ZDF HD/DVB-C). I hadn't time yet to debug this, but I suspect that decoding in vlc is a little bit too slow and vdr delivers data "too fast" (of course vdr will deliver with the right speed since it's receiving the original stream). Increasing buffers wouldn't resolve the problem, it will just take longer till the first overflow is hit.
And I think it's independend to the dvb card. I use a Satelco EasyWatch and a Cine C/T.
Lars.
Aug 21 23:09:45 wuwek vdr: [5018] Streamdev: Accepted new client (HTTP) 192.168.1.10:2734 Aug 21 23:09:45 wuwek vdr: [5018] CAM 1: assigned to device 1 Aug 21 23:09:47 wuwek vdr: [5009] max. latency time 3 seconds Aug 21 23:09:51 wuwek vdr: [5030] streamdev-writer thread started (pid=5009, tid=5030) Aug 21 23:09:51 wuwek vdr: [5031] streamdev-livestreaming thread started (pid=5009, tid=5031) Aug 21 23:09:51 wuwek vdr: [5018] DVBAPI: 0.0 set CAM decrypt (SID 4807, caLm 4, HasCaDescriptors 0) Aug 21 23:09:52 wuwek vdr: [5032] receiver on device 1 thread started (pid=5009, tid=5032) Aug 21 23:09:52 wuwek vdr: [5033] TS buffer on device 1 thread started (pid=5009, tid=5033) Aug 21 23:09:52 wuwek vdr: [5018] Streamdev: Accepted new client (HTTP) 192.168.1.10:2737 Aug 21 23:09:52 wuwek vdr: [5030] ERROR: streamdev-server: couldn't send 48504 bytes: Połączenie zerwane przez drugą stronę Aug 21 23:09:52 wuwek vdr: [5030] streamdev-writer thread ended (pid=5009, tid=5030) Aug 21 23:09:53 wuwek vdr: [5018] client (HTTP) 192.168.1.10:2734 has closed connection Aug 21 23:09:53 wuwek vdr: [5018] streamdev-server: closing HTTP connection to 192.168.1.10:2734 Aug 21 23:09:53 wuwek vdr: [5031] streamdev-livestreaming thread ended (pid=5009, tid=5031) Aug 21 23:09:54 wuwek vdr: [5018] DVBAPI: 0.0 set CAM decrypt (SID 4807, caLm 5, HasCaDescriptors 0) Aug 21 23:09:54 wuwek vdr: [5018] buffer stats: 48692 (1%) used Aug 21 23:09:54 wuwek vdr: [5034] streamdev-writer thread started (pid=5009, tid=5034) Aug 21 23:09:54 wuwek vdr: [5035] streamdev-livestreaming thread started (pid=5009, tid=5035) Aug 21 23:09:54 wuwek vdr: [5033] TS buffer on device 1 thread ended (pid=5009, tid=5033) Aug 21 23:09:54 wuwek vdr: [5032] buffer stats: 50384 (1%) used Aug 21 23:09:54 wuwek vdr: [5032] receiver on device 1 thread ended (pid=5009, tid=5032) Aug 21 23:09:54 wuwek vdr: [5018] DVBAPI: 0.0 set CAM decrypt (SID 4807, caLm 4, HasCaDescriptors 0) Aug 21 23:09:54 wuwek vdr: [5036] receiver on device 1 thread started (pid=5009, tid=5036) Aug 21 23:09:54 wuwek vdr: [5037] TS buffer on device 1 thread started (pid=5009, tid=5037) Aug 21 23:09:54 wuwek vdr: [5015] Adding pid 208 (type 0xc0) RegDesc not found -> assume AC-3 Aug 21 23:09:54 wuwek vdr: [5015] Adding pid 213 (type 0xc1) RegDesc not found -> assume AC-3 Aug 21 23:09:54 wuwek vdr: [5015] Adding pid 1200 (type 0xc6) RegDesc not found -> assume AC-3 Aug 21 23:09:54 wuwek vdr: [5015] Adding pid 666 (type 0xc0) RegDesc not found -> assume AC-3 Aug 21 23:09:54 wuwek vdr: [5015] Adding pid 667 (type 0xc1) RegDesc not found -> assume AC-3 Aug 21 23:09:56 wuwek vdr: [5015] ERROR: 1 ring buffer overflow (188 bytes dropped) Aug 21 23:10:02 wuwek vdr: [5015] ERROR: 8 ring buffer overflows (1504 bytes dropped) Aug 21 23:10:09 wuwek vdr: [5015] ERROR: 10 ring buffer overflows (1880 bytes dropped) Aug 21 23:10:15 wuwek vdr: [5015] ERROR: 7 ring buffer overflows (1316 bytes dropped)
Marx
Ps. I know why I get: ERROR: streamdev: protocol violation (VTP) from 127.0.0.1:37275 It's from vdradmin-am which seems incompatible with VDR 1.7.28
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
On 28 August 2012 11:30, Marx acc.for.news@gmail.com wrote:
Are we the only two who have this problem? Marx
Are you watching on VLC over Wifi? Have you tried increasing vlc's HTTP caching? I tend to set it to 'maximum latency', or switch to advanced and increased it to ~4000ms.
Also try accessing streamdev's PES streams (http://example.com:3000/PES/101 ) rather than the TS stream.
Oh and also try using xineliboutput's streaming of the current channel (http://example.com:37890 ) to see if that works any better.
Hi,
Am 28.08.2012 17:08, schrieb Dominic Evans:
On 28 August 2012 11:30, Marx acc.for.news@gmail.com wrote:
Are we the only two who have this problem? Marx
Are you watching on VLC over Wifi? Have you tried increasing vlc's HTTP caching? I tend to set it to 'maximum latency', or switch to advanced and increased it to ~4000ms.
I'm watching over GBit-LAN, so no bandwidth problem. I've increased the HTTP caching, I will see if it helps.
Also try accessing streamdev's PES streams (http://example.com:3000/PES/101 ) rather than the TS stream.
My (Windows-)vlc won't play, don't know why. Only TS is working here.
Oh and also try using xineliboutput's streaming of the current channel (http://example.com:37890 ) to see if that works any better.
I'm using softhddevice. Streaming is not so important for me to give up the advantages of softhddevice. :)
Thanks, Lars.
-
Dominic Evans -
Lars Hanisch -
Marx