Re: [vdr] Instability with recordings on VDR-1.7.4 when recording to a NTFS partition
On 03/24/09 01:09, Niedermeier Günter wrote: One question (OT): is it normal that replaying a PES record causes in a very high CPU load on 1.7.2 and higher? - 80-90% on a P4/2400 Replaying TS produces no CPU load. Forget it! This seems to be fixed too since your patch. Could that be possible? I don't think so. The modified code is not involved in replaying, only in recording. Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Instability with recordings on VDR-1.7.4 when recording to a NTFS partition
Replaying TS produces no CPU load. Forget it! This seems to be fixed too since your patch. Could that be possible? I don't think so. The modified code is not involved in replaying, only in recording. However, currently 174 works without high CPU load in my environment. I had no chance to reproduce it again yesterday. In 173 or 172 I can do. Is this a known problem? -Günter -- This message was scanned by ESVA and is believed to be clean. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] VDR-Live plugin
How do you use this from the internet? I have got it working (via Gentoo) on my lan, but I wan't to use it with the extern function of streamdev using my dynamic dns name. I have opened the port but it keeps asking for the username and password (which work at home). I can't work out what config options I might need to set. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR-Live plugin
On Tue, Mar 24, 2009 at 09:44:12AM +0100, Rob Davis wrote: How do you use this from the internet? I have got it working (via Gentoo) on my lan, but I wan't to use it with the extern function of streamdev using my dynamic dns name. I have opened the port but it keeps asking for the username and password (which work at home). I can't work out what config options I might need to set. While you are on your local network go to the live plugins web interface. Select Setup from the top menue Activate Use Authentication. Now you should see three more input fields. Two to change your login credentials and one to set a Local net from which no login will be required. I strongly recommend that you use the login. Otherwise everybody from the internet can access your vdr. (And problably 0wn your whole network. As I understand it the vdr code has hardly been audited for security and due to the plugin architecture a buffer overflow in one plugin would compromises the vdr process that (depending on your setup) may even run as root). If you insist on getting hacked you can set the Local net to something like 0.0.0.0/0 This would disable the password question, no matter where you come from. cheers -henrik ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Instability with recordings on VDR-1.7.4 when recording to a NTFS partition
One question (OT): is it normal that replaying a PES record causes in a very high CPU load on 1.7.2 and higher? - 80-90% on a P4/2400 Replaying TS produces no CPU load. Forget it! This seems to be fixed too since your patch. Could that be possible? I don't think so. The modified code is not involved in replaying, only in recording. Klaus I too can confirm that this has fixed my problem recording to an NTFS Partition. With the patches applied I have successfully recorded two streams simultaneously while playing a third. Thanks. Mark. This is an email from Fujitsu Australia Limited, ABN 19 001 011 427. It is confidential to the ordinary user of the email address to which it was addressed and may contain copyright and/or legally privileged information. No one else may read, print, store, copy or forward all or any of it or its attachments. If you receive this email in error, please return to sender. Thank you. If you do not wish to receive commercial email messages from Fujitsu Australia Limited, please email unsubscr...@au.fujitsu.com ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] power consumption, powertop and wakups per second with a af9015 device, vp7045, and various plugins
Heinrich Langos wrote: now, are there any negative side effects to enabling the pid filter that one has to expect? You cannot receive all channels in the mux at the same time (at least in case there is more than 32 PIDs in the transport stream). is it still possible to record two stations that are send over the same OTA channel? I think in theory yes. One program stream is typically less than 5 Mbit/s and USB1.1 can carry around 12Mbit/s. Anyhow, you are now using USB2.0 with PID-filter which means USB can transfer 480 Mbit/s in theory. AF9015 does have 32 PID-filters which sets some limits. 32 is still more than enough for 2 channels if yes, can reprogramming of the pid filter cause lost packages for a already running recording? No. regards Antti -- http://palosaari.fi/ ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] power consumption, powertop and wakups per second with a af9015 device, vp7045, and various plugins
Heinrich Langos wrote: For completeness and comparability: The Fujitsu Stick (vp7045) still by far beats the af9015 in terms of resource usage with vdr. (13% vs 19% with or 37% without hw pid filter) It doesn't seem to hava a hw pid filter ( at least it doesn't react to the force_pid_filter_usage option. so here are the results with the same setup, using the same channels and the same vdr plugins: vp7045 does not have PID-filters. I think difference comes from different USB-transfer settings. vp7045 uses BULK packet size 4096 and af9015 uses BULK packet size 512 for USB2.0 and BULK packet size 64 for USB1.1. Therefore af9015 sends 8 times more packets than vp7045 (I guess). One thing more you can test - use USB1.1. To force USB1.1 remove USB2.0 driver by rmmod ehci_hcd. After that plug af9015 stick and look from logs it detects USB1.1 and uses PID-filters. af9015 driver now uses smaller packet size for transfer that can change load (bigger?). regards Antti -- http://palosaari.fi/ ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR-Live plugin
Heinrich Langos ha scritto: While you are on your local network go to the live plugins web interface. Select Setup from the top menue Activate Use Authentication. Now you should see three more input fields. Two to change your login credentials and one to set a Local net from which no login will be required. I strongly recommend that you use the login. Otherwise everybody from the internet can access your vdr. (And problably 0wn your whole network. As I understand it the vdr code has hardly been audited for security and due to the plugin architecture a buffer overflow in one plugin would compromises the vdr process that (depending on your setup) may even run as root). If you insist on getting hacked you can set the Local net to something like 0.0.0.0/0 This would disable the password question, no matter where you come from. //www.linuxtv.org/cgi-bin/mailman/listinfo/vdr Thanks Henrick, On further investigation I have sorted it out. In my firewall I'd mistyped the portforward, so it was arriving at vdradmin instead, which uses a different password. I have it working. However, for the next version, is there a way to select two different streamdev profiles quickly. When I am home I would like to select streamdev TS, but when away extern? Also, is there a way to allow a change of language in the vlc plugin, or a way to serve up a file with the url in, for instance stream.m3u with the url in it like a playlist, a bit like a dreambox. This would allow the vlc interface to select language etc. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Instability with recordings on VDR-1.7.4 when recording to a NTFS partition
Klaus Schmidinger kirjoitti: On 23.03.2009 22:13, Klaus Schmidinger wrote: On 23.03.2009 21:42, Niedermeier Günter wrote: Here's a quick shot - totally untested (no time, sorry). Please try it and let me know if it helps. Hi, I've tried it: files are created, but with zero filesize. Only info is correct. After a few seconds vdr is restarting with an emergency exit!. Well, then I guess I do need to spend a little more time on this ;-) I hope the patch does what I thought it would: collects writes in larger chunks. For a networked application, the key performance bottleneck is the number of needed transactions. See e.g. http://portal.acm.org/citation.cfm?id=1066051.1066069 (and the PDF file in there). yours, Jouni ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Instability with recordings on VDR-1.7.4 when recording to a NTFS partition
On 24.03.2009 17:05, Jouni Karvo wrote: Klaus Schmidinger kirjoitti: On 23.03.2009 22:13, Klaus Schmidinger wrote: On 23.03.2009 21:42, Niedermeier Günter wrote: Here's a quick shot - totally untested (no time, sorry). Please try it and let me know if it helps. Hi, I've tried it: files are created, but with zero filesize. Only info is correct. After a few seconds vdr is restarting with an emergency exit!. Well, then I guess I do need to spend a little more time on this ;-) I hope the patch does what I thought it would: collects writes in larger chunks. For a networked application, the key performance bottleneck is the number of needed transactions. See e.g. http://portal.acm.org/citation.cfm?id=1066051.1066069 (and the PDF file in there). That's exactly what the fix does - and apparently it works, judging from the feedback. Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Instability with recordings on VDR-1.7.4 when recording to a NTFS partition
On 24.03.2009 09:22, Niedermeier Günter wrote: Replaying TS produces no CPU load. Forget it! This seems to be fixed too since your patch. Could that be possible? I don't think so. The modified code is not involved in replaying, only in recording. However, currently 174 works without high CPU load in my environment. I had no chance to reproduce it again yesterday. In 173 or 172 I can do. Is this a known problem? Not to my knowledge. But since it works better in version 1.7.4, that's a step in the right direction, I'd say ;-) Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR-Live plugin
Hello Am Dienstag, 24. März 2009 schrieb Rob Davis: [...] I have it working. However, for the next version, is there a way to select two different streamdev profiles quickly. When I am home I would like to select streamdev TS, but when away extern? Sorry, that is currently not possible. Unfortunately there is only one 'user' accessing the LIVE plugin - as you can set only one password. There exist thoughts/proposals on implementing a multi-user feature in LIVE. This would enable the addition of individual settings for each user. Kind regards Dieter -- Dieter Hametnerdh (plus) vdr (at) gekrumbel (dot) de live plugin developer http://live.vdr-developer.org ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] power consumption, powertop and wakups per second with a af9015 device, vp7045, and various plugins
Moikka Antti, vp7045 does not have PID-filters. I think difference comes from different USB-transfer settings. vp7045 uses BULK packet size 4096 and af9015 uses BULK packet size 512 for USB2.0 and BULK packet size 64 for USB1.1. Therefore af9015 sends 8 times more packets than vp7045 (I guess). One thing more you can test - use USB1.1. To force USB1.1 remove USB2.0 driver by rmmod ehci_hcd. After that plug af9015 stick and look from logs it detects USB1.1 and uses PID-filters. af9015 driver now uses smaller packet size for transfer that can change load (bigger?). without ehci_usb i get this on loading af9015-dvb-usb : [211324.238031] ehci_hcd :00:1d.7: remove, state 1 [211324.238227] usb usb5: USB disconnect, address 1 [211324.238340] usb 5-1: USB disconnect, address 7 [211324.245523] ehci_hcd :00:1d.7: USB bus 5 deregistered [211324.245837] ACPI: PCI interrupt for device :00:1d.7 disabled [211324.524157] usb 1-1: new full speed USB device using uhci_hcd and address 4 [211324.702426] usb 1-1: configuration #1 chosen from 1 choice [211324.708807] usb 1-1: New USB device found, idVendor=15a4, idProduct=9016 [211324.708965] usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [211324.709152] usb 1-1: Product: DVB-T 2 [211324.709275] usb 1-1: Manufacturer: Afatech [211324.709381] usb 1-1: SerialNumber: 01010101061 [211325.692779] dvb-usb: found a 'Afatech AF9015 DVB-T USB2.0 stick' in warm state. [211325.692779] dvb-usb: will use the device's hardware PID filter (table count: 32). [211325.697043] DVB: registering new adapter (Afatech AF9015 DVB-T USB2.0 stick) [211326.428116] af9013: firmware version:4.95.0 [211326.448011] DVB: registering adapter 0 frontend 0 (Afatech AF9013 DVB-T)... [211326.448011] tda18271 0-00c0: creating new instance [211326.455236] TDA18271HD/C2 detected @ 0-00c0 [211326.890065] dvb-usb: Afatech AF9015 DVB-T USB2.0 stick successfully initialized and connected. [211326.933817] usbcore: registered new interface driver dvb_usb_af9015 loading the module seems to cause polling each 250ms: = PowerTOP version 1.10 (C) 2007 Intel Corporation CnAvg residency P-states (frequencies) C0 (cpu running)( 0.2%) 750 Mhz 0.0% polling 0.0ms ( 0.0%) 563 Mhz 0.0% C1 halt 0.0ms ( 0.0%) 375 Mhz 0.0% C20.0ms ( 0.0%) 188 Mhz 100.0% C3 118.1ms (99.8%) Wakeups-from-idle per second : 8.4 interval: 20.0s no ACPI power usage estimate available Top causes for wakeups: 37.0% ( 4.0) kernel module : usb_hcd_poll_rh_status (rh_timer_func) 18.5% ( 2.0) xfsaild : schedule_timeout (process_timeout) 15.7% ( 1.7) xfsbufd : schedule_timeout (process_timeout) 9.3% ( 1.0) ifconfig : b44_open (b44_timer) running zap causes a load between 1.0 and 1.4% running zap PowerTOP version 1.10 (C) 2007 Intel Corporation CnAvg residency P-states (frequencies) C0 (cpu running)( 1.0%) 750 Mhz 0.0% polling 0.0ms ( 0.0%) 563 Mhz 0.0% C1 halt 0.0ms ( 0.0%) 375 Mhz 0.0% C20.1ms ( 0.0%) 188 Mhz 100.0% C3 14.5ms (99.0%) Wakeups-from-idle per second : 68.5 interval: 15.0s no ACPI power usage estimate available Top causes for wakeups: 55.5% ( 84.6) USB device 1-1 : DVB-T 2 (Afatech) 32.3% ( 49.2) interrupt : uhci_hcd:usb1, HDA Intel 3.6% ( 5.5) zap : schedule_timeout (process_timeout) 2.7% ( 4.1) kernel module : usb_hcd_poll_rh_status (rh_timer_func) 1.3% ( 2.0) xfsaild : schedule_timeout (process_timeout) 1.1% ( 1.7) xfsbufd : schedule_timeout (process_timeout) 0.7% ( 1.1)kdvb-ad-0-fe-0 : schedule_timeout (process_timeout) 0.7% ( 1.0) zap : do_nanosleep (hrtimer_wakeup) == and here's the load with idle vdr. running vdr PowerTOP version 1.10 (C) 2007 Intel Corporation CnAvg residency P-states (frequencies) C0 (cpu running)(32.2%) 750 Mhz 0.0% polling 0.0ms ( 0.0%)
Re: [vdr] power consumption, powertop and wakups per second with a af9015 device, vp7045, and various plugins
Heinrich Langos wrote: Moikka Antti, vp7045 does not have PID-filters. I think difference comes from different USB-transfer settings. vp7045 uses BULK packet size 4096 and af9015 uses BULK packet size 512 for USB2.0 and BULK packet size 64 for USB1.1. Therefore af9015 sends 8 times more packets than vp7045 (I guess). One thing more you can test - use USB1.1. To force USB1.1 remove USB2.0 driver by rmmod ehci_hcd. After that plug af9015 stick and look from logs it detects USB1.1 and uses PID-filters. af9015 driver now uses smaller packet size for transfer that can change load (bigger?). seems you are right. The transfer with PID filter in usb 1.1 causes about 30% load in contrast to 19% with usb 2.0 is there a way to increase the packet size for those bulk transfers? for usb 2.0? for 1.1? Actually AF9015 chip offers registers to configure packet size. But those which are now used are default ones and rather many devices (other than af9015) are using just same. That's why I am not sure if I want change those to bigger ones. I will make test version that uses 4k packets for your tests. If it resolves problem then we should consider for example adding module param for setting desirable packet size. I will inform you when test version is ready - It takes day or two. regards Antti -- http://palosaari.fi/ ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
