vdr

vdr@linuxtv.org

2 participants
6731 discussions

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

CAM module doesn't work on Nexus and CI module
by ocmer 06 May '05

06 May '05

Hello list, I'm trying to get my CAM working on vdr 1.3.22 and vdr 1.2.6, with only the vdr-remote-0.3.3 plugin (http://endriss.escape.bei.t-online.de/vdr) enabled. I've got a Hauppauge CI module (http://213.221.87.83/pages/products/data_ci-modul.html) connected to the second Hauppauge Nexus card (http://213.221.87.83/pages/products/data_nexus-s.html) Accoording to the Wiki (http://www.linuxtv.org/wiki/index.php/Supported_CAM_modules) this configuration should support all cam's. I've tried 3 different CAM's, without success. The CAM's get hot, so they've got power, but further no results. When I use the Setup menu in vdr (both versions), I can reset the CAM's, the log shows that that is done, but when I triy to access the CAM menu, vdr report "Can't acces CAM menu". The question is : What should I see in the log and on screen when I got a working CAM ? Best regards, ocmer

3 3

trying to find causes for high cpu usage
by Wolfgang Rohdewald 06 May '05

06 May '05

I added some debug output for every 1000th call to poll() in cSectionHandler::Action At 23:58 a recording started. Since then the thread for my 2nd device (first and primary is Nexus-S FF, 2nd is TT PCI Budget) also polls much more even after the recording finished. Why is there so much activity going on for the 2nd device even when it is no longer needed? Is there any way to tell vdr that no output is needed such that vdr can stop processing the data stream of the first device too? Why does the first device call poll() twice as much as the second one? Mar 22 23:57:55 mm vdr[20430]: pcount in cSectionHandler::Action:12209000 Mar 22 23:57:59 mm vdr[20430]: pcount in cSectionHandler::Action:12210000 Mar 22 23:58:00 mm vdr[20426]: timer 1 (28 0000-0055 'Zimmer frei!') entered VPS margin Mar 22 23:58:00 mm vdr[20426]: switching device 2 to channel 28 Mar 22 23:58:02 mm vdr[20430]: pcount in cSectionHandler::Action:12211000 Mar 22 23:58:05 mm vdr[20430]: pcount in cSectionHandler::Action:12212000 Mar 22 23:58:08 mm vdr[20433]: pcount in cSectionHandler::Action:1000 Mar 22 23:58:08 mm vdr[20430]: pcount in cSectionHandler::Action:12213000 Mar 22 23:58:11 mm vdr[20430]: pcount in cSectionHandler::Action:12214000 Mar 22 23:58:13 mm vdr[20433]: pcount in cSectionHandler::Action:2000 Mar 22 23:58:14 mm vdr[20430]: pcount in cSectionHandler::Action:12215000 ... Mar 23 00:00:00 mm vdr[20426]: timer 1 (28 0000-0055 'Zimmer frei!') start Mar 23 00:00:00 mm vdr[20426]: record /video0/Zimmer_frei!/2005-03-23.00:00.50.99.rec ... Mar 23 10:35:25 mm vdr[20430]: pcount in cSectionHandler::Action:24078000 Mar 23 10:35:26 mm vdr[20433]: pcount in cSectionHandler::Action:6408000 Mar 23 10:35:29 mm vdr[20430]: pcount in cSectionHandler::Action:24079000 -- Wolfgang

2 1

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

vdr