vdr May 2006

vdr@linuxtv.org

122 participants
128 discussions

analogTV ffmpeg can't find video grab device
by Simon Baxter 28 May '06

28 May '06

I've been trying to get analogTV working with a PVR-150, but the ffmpeg fails. I ran the syntax myself: ffmpeg -f mpeg1video -s 352x288 -ad /dev/dsp:14 -ar 44.1 -vd /dev/video0 -ac 1 -b 2000 -ab 80 -y -re -title analogTV -author analogTV -copyright GPL -comment analogTV -aspect 4:3 -tvstd NTSC /tmp/.analogtv.avi and it fails as ffmpeg can't find the video grab device /dev/video0 but if I change it to: ... -i /dev/video0 ... the encoding starts ok, but I still don't see a picture. Any ideas??

1 0

[Patch] Fix calculating starttime of repeated timers with start date
by Udo Richter 28 May '06

28 May '06

Hi list, Referring to http://www.vdr-portal.de/board/thread.php?postid=468928#post468928 , here's a patch that fixes calculation of startTime in case that they (1) are weekly timers (2) have a start day set (3) have next scheduled recording more than 7 days in the future In this case, the timer will be sorted in the timer list at the start day, even if the start day doesn't match the weekday mask. (this can be down to two days from now for a timer that will record in 8 days) Since the fix is at a rather sensitive code piece, it could use some review and testing. The change only affects repeated timers with start date set. The fix does two things: First, the scan loop for matching timer events is shifted from now (or whatever t is) to the scheduled start day. That way the loop should always find a match. Second, the startTime safety catchup is changed to a time that is really one week in the future - 'day' may be earlier. However, I don't think that this catch is triggered at all any more. Cheers, Udo --- vdr-1.4.0-orig/timers.c 2006-05-20 18:50:49.000000000 +0200 +++ vdr-1.4.0/timers.c 2006-05-20 18:50:54.000000000 +0200 @@ -347,7 +347,7 @@ } else { for (int i = -1; i <= 7; i++) { - time_t t0 = IncDay(t, i); + time_t t0 = IncDay(day ? max(day, t) : t, i); if (DayMatches(t0)) { time_t a = SetTime(t0, begin); time_t b = a + length; @@ -359,7 +359,7 @@ } } if (!startTime) - startTime = day; // just to have something that's more than a week in the future + startTime = IncDay(t, 7); // just to have something that's more than a week in the future else if (!Directly && (t > startTime || t > day + SECSINDAY + 3600)) // +3600 in case of DST change day = 0; }

6 25

Request: call plugin Makefiles with install target
by s.huelswitt＠gmx.de 28 May '06

28 May '06

Hi, it would be nice if during install the main Makefile would call the plugin Makefiles with install target. Normaly this would be an empty target, but if the plugins needs additional files e.g. config files or sub-libraries they could be copied here. Yes, I know that this change would break all plugins for the moment (until all have implemented an install target), so may be the main Makefile could grep the plugin Makefile for the install target and call it only when present. I can prepare a patch if wanted. Regards. -- Stefan Huelswitt s.huelswitt(a)gmx.de | http://www.muempf.de/

2 2

RFC: recording strategy on timer conflicts
by Christian Wieninger 28 May '06

28 May '06

Hi, I'm currently working on a tool that checks for timer conflicts and became aware of the following problem: Suppose you have the following 3 timers on a system with two DVB cards: nr. transponder - start - priority 1. A - 20:10 - 45 2. B - 20:10 - 5 3. C - 20:11 - 50 A,B,C are different transponders. VDR will start recording from transponder A at 20:10 with device 2. The same for transponder B with device 1. At 20:11 we have a conflict and IMHO VDR should stop timer 2 and start timer 3 on device 1. But when I check the logs the following occures: VDR first stops timer 1 on device 2 and starts timer 3 on device 2. Then it recognizes the pending timer 1 with higher priority than the running timer 2 and stops this one. So in the end all is fine, but there is a small break about 1-2 seconds in recording 1. The problem is, that cDevice::GetDevice handles the two devices in this case with the same priority and therefore returns the device with the highest number. I think one could fix this with a small change (patch against 1.4.0 is attached), but the whole thing is really complicated and I do not have a real deep insight in the side effects ;-) , so perhaps you could give a comment on this. BR, Christian

5 14

[PATCH] Priority of transfer-mode should not be -1
by Anssi Hannula 27 May '06

27 May '06

Hi! The transfer-mode uses always priority -1. That presents a problem: If I connect to that vdr using streamdev, it switches the first budget device off from the multiplex transfered to the FF card, although there is a second identical budget device available. Also, if I had DVB-S FF and only one DVB-T budget and had a DVB-T recording with priority 10 and Primary Limit at 20, live DVB-T video would (wouldn't it?) be severed. Klaus, shouldn't transfer-mode be also using the Primary Limit value, so that recordings with priority less than Primary Limit couldn't distract the output of primary device? Patch attached. -- Anssi Hannula

5 23

VDR constantly tries to change transponder frequency
by Anssi Hannula 27 May '06

27 May '06

Hi! VDR constantly changes the frequency of one multiplex in DVB-T. Here's an example: Correct: Urheilukanava;Suomen Urheilutelevisio Oy:770000000:C23D23M64B8T8G8Y0:T:27500:417+130:673=fin:929:0:113:8438:12289:0 But then VDR decides to change it: Dec 29 18:32:48 delta vdr[18069]: changing transponder data of channel 22 from T:770000000:0:3:0:2:2:2:1 to T:674000000:0:3:0:2:2:2:1 And then of course the channels stop being watchable. I took a dvbsnoop on PID 16 to grab the NIT tables (or whatever they're called). The two SECT-packets which are looped in the PID 16 are both in: http://anssi.hopto.org/dvbsnoop-MUX3-pid16 BTW, I put a debug output entry in nit.c line 173 to grab the frequency returned by getFrequency(), and I get these kind of results: FREQUENCY, 562000000 FREQUENCY, 658000000 FREQUENCY, 674000000 However the correct frequencies of the muxes are 490000, 578000, and 770000. However I've no idea why mux3 is the only one of which frequency VDR tries to change. -- Anssi Hannula

2 11

Some small bug in vdr 1.4.0
by Tobias Grimm 26 May '06

26 May '06

Hi! While checking some plugins with valgrind, I stumbled across this minor bug in vdr: The skinDescriptions array allocated in cMenuSetupOsd should be deleted with delete[] instead of delete. bye, Tobias --- vdr-1.4.0.orig/menu.c +++ vdr-1.4.0/menu.c @@ -2131,7 +2131,7 @@ cMenuSetupOSD::~cMenuSetupOSD() { cFont::SetCode(I18nCharSets()[Setup.OSDLanguage]); - delete skinDescriptions; + delete[] skinDescriptions; } void cMenuSetupOSD::Set(void)

3 5

DVB-S CI used by DVB-C?
by Kent Nielsen 26 May '06

26 May '06

Hi, I have a Technotrend Rev. 1.5 (FF) card, and also an internal CI (came with Fujitsu-Siemens Rev. 1.3). I will buy a Technotrend Budget C-1500 (DVB-C) without a CI. I believe I can use first one as front end, but can I use first one's CI to decrypt DVB-C channels (Conax). Should it work? Does anybody have similar setup? Thanks in Advance, Kent Nielsen

2 1

Xineliboutput + network
by CR 25 May '06

25 May '06

Hi all, I am re-attempting a vdr networked setup. I recently discovered the "xineliboutput" .99rc plug-in which has network support built in. Has anyone been able to get this to work? Using vdr 1.3.48 + xineliboutput .99rc , on the client side I continue to get error messages that it cannot connect, despite having compiled same version of xine-lib on both server/client (fresh), and verifying all the settings on both sides correct. I have applied the xineliboutput "frontend" patch too. Regards, CR.

3 5

Livna repository vdr restart problem
by Kartsa 25 May '06

25 May '06

I am having a problem with restarting vdr. I've installed FC5 and then vdr from livna repository. The problem is that if watchdog kicks in vdr is not restarted. Am I forgetting something? Same thing happens if I choose restart using remote. I have VDR_OPTIONS=(--watchdog=20 --lirc) in /etc/sysconfig/vdr. Shouldn't runvdr take care of the restarting? \\Kartsa

3 3

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

vdr May 2006