search

manio / vdr-plugin-dvbapi

VDR dvbapi plugin for use with OSCam
http://www.streamboard.tv/wbb2/thread.php?threadid=40060
GNU General Public License v2.0
58 stars 25 forks source link

High CPU-Load when record a view HD-Streams #43

Closed MegaV0lt closed 10 years ago

MegaV0lt commented 10 years ago

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.

MegaV0lt commented 10 years ago

here is a benchmark from libdvbcsa:

hdvdr01 test # ./benchenc

hdvdr01 test # ./benchdec

manio commented 10 years ago

Does it work without this problems on previous plugin versions?

MegaV0lt commented 10 years ago

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

manio commented 10 years ago

Ok - one additional question: Isn't it that before a decoding was done using multiple cores, while now it uses one core?

Christian-MLD commented 10 years ago

hi manio, I think this is the same problem as mine. :)

manio commented 10 years ago

@Christian-MLD I know it may be related. Please also test the two configurations I've sent you via email.

MegaV0lt commented 10 years ago

@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

manio commented 10 years ago

@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?

MegaV0lt commented 10 years ago

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

manio commented 10 years ago

@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...

manio commented 10 years ago

@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.

Christian-MLD commented 10 years ago

yes I do. I can only compile and Test at home. my free time starts after bedtime of children ;)

imperia777 commented 10 years ago

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.

manio commented 10 years ago

@imperia777 I assume you have same problem.

Ok guys - another fix is now in the perftest. Please try it again.

MegaV0lt commented 10 years ago

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!

manio commented 10 years ago

@MegaV0lt Ok. Please revert my plugin to master and apply this patch to clean VDR 2.1.4: http://skyboo.net/p2.diff

MegaV0lt commented 10 years ago

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

manio commented 10 years ago

So it is at the same level as it was on my old plugin version?

MegaV0lt commented 10 years ago

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?

manio commented 10 years ago

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.

manio commented 10 years ago

@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?

MegaV0lt commented 10 years ago

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

MegaV0lt commented 10 years ago

see here : http://i.imgur.com/uhsdcyP.png

i think is ok.

manio commented 10 years ago

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 :)

MegaV0lt commented 10 years ago

p2.diff is now different... what is then reason? should i revert the first p2 and test with the new one?

manio commented 10 years ago

@MegaV0lt Yes, please apply it on clean vdr 2.1.4.

manio commented 10 years ago

Hold on - there is a new conception of this change. I'll do it in the plugin instead of VDR. Stay tuned.

MegaV0lt commented 10 years ago

Ok, with last p2.diff looks good with 8 recordings in hd: http://i.imgur.com/F7ZOewT.png

MegaV0lt commented 10 years ago

...so i was a few minutes too fast

manio commented 10 years ago

@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.

MegaV0lt commented 10 years ago

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 ;)

imperia777 commented 10 years ago

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.

manio commented 10 years ago

@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.

manio commented 10 years ago

@imperia777 Is it now working better after you compile everything from scratch?

imperia777 commented 10 years ago

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) 205

VDR 2.1.4 with 1 stream(encrypted) 214

huge difference. if that's the future of VDR + dvbapi. I am stuck in the past :(

Christian-MLD commented 10 years ago

image

The CPU load is ok, but the Problem with the FF Card is still there.

manio commented 10 years ago

@imperia777 You also have a FF card?

manio commented 10 years ago

@imperia777 @Christian-MLD What if you additionally try this patch on VDR: http://skyboo.net/pidrecv.diff

imperia777 commented 10 years ago

sorry but what is FF card? Mine is TBS QBOX 5922 USB, do you still want me to try the above patch?

manio commented 10 years ago

Yes, please try this patch. FF is a FullFeatured card. You don't have it.

imperia777 commented 10 years ago

I see. with hardware decoder. brb

imperia777 commented 10 years ago

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?

manio commented 10 years ago

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?

imperia777 commented 10 years ago

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.

manio commented 10 years ago

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).

imperia777 commented 10 years ago

Ok. Thanks. Will do now.

Christian-MLD commented 10 years ago

My Test: with patch -> Blackscreen "Channel Not availible" without Patch and 10 Buffer -> no improvement

manio commented 10 years ago

@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?

imperia777 commented 10 years ago

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.

manio commented 10 years ago

@imperia777 Can you redo this same test but with dvbapi loglevel set to 3 and share your log?