Closed MegaV0lt closed 10 years ago
here is a benchmark from libdvbcsa:
hdvdr01 test # ./benchenc
hdvdr01 test # ./benchdec
Does it work without this problems on previous plugin versions?
with vdr 2.1.3 and 6 hd recording the vdr process has ~50% on one core. plugin is teh last before 2.0 http://i.imgur.com/7ZURGG3.png
Ok - one additional question: Isn't it that before a decoding was done using multiple cores, while now it uses one core?
hi manio, I think this is the same problem as mine. :)
@Christian-MLD I know it may be related. Please also test the two configurations I've sent you via email.
@manio i do not understand what you mean with cores? any way to set that it should use all cores? i also switched to ffdecsa back, same result with plugin2.0 and vdr 2.1.4
PS: is a amd 4850e with 2x2,5GHz
@MegaV0lt By cores I mean CPU cores. Look at your htop screenshot - can you see the Line for CPU1 and CPU2? I mean this.
What if you switch to my perftest branch?
ok, made test with perftest. already at 4 recordings i got errors and füll cpu load: http://i.imgur.com/qBr3XnX.png
Jan 30 12:45:54 [vdr] [24347] ERROR: driver buffer overflow on device 1
@MegaV0lt Please update my perftest branch and redo the test. I hope it's ok for you to testing my patches? I am trying to find the cause this way...
@Christian-MLD Please also test it - if it will not work I have some new ideas. But i want to know if it is now better with my perftest branch.
yes I do. I can only compile and Test at home. my free time starts after bedtime of children ;)
Hello. I just tested your perftest branch. I can't say its better. 100% CPU usage. I am willing to test patches and provide logs.
@imperia777 I assume you have same problem.
Ok guys - another fix is now in the perftest. Please try it again.
hm... no picture at all here:
Jan 31 11:08:42 [vdr] [20752] switching to channel 56 Jan 31 11:08:42 [vdr] [20752] [softhddev]SetPlayMode: 0 Jan 31 11:08:42 [vdr] [20752] [softhddev]SetVideoDisplayFormat: 0 Jan 31 11:08:42 [vdr] [20752] [softhddev]GetSpuDecoder: Jan 31 11:08:42 [vdr] audio/alsa: using device 'hw:NVidia,0' Jan 31 11:08:42 [vdr] audio/alsa: start delay 361ms_ Jan 31 11:08:42 [vdr] [20752] DVBAPI: 0.0 CA_PMT decoding len=17e lm=5 prg=61300 len=178 Jan 31 11:08:42 [vdr] [20752] DVBAPI: ci_cmd(G)=01 Jan 31 11:08:42 [vdr] [20752] DVBAPI: 0.0 got CA pmt ciCmd=1 caLm=5 Jan 31 11:08:42 [vdr] [20752] DVBAPI: 0.0 answer to query surpressed Jan 31 11:08:42 [vdr] [20752] DVBAPI: 0.0 set CAM decrypt (SID 61300, caLm 5, HasCaDescriptors 1) Jan 31 11:08:42 [vdr] [20752] DVBAPI: 0.0 CA_PMT decoding len=6 lm=3 prg=0 len=0 Jan 31 11:08:42 [vdr] [20752] DVBAPI: 0.0 got CA pmt ciCmd=-1 caLm=3 Jan 31 11:08:42 [vdr] [20752] DVBAPI: 0.0 answer to query surpressed Jan 31 11:08:42 [vdr] [20752] DVBAPI: 0.0 stop decrypt Jan 31 11:08:42 [vdr] [20752] CAM 1: unassigned Jan 31 11:08:42 [vdr] [25510] osdteletext-receiver thread ended (pid=20752, tid=25510) Jan 31 11:08:42 [vdr] [20752] buffer stats: 0 (0%) used Jan 31 11:08:42 [vdr] [25511] TS buffer on device 1 thread ended (pid=20752, tid=25511) Jan 31 11:08:42 [vdr] [25509] buffer stats: 199092 (3%) used Jan 31 11:08:42 [vdr] [25509] receiver on device 1 thread ended (pid=20752, tid=25509) Jan 31 11:08:42 [vdr] [20752] CAM 1: assigned to device 1 Jan 31 11:08:42 [vdr] [20752] DVBAPI: 0.0 CA_PMT decoding len=188 lm=4 prg=61303 len=178 Jan 31 11:08:42 [vdr] [20752] DVBAPI: ci_cmd(G)=01 Jan 31 11:08:42 [vdr] [20752] DVBAPI: pid=2,03ff len=0 (0x0) Jan 31 11:08:42 [vdr] [20752] DVBAPI: pid=6,0403 len=0 (0x0) Jan 31 11:08:42 [vdr] [20752] DVBAPI: 0.0 got CA pmt ciCmd=1 caLm=4 Jan 31 11:08:42 [vdr] [20752] DVBAPI: 0.0 answer to query surpressed Jan 31 11:08:42 [vdr] [20752] DVBAPI: 0.0 set CAM decrypt (SID 61303, caLm 4, HasCaDescriptors 1) Jan 31 11:08:42 [vdr] [20752] DVBAPI: send: channelSid=0xef77 (61303) Jan 31 11:08:42 [vdr] [20752] DVBAPI: created socket with socket_fd=41 Jan 31 11:08:42 [vdr] [20752] DVBAPI: socketfd=41 toWrite=402 wrote=402 Jan 31 11:08:42 [vdr] [25702] receiver on device 1 thread started (pid=20752, tid=25702, prio=high) Jan 31 11:08:42 [vdr] [25703] TS buffer on device 1 thread started (pid=20752, tid=25703, prio=high) Jan 31 11:08:42 [vdr] [20752] creating directory /dev/shm/osdteletext/S19.2E-1-1017-61303 Jan 31 11:08:42 [vdr] [25704] osdteletext-receiver thread started (pid=20752, tid=25704, prio=high) Jan 31 11:08:43 [vdr] [20752] [softhddev]SetPlayMode: 1 Jan 31 11:08:43 [vdr] audio/alsa: using device 'hw:NVidia,0' Jan 31 11:08:43 [vdr] audio/alsa: start delay 361ms Jan 31 11:08:43 [vdr] [20963] DVBAPI: Action: Got CA_SET_PID request, adapter_index=0 Jan 31 11:08:43 [vdr] [20963] DVBAPI: 0.0: set pid 03ff Jan 31 11:08:43 [vdr] [20963] DVBAPI: Action: Got CA_SET_PID request, adapter_index=0 Jan 31 11:08:43 [vdr] [20963] DVBAPI: 0.0: set pid 0403 Jan 31 11:08:43 [vdr] [20963] DVBAPI: Action: Got CA_SET_DESCR request, adapter_index=0 Jan 31 11:08:43 [vdr] [20963] DVBAPI: SetDescr Jan 31 11:08:43 [vdr] [20963] DVBAPI: 0.0: even key set Jan 31 11:08:43 [vdr] [20963] DVBAPI: Action: Got CA_SET_DESCR request, adapter_index=0 Jan 31 11:08:43 [vdr] [20963] DVBAPI: SetDescr Jan 31 11:08:43 [vdr] [20963] DVBAPI: 0.0: odd key set
Blank screen!
@MegaV0lt Ok. Please revert my plugin to master and apply this patch to clean VDR 2.1.4: http://skyboo.net/p2.diff
Patch applied. Now with 7 hd recordings it looks like this: http://i.imgur.com/uhsdcyP.png
but with 8 i have some: Jan 31 11:47:16 [vdr] [22780] DVBAPI: Action: Got CA_SET_DESCR request, adapterindex=0 Jan 31 11:47:16 [vdr] [22780] DVBAPI: SetDescr Jan 31 11:47:16 [vdr] [22780] DVBAPI: 0.0: even key set Jan 31 11:47:16 [vdr] [4646] buffer usage: 80% (tid=4644) Jan 31 11:47:17 [vdr] video: slow down video, duping frame Jan 31 11:47:17 [vdr] video/vdpau: missed frame (37/348) Jan 31 11:47:17 [vdr] video/vdpau: missed frame (38/348) Jan 31 11:47:17 [vdr] video: slow down video, duping frame Jan 31 11:47:17 [vdr] video: 9:23:17.095 +558 167 0/\ms 0+5 v-buf Jan 31 11:47:17 [vdr] video: decoder buffer empty, duping frame (899/348) 1 v-buf Jan 31 11:47:17 [vdr] video: 9:23:17.095 +535 144 0/\ms 1+5 v-buf Jan 31 11:47:17 [vdr] video/vdpau: missed frame (39/350) Jan 31 11:47:17 [vdr] video: slow down video, duping frame Jan 31 11:47:17 [vdr] video: 9:23:17.095 +507 111 0/\ms 0+7 v-buf Jan 31 11:47:17 [vdr] video/vdpau: missed frame (40/350) Jan 31 11:47:17 [vdr] [27853] ERROR: driver buffer overflow on device 1 Jan 31 11:47:17 [vdr] video: slow down video, duping frame Jan 31 11:47:17 [vdr] video: 9:23:17.115 +446 0 0/\ms 0+6 v-buf Jan 31 11:47:17 [vdr] video/vdpau: missed frame (41/350) Jan 31 11:47:17 [vdr] video: decoder buffer empty, duping frame (902/350) 1 v-buf Jan 31 11:47:17 [vdr] video: 9:23:17.135+8888 0 0/\ms 1+5 v-buf Jan 31 11:47:17 [vdr] video/vdpau: missed frame (42/352) Jan 31 11:47:17 [vdr] video: decoder buffer empty, duping frame (903/356) 0 v-buf Jan 31 11:47:17 [vdr] video: 9:23:17.255+8888 0 0/\ms 0+5 v-buf Jan 31 11:47:17 [vdr] [22780] DVBAPI: Action: Got CA_SET_DESCR request, adapterindex=0 Jan 31 11:47:17 [vdr] [22780] DVBAPI: SetDescr Jan 31 11:47:17 [vdr] [22780] DVBAPI: 0.1: even key set Jan 31 11:47:17 [vdr] [4646] buffer usage: 90% (tid=4644) Jan 31 11:47:17 [vdr] audio/alsa: wait underrun error? 'Datenübergabe unterbrochen (broken pipe)' Jan 31 11:47:17 [vdr] video: decoder buffer empty, duping frame (910/360) 0 v-buf Jan 31 11:47:17 [vdr] video: slow down video, duping frame Jan 31 11:47:17 [vdr] video: 9:23:17.435 +698 382 0/\ms 0+6 v-buf_ Jan 31 11:47:17 [vdr] [22780] DVBAPI: Action: Got CA_SET_DESCR request, adapter_index=0 Jan 31 11:47:17 [vdr] [22780] DVBAPI: SetDescr Jan 31 11:47:17 [vdr] [22780] DVBAPI: 0.3: odd key set Jan 31 11:47:18 [vdr] [27851] ERROR: skipped 59 bytes to sync on TS packet on device 1 Jan 31 11:47:18 [vdr] [27851] ERROR: skipped 2 bytes to sync on TS packet on device 1 Jan 31 11:47:18 [vdr] [27851] ERROR: skipped 62 bytes to sync on TS packet on device 1 Jan 31 11:47:18 [vdr] [27853] buffer usage: 60% (tid=27851) Jan 31 11:47:18 [vdr] [4646] buffer usage: 60% (tid=4644) Jan 31 11:47:19 [vdr] [27853] i/o throttle released, count = 1 (tid=27853)
in my enviorment i have up to 9 simultan recordings. a chance to optimice taht more? At least the lat patch runs miuch better , thanks
So it is at the same level as it was on my old plugin version?
not 100% sure. but max. 7 recordings? what about the p2 patch? coes the patch to vdr in 2.1.5? or do we have to patch all futuer versions?
It is now not about patching further VDR versions. I am only want to see where is the problem. That's why I am asking if with VDR patch it is the same as it was with my old plugin.
@MegaV0lt You said: "with vdr 2.1.3 and 6 hd recording the vdr process has ~50% on one core" and now you have max 7 recordings, right? The CPU usage is the same?
Well, i thinkk so. before patch only 3 recordings were possible at one time. now first test with 7 recordings is ok wit p2 patch and 2.0 plugin (master). Nest step is probably to get max performace
see here : http://i.imgur.com/uhsdcyP.png
i think is ok.
Ok ok ... but now I want to have "the same" performance as with the old plugin version.
@all Please patch your VDRs with this file: http://skyboo.net/p2.diff and let me know if this was a problem. I finally hope so :)
p2.diff is now different... what is then reason? should i revert the first p2 and test with the new one?
@MegaV0lt Yes, please apply it on clean vdr 2.1.4.
Hold on - there is a new conception of this change. I'll do it in the plugin instead of VDR. Stay tuned.
Ok, with last p2.diff looks good with 8 recordings in hd: http://i.imgur.com/F7ZOewT.png
...so i was a few minutes too fast
@MegaV0lt A little - but good that you're such a great tester ;) You can now recheck with clean VDR2.1.4 (without any patch) and my perftest branch.
so, i run a little bit out of tim, but finaly i made it. now test 8 hd recordings with vdr 2.1.4 and perftest http://i.imgur.com/l6w4cqy.png
Looks good so far ;)
i've just tested perftest branch. this time the stream at least starts.. but the cpu usage is still 100% on my eeepc @900mhz.. before I was able to stream at least 2-3 encrypted streams. I will download vdr-2.1.4 again and start over.. in case something left from my experiments :) will try to report again in 30 minutes.
@imperia777 Yes please try it, but I am afraid I cannot do more in this case. If you look at my graph: http://skyboo.net/vdr_cpu.png You can see that on the right is cpu usage with my patch applied (perftest), on the left - without it (current master). The right result is the same as cpu usage on vdr plugin version v1.0.6 and older VDR.
@imperia777 Is it now working better after you compile everything from scratch?
I just tried 2.1.4 with perftest again. vdr occupies 100% cpu with one encrypted HD stream. yesterday: the stream wasn't starting at all. today I can run 1 or 2 streams.. but the CPU usage is 100% and log shows "ring buffer overflows" errors.
VDR 2.0.5 with 2 HD streams(encrypted)
VDR 2.1.4 with 1 stream(encrypted)
huge difference. if that's the future of VDR + dvbapi. I am stuck in the past :(
The CPU load is ok, but the Problem with the FF Card is still there.
@imperia777 You also have a FF card?
@imperia777 @Christian-MLD What if you additionally try this patch on VDR: http://skyboo.net/pidrecv.diff
sorry but what is FF card? Mine is TBS QBOX 5922 USB, do you still want me to try the above patch?
Yes, please try this patch. FF is a FullFeatured card. You don't have it.
I see. with hardware decoder. brb
Jan 31 19:25:02 eeepc vdr: [4824] Streamdev: Accepted new client (HTTP) 192.168.0.2:54284 Jan 31 19:25:02 eeepc vdr: [4824] CAM 1: assigned to device 1 Jan 31 19:25:02 eeepc vdr: [4841] streamdev-livestreaming thread started (pid=4817, tid=4841, prio=high) Jan 31 19:25:02 eeepc vdr: [4840] streamdev-writer thread started (pid=4817, tid=4840, prio=high) Jan 31 19:25:02 eeepc vdr: [4824] DVBAPI: 0.0 set CAM decrypt (SID 30761, caLm 4, HasCaDescriptors 1) Jan 31 19:25:02 eeepc vdr: [4842] receiver on device 1 thread started (pid=4817, tid=4842, prio=high) Jan 31 19:25:02 eeepc vdr: [4843] TS buffer on device 1 thread started (pid=4817, tid=4843, prio=high) Jan 31 19:25:03 eeepc vdr: [4823] Adding pid 208 (type 0xc0) RegDesc not found -> assume AC-3 Jan 31 19:25:03 eeepc vdr: [4823] Adding pid 309 (type 0xc0) RegDesc not found -> assume AC-3 Jan 31 19:25:03 eeepc vdr: [4823] Adding pid 253 (type 0xc1) RegDesc not found -> assume AC-3 Jan 31 19:25:03 eeepc vdr: [4823] Adding pid 307 (type 0xc1) RegDesc not found -> assume AC-3 Jan 31 19:25:03 eeepc vdr: [4823] Adding pid 356 (type 0xc1) RegDesc not found -> assume AC-3 Jan 31 19:25:03 eeepc vdr: [4823] Adding pid 392 (type 0xc1) RegDesc not found -> assume AC-3 Jan 31 19:25:03 eeepc vdr: [4823] Adding pid 616 (type 0xc1) RegDesc not found -> assume AC-3 Jan 31 19:25:03 eeepc vdr: [4823] Adding pid 888 (type 0xc1) RegDesc not found -> assume AC-3 Jan 31 19:25:07 eeepc vdr: [4842] DVBAPI: 0.0 set CAM decrypt (SID 30761, caLm 5, HasCaDescriptors 0) Jan 31 19:25:07 eeepc vdr: [4842] CAM 1: unassigned Jan 31 19:25:07 eeepc vdr: [4843] TS buffer on device 1 thread ended (pid=4817, tid=4843) Jan 31 19:25:07 eeepc vdr: [4842] buffer stats: 129532 (2%) used Jan 31 19:25:07 eeepc vdr: [4842] receiver on device 1 thread ended (pid=4817, tid=4842) Jan 31 19:25:08 eeepc vdr: [4823] ERROR: 1 ring buffer overflow (188 bytes dropped) Jan 31 19:25:09 eeepc vdr: [4840] streamdev-server: streamer done - writer exiting Jan 31 19:25:09 eeepc vdr: [4840] streamdev-server: closing HTTP connection to 192.168.0.2:54284 Jan 31 19:25:09 eeepc vdr: [4840] streamdev-writer thread ended (pid=4817, tid=4840) Jan 31 19:25:09 eeepc vdr: [4841] streamdev-livestreaming thread ended (pid=4817, tid=4841) Jan 31 19:25:09 eeepc vdr: [4824] buffer stats: 129908 (3%) used
i see VLC start buffering and then nothing. i just did 'make' in VDR directory and copied vdr to /usr/bin. I saw make compiling only ci.c. should be enough? if you say i will recompile everything from scratch. Is ci.c related to dvbapi plugin. do i need to recompile it too?
Yes, the change was only in ci.c. Ah - you're using streamdev. Maybe the problem is with it (network streaming plugin has to be fixed to use with dvbapi). Can you just try to start some recordings and see if its ok after?
I am not sure how to initiate recording on headless server. Will try to find out how to do it and will do some recording.
maybe you are right about streamdev. all i know is, streamdev works on FTA channels and on all channels with vdr 2.0.5.
FTA channels are a different (trivial) story and doesn't need dvbapi at all :) VDR 2.0.5 doesn't need any changes in streamdev.
You can use eg ncurses plugin for interacting with VDR. Or telnet to SVDRP port (telnet IP 6419), there is a command to create a timer. Or even put a line into timers.conf (but you have to do it right and only when VDR is not running).
Ok. Thanks. Will do now.
My Test: with patch -> Blackscreen "Channel Not availible" without Patch and 10 Buffer -> no improvement
@Christian-MLD Am I understand correctly: when you're recording than it is ok and you can do simultaneous recordings and when you're watching it than it is ok, right? The problem is only with live view?
Jan 31 20:42:51 eeepc vdr: [9589] timer 1 (2998 2041-2044 'test3.ts') start Jan 31 20:42:51 eeepc vdr: [9589] Title: 'NBA.NEW YORK KNICKS - CLEVELAN' Subtitle: '' Jan 31 20:42:51 eeepc vdr: [9589] executing '/usr/lib/vdr/vdr-recordingaction before "/var/lib/video.00/test3.ts/2014-01-31.20.41.2998-0.rec"' Jan 31 20:42:51 eeepc recordingaction: executing /usr/share/vdr/recording-hooks/R90.custom before recording /var/lib/video.00/test3.ts/2014-01-31.20.41.2998-0.rec as shell script Jan 31 20:42:51 eeepc vdr: [9589] record /var/lib/video.00/test3.ts/2014-01-31.20.41.2998-0.rec Jan 31 20:42:51 eeepc vdr: [9589] cFileName::SetOffset: removing zero-sized file /var/lib/video.00/test3.ts/2014-01-31.20.41.2998-0.rec/00001.ts Jan 31 20:42:51 eeepc vdr: [9589] recording to '/var/lib/video.00/test3.ts/2014-01-31.20.41.2998-0.rec/00001.ts' Jan 31 20:42:51 eeepc vdr: [9680] recording thread started (pid=9589, tid=9680, prio=high) Jan 31 20:42:51 eeepc vdr: [9589] DVBAPI: 0.0 set CAM decrypt (SID 30760, caLm 4, HasCaDescriptors 1) Jan 31 20:42:51 eeepc vdr: [9681] receiver on device 1 thread started (pid=9589, tid=9681, prio=high) Jan 31 20:42:51 eeepc vdr: [9682] TS buffer on device 1 thread started (pid=9589, tid=9682, prio=high) Jan 31 20:42:53 eeepc vdr: [9682] i/o throttle activated, count = 1 (tid=9682) Jan 31 20:42:54 eeepc vdr: [9682] buffer usage: 70% (tid=9681) Jan 31 20:42:54 eeepc vdr: [9682] buffer usage: 80% (tid=9681) Jan 31 20:42:54 eeepc vdr: [9682] buffer usage: 90% (tid=9681) Jan 31 20:42:55 eeepc vdr: [9682] buffer usage: 100% (tid=9681) Jan 31 20:42:56 eeepc vdr: [9682] ERROR: driver buffer overflow on device 1 Jan 31 20:42:59 eeepc vdr: [9682] ERROR: driver buffer overflow on device 1 Jan 31 20:43:00 eeepc vdr: [9682] ERROR: driver buffer overflow on device 1 Jan 31 20:43:02 eeepc vdr: [9682] ERROR: driver buffer overflow on device 1 Jan 31 20:43:04 eeepc vdr: [9682] ERROR: driver buffer overflow on device 1 Jan 31 20:43:05 eeepc vdr: [9682] ERROR: driver buffer overflow on device 1 Jan 31 20:43:05 eeepc vdr: [9680] executing '/usr/lib/vdr/vdr-recordingaction started "/var/lib/video.00/test3.ts/2014-01-31.20.41.2998-0.rec"' Jan 31 20:43:05 eeepc recordingaction: executing /usr/share/vdr/recording-hooks/R90.custom as shell script Jan 31 20:43:07 eeepc vdr: [9682] ERROR: driver buffer overflow on device 1 Jan 31 20:43:09 eeepc vdr: [9682] ERROR: driver buffer overflow on device 1 Jan 31 20:43:10 eeepc vdr: [9682] ERROR: driver buffer overflow on device 1 Jan 31 20:43:12 eeepc vdr: [9682] ERROR: driver buffer overflow on device 1 Jan 31 20:43:14 eeepc vdr: [9681] ERROR: skipped 21 bytes to sync on TS packet on device 1 Jan 31 20:43:14 eeepc vdr: [9681] ERROR: skipped 102 bytes to sync on TS packet on device 1 Jan 31 20:43:15 eeepc vdr: [9682] ERROR: driver buffer overflow on device 1 Jan 31 20:43:16 eeepc vdr: [9682] ERROR: driver buffer overflow on device 1 Jan 31 20:43:17 eeepc vdr: [9682] ERROR: driver buffer overflow on device 1 Jan 31 20:43:19 eeepc vdr: [9682] ERROR: driver buffer overflow on device 1 Jan 31 20:43:20 eeepc vdr: [9589] connect from 127.0.0.1, port 58413 - accepted Jan 31 20:43:20 eeepc vdr: [9682] ERROR: driver buffer overflow on device 1 Jan 31 20:43:23 eeepc vdr: [9682] ERROR: driver buffer overflow on device 1 Jan 31 20:43:26 eeepc vdr: [9682] ERROR: driver buffer overflow on device 1 Jan 31 20:43:27 eeepc vdr: [9682] ERROR: driver buffer overflow on device 1 Jan 31 20:43:30 eeepc vdr: [9682] ERROR: driver buffer overflow on device 1 Jan 31 20:43:32 eeepc vdr: [9681] ERROR: skipped 6 bytes to sync on TS packet on device 1 Jan 31 20:43:32 eeepc vdr: [9681] ERROR: skipped 66 bytes to sync on TS packet on device 1 Jan 31 20:43:32 eeepc vdr: [9681] ERROR: skipped 30 bytes to sync on TS packet on device 1 Jan 31 20:43:32 eeepc vdr: [9681] ERROR: skipped 21 bytes to sync on TS packet on device 1 Jan 31 20:43:34 eeepc vdr: [9682] ERROR: driver buffer overflow on device 1 Jan 31 20:43:36 eeepc vdr: [9682] ERROR: driver buffer overflow on device 1 Jan 31 20:43:38 eeepc vdr: [9682] ERROR: driver buffer overflow on device 1 Jan 31 20:43:40 eeepc vdr: [9682] ERROR: driver buffer overflow on device 1 Jan 31 20:43:42 eeepc vdr: [9682] ERROR: driver buffer overflow on device 1 Jan 31 20:43:43 eeepc vdr: [9682] ERROR: driver buffer overflow on device 1 Jan 31 20:43:47 eeepc vdr: [9682] ERROR: driver buffer overflow on device 1 Jan 31 20:43:50 eeepc vdr: [9681] ERROR: skipped 123 bytes to sync on TS packet on device 1 Jan 31 20:43:52 eeepc vdr: [9682] ERROR: driver buffer overflow on device 1 Jan 31 20:43:54 eeepc vdr: [9682] ERROR: driver buffer overflow on device 1 Jan 31 20:43:56 eeepc vdr: [9682] ERROR: driver buffer overflow on device 1 Jan 31 20:43:57 eeepc vdr: [9682] ERROR: driver buffer overflow on device 1 Jan 31 20:43:59 eeepc vdr: [9682] ERROR: driver buffer overflow on device 1 Jan 31 20:44:00 eeepc vdr: [9680] recording thread ended (pid=9589, tid=9680)
while its recording .. 100% cpu usage still. vdr cancel the recording after few seconds and retries. in the video folder i see few megabytes test file has been recorded.
@imperia777 Can you redo this same test but with dvbapi loglevel set to 3 and share your log?
I set up 2.1.4 and had a viuew recordings in hd. Then i got vdsb and i was lloking at the log. there is many device buffer overflows and htop shows 100% of vdr cpu usage. short log: https://dl.dropboxusercontent.com/u/1490505/VDR/G2V_V4/info.txt Full package with more informations: https://dl.dropboxusercontent.com/u/1490505/VDR/G2V_V4/VDSB_1391022845.tar.xz I was using dvbapi 2.0 latest git with libdvbcsa enabled.