vdr May 2005

vdr@linuxtv.org

154 participants
186 discussions

AverTv771, Dxr3 -> glitches with hdd activity
by Michael Schröder 08 May '05

08 May '05

Hi out there, maybe someone has a hint for me. I'm trying to get vdr run smoothly since a while now and I 'm close to giving up. Watching TV works fine, but as soon as I start recording, timeshifting or just doing some harddisk activity, there are a lot of glitches in the video/audio. Power management/ACPI is switched off in the kernel, HDD uses UDMA5 mode, so everything should be fine ?? Of course all drivers seem to load without probs. At least there are none reported in dmesg. My system: VDR 1.3.16 /VDR1.3.23 latest CVS version of video4linux, dxr3, dvb drivers.. I also tried several releases/older versions. Kernel 2.6.11 / 2.6.9 AverTV 771 DVB-T dxr3 ECS K7SEM (SIS) / Asrock K7VM2 (VIA) mainboard Duron1600 CPU 512 MB Samsung 120G HDD Any ideas anyone ?? Thanks. Michael -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.308 / Virus Database: 266.11.6 - Release Date: 06.05.2005

1 1

How to repair damaged AC3 stream of old recordings
by Stefan Lucke 08 May '05

08 May '05

Hi, as old recordings (pre vdr1.3.19) have damaged ac3 substream ids, and this damaged substream id is part of crc'd data it would be necessary to replaced the damaged substream id by 0x80 and to re-crc if previous crc is ok. Does someone know if there is a batch utility which can do that ? -- Stefan Lucke

3 3

softdevice 0.1.1 / mp3 0.9.7 : plays all tracks at high speed until "left" is pressed
by Nicolas Huillard 07 May '05

07 May '05

Hello again, As stated on the subject, all tracks are "played" (in fact, there is no sound) at high speed, whether I jump from track to track, or I simply wait for the prvious to finish. If I press "left", the track gets back a little, then plays fine... Until the next track... (vdr 1.3.23) -- NH

4 5

VDR automatic channel update and recording annoyance.
by Antti Hartikainen 07 May '05

07 May '05

Hi. VDR:s automatic channel update while recording is very annoying and it's breaking few seconds of the recording. Some channels (like YLE in Finland) changes audio language for example from "fin" to "eng" when program starts. VDR detects there is change in channel information, stops recording, retunes to channel and starts recording again. This way there is always missing few seconds from the start of the recording. But on the other hand, this feature is a must. I like new channels to be added and information changed. But retuning on such minor issue (and breaking recording) is bad. And if there is audio pid added when program starts (ie. AC3 or second mp2) couldn't vdr add it to stream "on the fly" and not cutting recording?

6 8

xine plugin patch for current cvs
by C.Y.M 07 May '05

07 May '05

When I just updated xine from cvs today, there were several errors when applying the xine-lib patch. Are these safe to ignore? Best Regards, C.Y.M. *************** *** 241,247 **** if (!*input) return port; (*input)->xine_in.name = "video in"; (*input)->xine_in.type = XINE_POST_DATA_VIDEO; - (xine_video_port_t *)(*input)->xine_in.data = &port->new_port; (*input)->post = post; xine_list_append_content(post->input, *input); } --- 241,247 ---- if (!*input) return port; (*input)->xine_in.name = "video in"; (*input)->xine_in.type = XINE_POST_DATA_VIDEO; + *(xine_video_port_t **)&(*input)->xine_in.data = &port->new_port; (*input)->post = post; xine_list_append_content(post->input, *input); } *************** *** 251,257 **** if (!*output) return port; (*output)->xine_out.name = "video out"; (*output)->xine_out.type = XINE_POST_DATA_VIDEO; - (xine_video_port_t **)(*output)->xine_out.data = &port->original_port; (*output)->xine_out.rewire = post_video_rewire; (*output)->post = post; (*output)->user_data = port; --- 251,257 ---- if (!*output) return port; (*output)->xine_out.name = "video out"; (*output)->xine_out.type = XINE_POST_DATA_VIDEO; + *(xine_video_port_t ***)&(*output)->xine_out.data = &port->original_port; (*output)->xine_out.rewire = post_video_rewire; (*output)->post = post; (*output)->user_data = port; *************** *** 718,724 **** if (!*input) return port; (*input)->xine_in.name = "audio in"; (*input)->xine_in.type = XINE_POST_DATA_AUDIO; - (xine_audio_port_t *)(*input)->xine_in.data = &port->new_port; (*input)->post = post; xine_list_append_content(post->input, *input); } --- 722,728 ---- if (!*input) return port; (*input)->xine_in.name = "audio in"; (*input)->xine_in.type = XINE_POST_DATA_AUDIO; + *(xine_audio_port_t **)&(*input)->xine_in.data = &port->new_port; (*input)->post = post; xine_list_append_content(post->input, *input); } *************** *** 728,734 **** if (!*output) return port; (*output)->xine_out.name = "audio out"; (*output)->xine_out.type = XINE_POST_DATA_AUDIO; - (xine_audio_port_t **)(*output)->xine_out.data = &port->original_port; (*output)->xine_out.rewire = post_audio_rewire; (*output)->post = post; (*output)->user_data = port; --- 732,738 ---- if (!*output) return port; (*output)->xine_out.name = "audio out"; (*output)->xine_out.type = XINE_POST_DATA_AUDIO; + *(xine_audio_port_t ***)&(*output)->xine_out.data = &port->original_port; (*output)->xine_out.rewire = post_audio_rewire; (*output)->post = post; (*output)->user_data = port;

2 1

RE: [vdr] vdr-1.3.22: channel not available. why?
by Rantanen Teemu 07 May '05

07 May '05

Stefan Taferner wrote: > I think it is necessary to have that checking for a CI. Otherwise > it wont work well on systems that have mixed CI and non-CI cards. > Or two cards with different CI (e.g. premiere + orf). This sounds good, at least it would fix this for me. In the meantime I modified for-loop in cDevice::GetDevice() to: for (int i = numDevices-1; i >= 0; i--) My full-card (with CI) is the first device, followed by 2 budget cards (non-CI). Now budget cards will be selected if they are free and can receive the channel. You should consider this as a (very) temporary solution, which may or may not help you (depending on the order of DVB cards in your system). For the real fix, wait for what Klaus has to say... Teemu

2 1

RE: [vdr] VDR automatic channel update and recording annoyance.
by Rantanen Teemu 07 May '05

07 May '05

Timo Laitinen wrote: > Sorry, I was a bit unclear there, the syslog gap means that there is > still a large difference between event change and pid change. Yes, you are correct. I reexamined the syslog and I had not noticed that the actual status change had happened earlier, exactly at the same time as on your syslog (22:05:20). What is now strange is that there is a 4 seconds difference between event status change and the timer event change: Apr 9 22:05:20 mewtwovdr vdr[7843]: channel 1 (TV1) event 22:05 'Frasier' status 4 Apr 9 22:05:24 mewtwovdr vdr[7835]: timer 2 (1 2129-2211 'Uutisvuoto') set to event La 09.04.2005 22:05-22:26 'Frasier' Apr 9 22:05:25 mewtwovdr vdr[7843]: changing pids of channel 1 from 512+128:650=fin:2321 to 512+128:650=eng:2321 What I am now wondering is if this is the same status that is changed in 22:05:20 and 22:05:24, or are those broadcasted separately? (= is there 4 seconds delay within VDR?) Teemu

2 1

RE: [vdr] VDR automatic channel update and recording annoyance.
by Rantanen Teemu 07 May '05

07 May '05

Klaus Schmidinger wrote: > > I asked once already, but you gave no answer. > Sorry, I had only very little time lately to go through the VDR ML messages. No prob > Well, I can't quote a standard here, but I would say that plain > common sense dictates that the PIDs should be set correctly > (including language codes) _before_ a broadcast starts. After > all, they're not likely to change right in the middle of a movie, are they? I wouldn't expect them to change in the middle of a movie, but some documentaries may have interviews and actual film footage in different languages. I haven't yet recorded any that actually change languages in the middle of a show, but just wondering if there is a limit what you can and what you cannot change... > But then again, most broadcasters don't even get the running > status in sync with the actual broadcasts, so how can we expect > the PIDs to be set at the right time. Seems to me like there are > a few monkeys sitting at a switchboard, plugging in cables randomly > and every once in a while hitting the right spot ;-) I always thought > that in today's digital playout centers things would be completely computerized... Yep, we have those here too :-) But, this particular broadcaster seems to be top of the line. It's e.g. the only one I know of that is using DVB subtitles... Also with a little bit of syslog examination it looks like the event state is changed when the program start (even after the programme introduction), at most a second or two before (impossible to say more precisely as the data is buffered inside vdr and dvb drivers). When PMT_SCAN_TIMEOUT is set to the default 10 seconds there is a delay between event change and a PID change, as Lauri Tischler noticed. I changed the PMT_SCAN_TIMEOUT to 1. Now the delay is gone, and event change and possible PID change happen at the same second (based on syslog). My next recording from that broadcaster is only next Saturday (that I know of having a gap every time), but based on the syslog now and before I guess this would help. And it doesn't seem to be taking any more CPU than before on my really slow P2-350, but I only have a fraction of the number of channels you may have in satellite (around 130 here in cable). Teemu

4 5

softdevice 0.1.1 / dvd 0.3.6_b03 : no overlay on menus
by Nicolas Huillard 06 May '05

06 May '05

Hello, As stated on the subject, with those version, there is no evidence of where the selection is in the menus (ie. blind selections). Don't know if it's related to vdr-dvd or softdevice (0.1.1, no CVS yet). -- NH

1 0

vdr 1.3.22 channels.conf parsing error ?
by Roberto Sebastiano 06 May '05

06 May '05

Hi, I have a strange error with channels.conf and vdr. I used the scan utility with "-e 3 -o vdr" options. The "-e 3" option is an extension I made to allow scan output the provider field in the right way for vdr 1.3.x, i.e: Chan_name;Provider:otherfields The patch has recently been applied to CVS Now, a friend of mine that used the scan utility with the options above has found a vdr error at startup. After a little debugging, I found that if you put these two lines in an empty channels.conf, vdr won't start. Bloomberg French TV;DEFAULT PROVIDER:11642:h:S13.0E:27500:1160:1120,1122:0:1:1:318:0:0 MTV Portugal;MTV Networks:11241:v:S13.0E:27500:160:80:32:1:1:318:0:0 The odd is that if you delete ONE of the two lines above (doesn't matter which), vdr starts. Maybe a buffer overflow in the vdr parser, or simply the lines above have something wrong ? Regards, Roberto

4 3

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

vdr May 2005