vdr

vdr@linuxtv.org

6731 discussions

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

Popcorn as VDR frontend
by Johan Andersson 13 Mar '09

13 Mar '09

I need some advise on routes to look into on the subject. First, thank you Klaus and all for a great PVR. I have tried a lot of others like Myth, MediaPortal, GBPVR etc, but the silent menusystems are hopelessly inferior to having all menus on OSD. Me and my family have used VDR for 2+ years now and we are all happy with it. I am not bleeding edge VDR with DVB-T in Sweden being SDTV and we have only one TV-set although I'm running client/server xineliboutpout with a dedicated frontend machine. I bought myself a PCH with the idea of using it instead of my PC VDR frontend. With some effort and googling I got xineliboutputs vdr-fbfe (with xinelib et.al) cross compiled and runnable on the PCH. However AFAIK, the directfb usage in xinelib is based on pixelmaps written to a dfb surface, all mpeg decode is done in software, this is suboptimal on the PCH along with sound being a problem. Running vdr-fbfe on PCH says 'DFBGetSurface() not supported' and exits. It seems people have looked into streamdev instead. I like my VDR OSD though on the TV-set, am I wrong in believing that is a nono with streamdev? Now PCH has an 'IAdvancedMediaProvider' extension to directfb seemingly allowing the mpeg-stream to be sent directly to the hardware, thereby including both video and audio, it is sadly not fully documented in the headers released by Syabas... The most promising option as I see it is to slash down vdr-fbfe to only display the 'osd_command' data on a PCH DFB layer without video capability and stream 'normally' to PCH using ideally the xineliboutputs servers ability to supply for example an http stream. The hope being that the 'vdr-fbfe' application can access directfb concurrently and have the OSD displayed ontop of the video layer. Before I dig deeper into this I would like to ask the community what has been tried and what routes do you see as most viable? I know of some other PCH frontend software for GBPVR Myth, ie vomp and mvcpmx(?) but they seem to return me to the world of silent menus, not a place I want to be. /Johan -- Johan Andersson, jna(a)jna.pp.se

4 6

Re: [vdr] Small VDR-streamdev patch for Popcorn Hour NMT
by Tomáš Skočdopole 13 Mar '09

13 Mar '09

2009/2/17 Goga777 <goga777(a)bk.ru>: > Приветствую, Tomáš > > can you watch hdtv channels on Popcorn with vdr 174 ? > > Hi Goka777, This week I switched to vdr-1.7.4 and streamdev-cvs (both without any patches). Its better than vdr-1.7.0 and streamdev-1.3.4 but popcornhour still sometimes freezes (while watching SD /HDTV channels) and power off from electrical network is needed. I tried Nova HD and Eurosport HD channels and I am able to watch both of them. But sometimes with freezing. With what can I help? Could I save stream and store somewhere to FTP for analysing or send some logs from vdr? Best regards, Tomas

4 4

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

vdr