vdr November 2011

vdr@linuxtv.org

37 participants
45 discussions

[PATCH v2] multi-frontend-support for vdr 1.7.21
by L. Hanisch 08 Jan '12

08 Jan '12

Hi, Here's version 2 of my multi-frontend-patch. It's still "dirty", since it changes the constructor of cDvbDevice which will break compilation of some plugins. But I think it might be necessary to look at the relevant plugins since they might need to react on frontend changes. I haven't tested any of those plugins but will have a look at some that I'm using. Maybe there have to be some virtual functions like "BeforeFrontendSwitch" and "AfterFrontendSwitch" so the plugins are even able to know about it. Assumption for this patch: All frontends within one adapter have to be used mutually exclusive. All cards I know behave in this way. If there are cards with multiple frontends which can be used simultaneously I'd like to hear about it. Whenever the dvb-api-changes are upstream (the ENUM_DELSYS thingy) I think my patch can easily be converted to use that. I'm still working on this patch, it's not finished yet... :-) Have fun, Lars.

7 8

sxfe and vsync
by Tony Houghton 26 Dec '11

26 Dec '11

When using NVidia graphics cards and the proprietary driver I find vdr-sxfe looks quite smooth even with a monitor that only supports 60Hz. I think it's been syncing to the vertical blank "automagically". But with other graphics cards I get a lot of tearing which is marring my viewing pleasure. This is happening both with Intel Sandy Bridge (normal monitor) and a Radeon 5450 with fglrx connected to a TV. The free ati driver isn't a practical option on that because the HDMI audio doesn't work with it. I'm using the xv output in each case. Is there a way to make vdr-sxfe sync to the vertical blank with these cards/drivers?

5 7

[PATCH] vdr-1.7.21 & DVB-T2 support
by Rolf Ahrenberg 22 Dec '11

22 Dec '11

Hi, here's my attempt to provide a native DVB-T2 support for VDR. - added initial libsi support for the required T2 delivery system descriptor - updated bandwidth, modulation, transmission, guard settings to match DVB-T2 specs - added a new PLP id to channel parameters and tuning mechanism - requires DVB API 5.3 - implementation is analog to the current DVB-S/S2 extending the existing delivery system field - shortcomings: PLP id can be found also in DVB-T channel configuration (but doesn't affect anything) and the new channels.conf values could be a bit more intuitive It seems to work here in Finland with my limited access to local DVB-T2 muxes, but no guarantees. :) BR, -- rofa

2 1

Unable to record 2 dvb-t channels
by Marc 12 Dec '11

12 Dec '11

Hi, I use vdr (1.7.21) with xvdr (git version). I can't record 2 channels, vdr start the recording but the file is empty and after 30 seconds, vdr throws an emergency exit : Nov 25 12:18:34 myhost vdr: [12866] recording thread started (pid=10925, tid=12866) Nov 25 12:18:34 myhost vdr: [10949] XVDR: Recordings state changed (6) Nov 25 12:18:34 myhost vdr: [10949] XVDR: Requesting clients to reload recordings list Nov 25 12:19:05 myhost vdr: [12866] ERROR: video data stream broken Nov 25 12:19:05 myhost vdr: [12866] emergency exit request ignored according to setup When I try to watch these streams with xineliboutput, the stream starts only after 30 seconds and I have only the sound : [19021] [input_vdr] <control> OSDCMD [19021] [input_vdr] <control> OSDCMD [19021] [input_vdr] <control> OSDCMD [19021] [input_vdr] <control> DISCARD 114940568 61162 [19022] [demux_vdr] input->read_block() was interrupted [19021] [input_vdr] <control> STILL 0 [19022] [input_vdr] <control> <data> DISCARD 114940568 61162 [19022] [input_vdr] wait_stream_sync: discard_index 114940568 != curpos 114869128 ! (diff 71440) [19022] [input_vdr] wait_stream_sync: streams synced at 114940568/114940568 [19021] [input_vdr] <control> LIVE 0 [19022] [input_vdr] <control> <data> BLANK prebuffer=14400 pts [19021] [input_vdr] <control> STILL 0 vdpau_set_property: property=0, value=0 vo_vdpau: deinterlace: none [19022] [input_vdr] wait_fifos_empty: video 0, audio 0 prebuffer=2000 pts prebuffer=14400 pts [19021] [input_vdr] <control> STILL 0 [19021] [input_vdr] <control> LIVE 1 prebuffer=14400 pts [19021] [input_vdr] <control> TRICKSPEED 1 [19021] [input_vdr] <control> STILL 0 [19022] [demux_vdr] PAT: program changed, flushing demuxer [19022] [demux_vdr] PMT changed, resetting demuxer [19022] [demux_vdr] New PTS: 7327138046 (AUDIO) [19022] [demux_vdr] audio stream changed: 00000000 -> 03010000 *** The stream doesn't start [19021] [input_vdr] <control> OSDCMD [19021] [input_vdr] <control> OSDCMD *** After 30 seconds, the audio start but no picture An example with an other channel of the same provider (France Television Group, the 2 wrecked channels are from the same provider): [19021] [input_vdr] <control> OSDCMD [19021] [input_vdr] <control> OSDCMD [19021] [input_vdr] <control> OSDCMD [19021] [input_vdr] <control> DISCARD 56596648 30119 [19022] [demux_vdr] input->read_block() was interrupted [19021] [input_vdr] <control> STILL 0 [19021] [input_vdr] <control> LIVE 0 prebuffer=14400 pts [19021] [input_vdr] <control> STILL 0 vdpau_set_property: property=0, value=0 vo_vdpau: deinterlace: none [19022] [input_vdr] <control> <data> DISCARD 56596648 30119 [19022] [input_vdr] wait_stream_sync: streams synced at 56596648/56596648 [19022] [input_vdr] <control> <data> BLANK [19022] [input_vdr] wait_fifos_empty: video 0, audio 0 prebuffer=2000 pts prebuffer=14400 pts [19021] [input_vdr] <control> STILL 0 [19021] [input_vdr] <control> LIVE 1 prebuffer=14400 pts [19021] [input_vdr] <control> TRICKSPEED 1 [19021] [input_vdr] <control> STILL 0 [19022] [demux_vdr] PAT: program changed, flushing demuxer [19022] [demux_vdr] PMT changed, resetting demuxer [19022] [demux_vdr] New PTS: 6415996599 (VIDEO) [19022] [demux_vdr] audio stream changed: 00000000 -> 03410000 [19021] [input_vdr] <control> HDMODE 1 [19021] [input_vdr] WARNING: xine-engine setting "engine.buffers.video_num_frames":22 is too small for some HD channels vdpau_set_property: property=0, value=1 vo_vdpau: deinterlace: temporal_spatial Broken NAL, skip it. ffmpeg_audio_dec: increasing buffer to 98304 to avoid overflow. Allocate 4 reference frames Create decoder: vdp_device: 1, profile: 8, res: 1920x1080 vo_vdpau: deinterlace: temporal vo_vdpau: set_scaling_level=0 vo_vdpau: enabled features: inverse_telecine=1 vo_vdpau: disable noise reduction. vo_vdpau: disable sharpness. vo_vdpau: vdpau_update_csc: hue=0.000000, saturation=1.000000, contrast=1.000000, brightness=0.000000, color_standard=1 studio_levels=0 vo_vdpau: skip_chroma = 0 vo_vdpau: background_color = 0 [19021] [input_vdr] <control> OSDCMD [19021] [input_vdr] <control> OSDCMD Regards, Marc.

1 1

[ANNOUNCE] halirc
by Wolfgang Rohdewald 28 Nov '11

28 Nov '11

halirc is a python program I wrote for my own use, but maybe others are interested in it too. If so, I will make it a sourceforge project halirc can get events from lirc and other sources. It controls devices like vdr, my Denon AVR 2805 Receiver (via RS232), my LG Plasma TV (via RS232) and other things by shell calls. This would be rather difficult to do with lircrc and shell scripts (I tried). it is rather modular, adding support for more devices should be straightforward. halirc gives you a basic library making it easy to implement your specific wishes on top of it. It knows about the quirks of those devices and hides them from you (like the LG reacting in strange ways when sending commands while it powers up or down and the Denon ignoring new commands while processing some. Both devices have no reliable way of telling that they are ready to process the next command) my use cases (they need about 90 statements on top of the library code): - in the morning, start a certain radio station very loudly. Later, make it less loud, then turn it off. Only on weekdays - I find it easier if I only have to get contact with one single IR receiver. So halirc listens to lirc events and redirects them to the matching devices (I use IR codes of otherwise unused remotes for this) - when listening to radio, I can switch the TV off with one button. This is not yet standby, if the image is wanted again it appears without delay. After 5 minutes halirc puts the screen into standby. Any other key will switch the screen back on and initialize it as needed by vdr. roadmap: - add direct support for USB-controlled Gembird power outlet, right now I do that via shell scripts - show some state changes of the Denon receiver on screen, especially for the different sound falsifying modes like SUPER STADIUM. The display of the Denon is too far away to be visible. This is easy to do because the Denon will automatically send all state changes over RS232, no polling needed. - I do have RS232 specifications for some Epson beamers and for some Pioneer blue ray players, but I currently have no plans to buy those. Anyway adding support for them those should be easy to do. - maybe support sending IR commands with lirc get it here: http://www.rohdewald.de/vdr/halirc.tar -- Wolfgang

1 0

vdr-xine with xxmc -> problem with OSD
by Arturo Martinez 27 Nov '11

27 Nov '11

Hi, I am launching xine with -V xxmc for the graphical acceleration. Using vdr 1.7.21 with vdr-xine 0.9.4 The only OSD mode that works is osdOverlay, the rest bring a severely corrupted OSD. But osdoverlay seems to be very CPU intensive. Does anybody know of a fix/patch or workaround? xine.osdMode = osdOverlay lspci |grep VGA 01:00.0 VGA compatible controller: VIA Technologies, Inc. VT8623 [Apollo CLE266] integrated CastleRock graphics (rev 03) * English - detected * English * Spanish * English * Spanish <javascript:void(0);> auto-copied

2 1

dropping broken PES packet
by Vidar Tyldum 25 Nov '11

25 Nov '11

After upgrading to 1.7.21 I have started having these issues where the picture freezes on the frontend from time to time. It can last from 30 seconds to several minutes. Looking at the log I see these errors repeating themselves: vdr-sxfe[9003]: [9014] [demux_vdr] ts2es: payload not PES ? vdr-sxfe[9003]: [9014] [demux_vdr] ts2es: dropping broken PES packet VDR itself is not logging anything particular when this happens, despite being at loglevel 3. I tried just streaming to VLC and the same thing happends, which means it's nota frontend issue. I cannot open the OSD when the problem is 'active'. If the watchdog is enabled it will cause a restart of VDR. If the picture comes back before the watchdog kicks inn I get: vdr-sxfe[31073]: [31111] [demux_vdr] New PTS: 7275023756 (VIDEO) Any ideas on how to proceed to debug this? Source is DVB-C, 1.7.17 was my previous version where I did not have this issue. Using precompiled packages from http://ppa.launchpad.net/yavdr/stable-vdr/ubuntu -- Vidar Tyldum vidar(a)tyldum.com PGP: 0x3110AA98

1 1

Re: [vdr] xine dropped frames warning
by Arturo Martinez 24 Nov '11

24 Nov '11

Finally, I´ve edited /xine-ui/src/xitk/errors.c the last function: I left it like this: void too_slow_window(void) { return; } Now no more dropped frames warning boxes :-)

1 0

Re: [vdr] xine dropped frames warning
by ian_and_joanna＠talktalk.net 24 Nov '11

24 Nov '11

Hi, I find this all puzzling too. I've been in similar situations and welcomed suggestions. Here is one of mine. Try changing your xine command line by replacing the '=' following --config with a space. Showing the commandline is not the same as the app parsing the parameter. Xine may be clever in this respect in which case this will make no difference. Ian. Sent from my HTC ----- Reply message ----- From: "Arturo Martinez" <martinez(a)embl.de> Date: Thu, Nov 24, 2011 08:29 Subject: [vdr] xine dropped frames warning To: <vdr(a)linuxtv.org> I am using the right config and the warnings still show. Lets prove it... ps -ef |grep xine xine --no-gui --no-logo --no-splash -pq -A alsa -f -V xxmc --post vdr --post vdr_video --post tvtime:method=LinearBlend,cheap_mode=1,pulldown=0,use_progressive_frame_flag=1 --config=/home/tv/.xine/config vdr://tmp/vdr-xine/stream#demux:mpeg_pes So that´s my xine running and shows it is using for config /home/tv/.xine/config Now I run the grep command on it: grep "^gui.dropped_frames_warning:0" /home/tv/.xine/config && echo "config is good :)" || echo "config is bad :(" And the result is: gui.dropped_frames_warning:0 config is good :) Yet if I open vdr´s OSD and fiddle with it for a minute or so I am guaranteed to get the dropped frames warning. cxfe does not have the warning problem but unfortunately it does not support xxmc acceleration :( _______________________________________________ vdr mailing list vdr(a)linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

2 1

Re: [vdr] xine dropped frames warning
by Arturo Martinez 24 Nov '11

24 Nov '11

I am using the right config and the warnings still show. Lets prove it... ps -ef |grep xine xine --no-gui --no-logo --no-splash -pq -A alsa -f -V xxmc --post vdr --post vdr_video --post tvtime:method=LinearBlend,cheap_mode=1,pulldown=0,use_progressive_frame_flag=1 --config=/home/tv/.xine/config vdr://tmp/vdr-xine/stream#demux:mpeg_pes So that´s my xine running and shows it is using for config /home/tv/.xine/config Now I run the grep command on it: grep "^gui.dropped_frames_warning:0" /home/tv/.xine/config && echo "config is good :)" || echo "config is bad :(" And the result is: gui.dropped_frames_warning:0 config is good :) Yet if I open vdr´s OSD and fiddle with it for a minute or so I am guaranteed to get the dropped frames warning. cxfe does not have the warning problem but unfortunately it does not support xxmc acceleration :(

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

vdr November 2011