vdr March 2009

vdr@linuxtv.org

96 participants
72 discussions

Start a nNew thread

[patch] softplay+vdr-1.7.4
by ua0lnj 20 Mar '09

20 Mar '09

Hi This is a patch for softplay in cvs, for vdr-1.7.4 It's works for me.

1 0

Instability with recordings on VDR-1.7.4 when recording to a NTFS partition
by Hawes, Mark 20 Mar '09

20 Mar '09

Hi, Since upgrading to VDR-1.7.4 I have experienced some instability when recording to an NTFS partition. The recording itself seems to proceed OK, but the recorded programs will generally only play for a few seconds before freezing. Pausing live video and then resuming play will also trigger the problem. Subsequently rewinding a recording that has been so paused will only rewind to the pause point, not the beginning of the recording. All works well when using vdr-1.7.2 to record on the same system to the same partition, and when I placed my recording directory on a reiserfs partition all worked well too. So it appears to be a problem recording on NTFS partitions introduced with the switch to .ts file recording. Any help appreciated. 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 unsubscribe(a)au.fujitsu.com

2 1

Re: [vdr] power consumption, powertop and wakups per second with a af9015 device
by Heinrich Langos 18 Mar '09

18 Mar '09

On Mon, Mar 16, 2009 at 05:23:53PM +0200, Antti Palosaari wrote: > Heinrich Langos wrote: >> >> Anyway .. the main problem remains. >> >> Is there a tool that would only do some minimal actions on a dvb >> device? > > Like power_on? femon for example reads device status. zap, scan... > I cleaned up my system a little more to reduce the avg wakups per second. Now, when vdr is not started I get about 5 wakeups per second and only about 0.2-0.3% of the time is spent in C0 (cpu running). Now starting "femon" I get the following outut at about one line per second: | jukebox:/tmp/hgaf9015.MPZgGXIerw/af9015-a57ea2073e77# femon -H | FE: Afatech AF9013 DVB-T (DVBT) | status SCVYL | signal 18% | snr 0% | ber 0 | unc 6073 | FE_HAS_LOCK | status SCVYL | signal 18% | snr 0% | ber 0 | unc 6073 | FE_HAS_LOCK | status SCVYL | signal 18% | snr 0% | ber 0 | unc 6073 | FE_HAS_LOCK | ... The avg wakups per second go up to about 30, time spent in C0 is slightly higher with 0.4 - 0.6%. Now starting "zap" to tune into a channel: | jukebox:/tmp/hgaf9015.MPZgGXIerw/af9015-a57ea2073e77# zap -channels /tmp/channel.conf N24 | Using frontend "Afatech AF9013 DVB-T", type DVB-T | status SCVYL | signal 0000 | snr 0014 | ber 00000000 | unc 000017b9 | FE_HAS_LOCK Now the wakups per second go up up about 3000 and the cpu is running in C0 about 30% of the time! I ran "dvbtraffic" (itself causing about 10 wakups but hardly any cpu load) on another console to see what is happening and it seems like "femon" does only check the receiver's status while "zap" realy causes data to be transfered from the USB device to the host. So the rather heavy load that I see with vdr is probably not caused by vdr itself but by the USB data transfer. The new questions are: Does every USB DVB-T receiver cause the same amount of cpu load? Does vdr need to read the data stream all of the time? Can it be switched off? (At least while nobody watches and EPG data is not refreshed?) cheers -henrik

1 0

Re: [vdr] power consumption, powertop and wakups per second with a af9015 device
by Heinrich Langos 16 Mar '09

16 Mar '09

On Mon, Mar 16, 2009 at 05:23:53PM +0200, Antti Palosaari wrote: > Heinrich Langos wrote: >> On Mon, Mar 16, 2009 at 03:07:21PM +0100, Heinrich Langos wrote: >>> On Mon, Mar 16, 2009 at 02:19:30PM +0200, Antti Palosaari wrote: >>>> remote=0 does not disable polling, it is for selecting correct remote. >>> Well, setting remote=0 does have an effect (af9015.c): >>> >>> if (val == AF9015_IR_MODE_DISABLED || val == 0x04) { >>> af9015_properties[i].rc_key_map = NULL; >>> af9015_properties[i].rc_key_map_size = 0; > > val is read from eeprom, there is byte in eeprom which tells whether > device have remote or not. If eeprom says no remote then polling is > disabled. > If you look more carefully there is if-else condition which goes: > if (eeprom remote disabled) > * disable remote > else if (module param remote defined) > * load ir-table defined as module param > else > * load ir-table according to USB-ID > You are right. Sorry I didn't read that carefully enough. > I am not sure what happens if device have remote but ir-table is not > selected by if-else. Probably .rc_key_map_size leaves to 0 and remote > polling is disabled. Thats exactly what happens. Though, I didn't see a place where af9015_properties[i]rc_key_map is initalized. Maybe a sanity check for the "remote" module parameter should be added? Telling the user that he uses an invalid value could help new users. > Anyhow, this problem is not af9015 specified. Most dvb-usb -drivers have > just similar implementation. rc-polling is provided by dvb-usb-core. Right again. Sorry to bother you. >> Anyway .. the main problem remains. >> >> Is there a tool that would only do some minimal actions on a dvb >> device? > > Like power_on? femon for example reads device status. zap, scan... Yeap. Thank you for that list. I'll take a look at those and see what I can find out. Cheers and thank you very much for your help! -henrik

1 0

vdr-iptv-0.2.5
by ua0lnj 16 Mar '09

16 Mar '09

Hi My issues. May be I not right, but.... 1. Have: use section filtering - "yes", disable filters - 0. Have a iptv channel in channel.conf, but absent and not streaming now. Switch channels: work channnel -> absent channel -> work channel. And vdr hangs, almost always.... If set use section filtering - "no", all works. If set use section filtering - "yes", disable filters - 1, PAT, all works too. 2. pat.c use Channels.GetByServiceID. Channels.GetByServiceID use ISTRANSPONDER(). #define ISTRANSPONDER(f1, f2) (abs((f1) - (f2)) < 4) We must use frequencies differ > 4 in iptv channels. TV1;IPTV:1:IPTV|S1P0|UDP|127.0.0.1|1234:P:0:512:650:2321:0:1:0:0:0 - third parametr. Never use: TV1;IPTV:1:IPTV|S1P0.............. TV1;IPTV:2:IPTV|S1P0.............. TV1;IPTV:3:IPTV|S1P0.............. need use (example): TV1;IPTV:10:IPTV|S1P0.............. TV1;IPTV:20:IPTV|S1P0.............. TV1;IPTV:30:IPTV|S1P0.............. Otherwise ISTRANSPONDER() not works correct...

2 1

Re: [vdr] power consumption, powertop and wakups per second with a af9015 device
by Heinrich Langos 16 Mar '09

16 Mar '09

Hei Antti, On Mon, Mar 16, 2009 at 02:19:30PM +0200, Antti Palosaari wrote: > Heinrich Langos wrote: >> That is with dvb_usb_af9015 loaded but with "remote=0" module parameter >> to disable the remote control input that aparently is done by polling. > > remote=0 does not disable polling, it is for selecting correct remote. Well, setting remote=0 does have an effect (af9015.c): if (val == AF9015_IR_MODE_DISABLED || val == 0x04) { af9015_properties[i].rc_key_map = NULL; af9015_properties[i].rc_key_map_size = 0; While every other (valid) value for "remote" assigns a key map at that point and further sets the af9015_config.ir_table. I guess thats has consequences so that even if polling occurrs, it doesn't cause a whole lot of other actions. > You can disable polling by setting proper module param for module dvb-usb. Where "proper" would be? :-) >> (With "remote=2" it goes up by about 50 wakeups per second. OK, AFAIK >> USB input devices need to be polled. No way around it. But does it have >> to be at 20ms intervals?) > > hmm, It should be 150ms according to the code. No idea why it generates > 50 wakeups. My guess would be that each polling action generates several USB packets which in turn cause several wakeups... > I have no idea why. Does your vdr let your machine sleep nicely? Cheers -henrik

1 1

PMT in multiple TS packet bug
by Alexw 16 Mar '09

16 Mar '09

Hi Klaus, I have noticed a PMT parsing issue with VDR version 1.7.x. The bug is still present in version 1.7.3 but the behaviour is worst because it segfaults. First I found out that 2 lines where added in the ParsePmt method. Data += Data[0] + 1; // this is the first packet Length -= Data[0] + 1; At the moment I don't know exactly what is the meaning of this 2 operations. The second line can result in a negative Length which is the reason of the segfault. Could you kindly explain the offset drift? In a single section PMT (99.9% of the time) Data[0] is always equal to 0 and we skip the first byte. Length is reduced by 1. I a multiple section stream Data[0] can be above 188. Trying to skip more than a section is not possible in the actual context. I have done a quick and dirty hack to prevent the segfault: --- remux.c_ori 2009-01-16 21:05:46.000000000 +0100 +++ remux.c 2009-01-17 13:34:17.000000000 +0100 @@ -361,6 +361,7 @@ if (pmtSize == 0) { Data += Data[0] + 1; // this is the first packet Length -= Data[0] + 1; + if ( Length < 0 ) Length = 0; if (SectionLength(Data, Length) > Length) { if (Length <= int(sizeof(pmt))) { memcpy(pmt, Data, Length); the second step will be to have the parsing of multiple section allowed. At the moment when the data size exceed the section size (max 4096), PMT cannot be parsed. [2222] ERROR: can't parse PMT [2222] ERROR: can't parse PMT [2222] ERROR: can't parse PMT [2222] ERROR: can't parse PMT [2222] ERROR: can't parse PMT [2222] ERROR: PMT section length too big (4176 byte)! [2222] ERROR: can't parse PMT Regards, Alex

15 36

power consumption, powertop and wakups per second with a af9015 device
by Heinrich Langos 16 Mar '09

16 Mar '09

Hi, I just installed vdr 1.6.0 on Debian stable (Lenny). I run it on an old notebook (Dell 1300, 1.5 GHz Celeron M). Up until now the system was a network storage for some windows clients and a music player for my living room. Now I plan to use vdr as a remote controled VCR. To keep it quiet I checked with powertop and got rid of most software that does short idle loops. Now the system shows less than 10 wakeups per second from sleep. That is with dvb_usb_af9015 loaded but with "remote=0" module parameter to disable the remote control input that aparently is done by polling. (With "remote=2" it goes up by about 50 wakeups per second. OK, AFAIK USB input devices need to be polled. No way around it. But does it have to be at 20ms intervals?) Anyway, the real fun comes with starting vdr. With vdr runing I get a whopping 2700 wakeups per second! And thats doing nothing at all. No recording, no playback no streaming. Nada! The result is a 30% CPU load (admittetly at a low P-state) and a constantly runing CPU fan. I don't know what vdr does, but it causes the device to jump through a lot of (idle) loops. At least thats what I'd read from the output of powertop. Does anybody have an idea as to what it causing this? Any comparative data for other devices? I also own a "Fujitsu-Siemens DVB-T Mobile TV Tuner" and I'll take a look and try to find out if that device will generate less system load. Cheers -henrik Here's the idle state without vdr: ================================= PowerTOP version 1.10 (C) 2007 Intel Corporation Cn Avg 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% C2 0.0ms ( 0.0%) 188 Mhz 100.0% C3 102.8ms (99.8%) Wakeups-from-idle per second : 9.7 interval: 20.0s no ACPI power usage estimate available Top causes for wakeups: 38.1% ( 4.9) <interrupt> : uhci_hcd:usb3, eth0 15.6% ( 2.0) xfsaild : schedule_timeout (process_timeout) 13.2% ( 1.7) xfsbufd : schedule_timeout (process_timeout) 7.8% ( 1.0) ifconfig : b44_open (b44_timer) 5.1% ( 0.7) <kernel core> : sk_reset_timer (tcp_delack_timer) 5.1% ( 0.7) mpd : sk_reset_timer (tcp_write_timer) 3.9% ( 0.5) <kernel core> : schedule_delayed_work_on (delayed_work_timer_fn) 1.9% ( 0.2) <kernel module> : neigh_table_init_no_netlink (neigh_periodic_timer) 1.9% ( 0.2) <kernel core> : neigh_table_init_no_netlink (neigh_periodic_timer) 1.6% ( 0.2) runsvdir : schedule_timeout (process_timeout) 1.6% ( 0.2) <kernel core> : __netdev_watchdog_up (dev_watchdog) 1.6% ( 0.2) init : schedule_timeout (process_timeout) 0.8% ( 0.1) screen : do_setitimer (it_real_fn) 0.8% ( 0.1) nmbd : schedule_timeout (process_timeout) 0.4% ( 0.1) <kernel core> : neigh_add_timer (neigh_timer_handler) 0.4% ( 0.1) <kernel core> : queue_delayed_work (delayed_work_timer_fn) 0.4% ( 0.1) xfssyncd : schedule_timeout (process_timeout) ================================= and here's the "idle" state with vdr: ================================= PowerTOP version 1.10 (C) 2007 Intel Corporation Cn Avg residency P-states (frequencies) C0 (cpu running) (29.4%) 750 Mhz 0.0% polling 0.0ms ( 0.0%) 563 Mhz 0.0% C1 halt 0.0ms ( 0.0%) 375 Mhz 0.0% C2 0.0ms ( 0.0%) 188 Mhz 100.0% C3 0.2ms (70.5%) Wakeups-from-idle per second : 2878.8 interval: 10.0s no ACPI power usage estimate available Top causes for wakeups: 60.2% (4431.3) USB device 5-1 : DVB-T 2 (Afatech) 39.4% (2897.7) <interrupt> : uhci_hcd:usb1, ehci_hcd:usb5, HDA Intel 0.1% ( 7.7) klogd : ehci_work (ehci_watchdog) 0.1% ( 5.1) vdr-kbd : schedule_timeout (process_timeout) 0.1% ( 4.4) <interrupt> : uhci_hcd:usb3, eth0 0.1% ( 3.7) vdr-kbd : futex_wait (hrtimer_wakeup) 0.0% ( 2.0) xfsaild : schedule_timeout (process_timeout) 0.0% ( 1.6) xfsbufd : schedule_timeout (process_timeout) 0.0% ( 1.0) ifconfig : b44_open (b44_timer) 0.0% ( 0.9) kdvb-ad-0-fe-0 : schedule_timeout (process_timeout) 0.0% ( 0.6) <kernel core> : sk_reset_timer (tcp_delack_timer) 0.0% ( 0.6) mpd : sk_reset_timer (tcp_write_timer) 0.0% ( 0.5) <kernel core> : schedule_delayed_work_on (delayed_work_timer_fn) 0.0% ( 0.3) <kernel module> : neigh_table_init_no_netlink (neigh_periodic_timer) 0.0% ( 0.2) <kernel core> : __netdev_watchdog_up (dev_watchdog) 0.0% ( 0.2) xfssyncd : schedule_timeout (process_timeout) 0.0% ( 0.2) runsvdir : schedule_timeout (process_timeout) 0.0% ( 0.2) <kernel core> : neigh_table_init_no_netlink (neigh_periodic_timer) 0.0% ( 0.2) init : schedule_timeout (process_timeout) 0.0% ( 0.1) syslogd : do_setitimer (it_real_fn) 0.0% ( 0.1) nmbd : schedule_timeout (process_timeout) =================================

1 1

Re: [vdr] Popcorn as VDR frontend
by Johan Andersson 14 Mar '09

14 Mar '09

Thank you for your responses. I would be happy for any help offered and would gladly share any results I come up with. If anyone wants my diffs for building xinelib/vdr-fbe on PCH, please mail me. For me, the overall goal is: - Get the functionality of a full VDR frontend on PCH The current tech. idea is; - Use mono to display audio/video - Use custom directfb app to display xineliboutput VDR OSD and get lirc input The initial tasklist as I see it: - Test mono with xineliboutput http access - Make a simple directfb app displaying some image and see if it can show it ontop of a running mono av-stream. - Hack vdr-fbfe/xinelib wildly to get OSD from xineliboutput onto PCH. - Possibly rewrite without using xinelib. It might be good to locate the 'project' somewhere with a decent Wiki and SVN repository. Please suggest something. Please note though that the time I can put on this is very limited, my VDR adventures is a very slow moving process, with family, house and work taking up most of my time. /Johan -- Johan Andersson, jna(a)jna.pp.se

1 0

image 0.3.0 with high resolution output
by Alex Betis 14 Mar '09

14 Mar '09

Hi all, In case you have a high resolution output device (LCD/Plasma) you probably noticed that image plugin show low quality results even when the original image is a very high quality/resolution. To fix it, replace the following lines in liboutput/encode.c file from: m_nWidth = 720; m_nHeight = m_bUsePAL ? 576 : 480; to m_nWidth = 1920; m_nHeight = 1080; Or other output resolution if you don't have a full HD screen. Developers of image plugin, it would be great to have those 2 parameters configurable for that plugin. Also, I've noticed the xinelibout (or OSD) stuck many times when I use image plugin. And another improvement: Since image conversion takes lots of time (about 2-3 seconds on E6600) it will be great if the plugin will try to cache next or previous image (depends on user direction) in advance, so the switch will be instant. Converting 9 images to show the 3x3 screen takes VERY long. Maybe should convert them to a very low resolution images to make is faster. Beside that, thanks for a good plugin.

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

vdr March 2009