vdr December 2009

vdr@linuxtv.org

43 participants
54 discussions

VDR 1.7.x and unstable DVBT locking on channe (breaks after 60secs)l?
by mike n 05 Dec '09

05 Dec '09

Hello, I have been testing the latest VDR 1.7.10 and 1.7.5 versions and both have following problem I haven't seen on VDR 1.6.x version. The problem is that after starting VDR (with or without OSD GUI frontend), it looses a lock on channel after 60 seconds or so. If I have local or remote xinelibout GUI watching the live-tv then at first picture goes to garbage (lots of blocky artifacts) and after few seconds it freezes completely. OSD and VDR itself is still functional, but livetv picture is static picture. Or sometimes VDR all in a sudden shows a picture from another channel even when I didn't change channel (static picture with lots of blocky artifacts). To me it looks like VDR changed tuner to another MUX (I have 4 DVBT muxes here or whatever the proper term is for those "channel groups") when static picture changes. This happens every time when I start VDR. Restart of VDR fixes the problem immediatly, but after 60 seconds booom again. When this happens, Xineliboutput console shows following text: "no data in 8 seconds. queing no signal image" If I use ZAP dvb-apps tool to save a channel output to a tempfile.ts file output, it works beatifully all day long. It doesn't loose lock on a channel and picture quality is perfect (no artifacts). I have tried two different computers and two USB DVBT tuners and the problem is the same in all of these, so I assume it is not hardware related. It shouldn't be signal related either because ZAP saves perfect TS stream output all night long. Is there some worker process which kicks in VDR every 60 seconds? Maybe EPG related process? For some reason I suspect that VDR starts to scan through EPG data even when I'm watching live-tv. This would explain why it seems that sometimes it tuned to another mux. When I start VDR, there is no cached EPG data file because it goes to TMP folder and tmp is cleared everytime machine boots up. Environment is as follows - Linux kernel 2.6.31.1 - DVBT Reddo usb stick and Twinhan DVBT stick tested - VDR 1.7.10 and 1.7.5 versions tested - Xineliboutput latest CVS version as frontend (doesnt matter even when I start VDR in background without GUI frontend. Problem is the same) I'm able to code/debug/read source code quite fluently, so I'm happy to help debug this if someone could point me to right direction where to look for this "60 secs timeout/worker process" issue in VDR. Anyone any ideas? Thanks in advance, Mike N _________________________________________________________________ Windows Live: Friends get your Flickr, Yelp, and Digg updates when they e-mail you. http://www.microsoft.com/middleeast/windows/windowslive/see-it-in-action/so…

2 1

vdr 1.7.10, Wiedergabe TS-Aufnahme gibt "TS continuity error"
by Andreas Hölscher 05 Dec '09

05 Dec '09

Hallo, ich habe jetzt probehalber mal vdr von 1.6.0 auf 1.7.10 umgestellt. Ich habe keinen Zwang die 1.7.x zu benutzen, da ich keine HD-Ambitionen habe, möchte aber den Anschluss bei der vdr-Entwicklung nicht verpassen. Ich kann mit 1.7.10 live Fernsehen und alten Aufnahmen ansehen. Dann habe ich eine Probeaufnahme gemacht (jetzt ja im TS-Format) und die kann ich nicht wiedergeben: Ich bekomme ein schwarzes Bild und in /var/log/messages jede Menge Meldungen "TS continuity error". Das OSD-Menu funktioniert wie gewohnt. Die Aufnahme kann ich mir mit mplayer aber prima angucken, es scheint wohl ein Problem der Wiedergabe zu sein. Googeln brachte zwar viele Ergebnisse zu dieser Fehlermeldung, aber nichts was zu meinen Randbedingungen zu passen scheint (Probleme nur bei Wiedergabe einer TS-Aufnahme). Habt ihr einen Tipp für mich, wie ich da weiter komme? Welche Infos/Logs wären noch hilfreich? Danke, Andreas SuSE 11.2 mit Kernel 2.6.31.5-0.1-default Technisat SkyStar2 DVB-S vdr 1.7.10 burn-0.1.0-pre22-ff1 extrecmenu-1.2-test1-am2b femon-1.6.6 vompserver-0.3.1-1-Yaris xine-0.9.0

1 2

Re: [vdr] mdadm software raid5 arrays?
by Stephan Loescher 03 Dec '09

03 Dec '09

"Simon Baxter" <linuxtv(a)nzbaxters.com> writes: > Anyway, I've bought 3x 1.5 TB SATA disks which I'd like to put into a > software (mdadm) raid 5 array. [...] > But does anyone have any production VDR experience with mdadm - good or bad? If you like good performance and simple recovery, then do not use RAID5. Use RAID1 instead. I use RAID5 only because I am too lazy to buy some new and larger disks for my VDR at the moment :-) I have had serious performance-problems with parallel recordings and some Linux-background-jobs (like system-backup). I solved it by raising the I/O-priority of vdr with ionice: ionice -c2 -n0 vdr -w 120 -v $VIDEODIR -d -t /dev/tty5 -g /tmp ... Stephan. -- loescher(a)gmx.de http://www.loescher-online.de/ Try LEO: http://www.leo.org/

2 1

deinterlacing VDR-HD on xine?
by Füley István 01 Dec '09

01 Dec '09

Hello list, after some unsuccesfull tests with HD-VDR on Ubuntu, I decided to return to Opensuse (i'm using it for SD-VDR for about 4 years). I installed a fresh 11.2 x64 version, compiled v4l-dvb-b8eb9e860545 drivers, installed NVIDIA-Linux-x86_64-190.32, compiled xine-lib-1.2 patched with xine-lib-1.2-vdpau-r284.diff by Reinhard Nissl, vdr-1.7.9 with liemikuutio patch, vdr-xine-0.9.3 and PearlHD skin. I had to make the following settings to have a tear-free HD video: - give 512 MB RAM for onboard video (i have 8200 onboard on Asus M3N78-VM, 2GB) - set cpu-freq to the max. possible value of 2.1 GHz (aka "performance governor") as i had problems letting cpu-freq to choose the cpu frequency (i don't understand, why, as i had no cpu load higher than 40% even on high bitrate HD channels) - AMD BE-2350 - disabling composite out in xorg.conf (I have a 1920x1080 LCD connected via dvi) - and the usual settings in ~/.xine/config for buffer values Now VDR works fine even on high bitrate channels with "xine --post vdr_video --post vdr_audio --post upmix_mono --post vdr". The problem is, if I'm trying to activate deinterlacing in xine ( -Dtvtime:method=Greedy2Frame,cheap_mode=0,pulldown=0,use_progressive_frame_flag=1 and many other tvtime setups) I end up with some dropped frames and freezes on high bitrate HD channels (>12mbps). Is this issue coming from my hardware's limitations (not enough CPU or GPU power), or is there any more things to fine-tune? thanks, István -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.

5 10

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

vdr December 2009