vdr February 2006

vdr@linuxtv.org

142 participants
169 discussions

Re: Audio channel problem
by Radek Rous 24 Feb '06

24 Feb '06

> Radek Rous wrote: > > Hello > > > > I have problem in VDR version 1.3.42 and 1.3.43. > > When I switching audio channels, I see only numbers instead > of short-name of > > audio track. > > In VDR 1.3.41 everything is OK. > > Please try the attached patch. > > Klaus It's working. Thank's. Radek

1 0

[RFC] Eliminating the 'summary' field of timers
by Klaus Schmidinger 24 Feb '06

24 Feb '06

Some (external) applications require a way of uniquely identifying timers. Currently some of these use the upper 16 bit of the 'flags' field, while others use the 'summary' field. In an effort to make things more straightforward (and simpler, from VDR's point of view ;-) I propose the following changes: - The 'summary' field in the timer definition becomes a pure string parameter, into which (external) applications can write whatever they like. VDR will read and write it, but otherwise won't do anything with it. The name of this field would be changed to something like 'aux' or so. - The description of a recording is taken exclusively from its related EPG data. If an application wants to use a different description it would have to set it with SVDRP/PUTE and use table ID 0x00, so that it won't be overwritten (as a side effect, however, this would also disable VPS for such an event). An added bonus of this method would be that not only the 'description' can be set, but also 'title' and 'short text'. - The upper 16 bit of the timer's 'flag' field are no longer given any special treatment, and also shouldn't be used. Only the flags defined in vdr.5 shall be used. - The cEvent::eventID is changed to u_int32_t so that fake event ids won't collide with real ones (by using values greater than 0xFFFF). - The 'E' record of the recording's EPG data will also be written into 'info.vdr'. - A new record in 'info.vdr' will hold the 'aux' string of the timer that created this recording. If we can agree on these changes until next weekend, I would incorporate them into the upcoming version 1.4. Klaus

10 53

Re: [vdr] Audio channel problem
by Klaus Schmidinger 24 Feb '06

24 Feb '06

Radek Rous wrote: > Hello > > I have problem in VDR version 1.3.42 and 1.3.43. > When I switching audio channels, I see only numbers instead of short-name of > audio track. > In VDR 1.3.41 everything is OK. Please try the attached patch. Klaus

1 0

change in cDevice::GetDevice between 1.3.37 and 1.3.38
by syrius.ml＠no-log.org 24 Feb '06

24 Feb '06

Hi, Could anybody recall me why that change occured ? I don't find it on the mailing list archive: @@ -302,7 +302,7 @@ pri = 6; // receiving with same priority but fewer Ca's else pri = 7; // all others - if (pri < select) { + if (pri <= select) { select = pri; d = device[i]; if (NeedsDetachReceivers) --

2 1

LoadPlugins should fail or ignore errors
by Udo Richter 23 Feb '06

23 Feb '06

Hi Klaus, I've stumbled over an inconsistency of the plugin load mechanism. Under regular conditions, plugins are loaded this way: if (!PluginManager.LoadPlugins(true)) EXIT(2); If loading a plugin fails, maybe because of dynamic linker error or ProcessArgs() returned false, no further plugins will be loaded, and VDR exits. In case of --help or --version however: PluginManager.LoadPlugins(); Now, if loading a plugin fails, VDR loads all plugins up to the failing one (which itself is in some in-between state), stops loading any more plugins, and outputs version and help for all plugins up to the failing one, maybe including the failing one. Version and help for all plugins _after_ the failing one is silently skipped. Shouldn't LoadPlugins be non-fatal for --help and --version? Eg. add an option to continue if dll->Load() fails? Cheers, Udo

1 0

VDR 1.3.43: can not attach receiver on DD PID
by Dr. Werner Fink 22 Feb '06

22 Feb '06

Hi, the bitstreamout plugin can not attach a receiver or the attached receiver does not receive for an DD PID. This leads to silent for all DD audio tracks. Sometime I can hear DD but then the VDR 1.3.43 is in transfer mode which is can be seen from /var/log/messages ... Beside this Mpeg Audio PIDs works flawless but also in this case the VDR 1.3.43 switches soemtime into transfer mode. It looks like the Receive() function of my cReceiver calls will never called by VDR. The Action() thread is Activate()ed by the appropiate functions but then never a bit of data reaches the Receive() function. Is this a known problem? Werner -- AC3 loop through sound card http://bitstreamout.sourceforge.net/ Howto http://www.vdr-portal.de/board/thread.php?threadid=1958 ------------------------------------------------------------------ "Having a smoking section in a restaurant is like having a peeing section in a swimming pool." -- Edward Burr

2 1

Which DVB-T
by Luis Palacios 22 Feb '06

22 Feb '06

Hi, I'm planning to bye a DVB-T pci or usb for my vdr box, as in Spain TDT is running pretty well. Any recommendation is greatly appreciated. Looking for one that works well with '2.6.xx' kernel (drivers available) and vdr 1.3.40. Thanks in advance, luis

5 10

fbxine display falls asleep???
by Hu-Emulator 21 Feb '06

21 Feb '06

This a follow-up to a earlier email. I was asking before when running fbxine that after about 10-15 minutes I get a black screen but still hear the audio and can change channels with the remote but with no OSD. And at that point I would just stop vdr and then restart for another 10-15 minutes. After the 3rd time it would be stable and not happen. Well so I was thinking if its a display issue and not vdr. So I rebooted and restarted fbxine and vdr. This time after 10-15 minutes and the screen went black and the audio was still working; I hit any key on my keyboard (remember display is out to tv) and wholla the video came back. However it would continue to go out after like 10-15 minutes. No matter how many times I had to just press a key on the keyboard. So its acting like the display is going in (screen saver mode)? How do I stop that when I am not using Xwindows but using fbxine? Video card Matrox g550 (output dvi input to tv hdmi) Settings: fbset -fb /dev/fb1 "1280x1024-70" -depth 16 -laced true fbxine command line: /usr/bin/fbxine --stdctl --deinterlace -V DirectFB -A alsa vdr:/tmp/vdr-xine/stream#demux:mpeg_pes > /tmp/xine.log 2>&1 Please see the screenshots at: http://www.putfile.com/vlive VDRversion: 1.3.43 vdr-xine plugin:vdr-xine-0.7.7 xine-lib & xine-ui CVS as of 2-14-06

2 1

multiImages on TV screen with fbxine
by Hu-Emulator 21 Feb '06

21 Feb '06

This is a follow up; I am having trouble getting the correct display on my 42" sony lcd projection tv. It is mostly noticable watching hdtv channels. When I watch a non hd channel the I get the left and right black boarders. Video card Matrox g550 (output dvi input to tv hdmi) Settings: fbset -fb /dev/fb1 "1280x1024-70" -depth 16 -laced true fbxine command line: /usr/bin/fbxine --stdctl --deinterlace -V DirectFB -A alsa vdr:/tmp/vdr-xine/stream#demux:mpeg_pes > /tmp/xine.log 2>&1 Please see the screenshots at: http://www.putfile.com/vlive VDRversion: 1.3.43 vdr-xine plugin:vdr-xine-0.7.7 xine-lib & xine-ui CVS as of 2-14-06

2 1

RE: [vdr] Streamdev HTTP attach not grabbing a free DVB card?
by Jukka Vaisanen 21 Feb '06

21 Feb '06

Jose wrote: >> In both cases I think if that card was already being used for a recording, >> that recording would get bumped off regardless of any priorities etc. >> Smells ugly..? >If a card is used for a recording, cDevice::GetDevice don't take it. But in the loop to find the device: >> for (int i = 0; i < cDevice::NumDevices(); ++i) { >> cDevice *dev = cDevice::GetDevice(i); >> if (dev->ProvidesChannel(current, 0) && dev != device) { newdev = dev; >> break; >> } I don't see how GetDevice could not "take" a device being used for recording since we're accessing it with an index number 0..(NumDevices-1) and not asking by channel + priority. And if GetDevice were to return NULL here for a device being used for recording, this would segfault on the dev->ProvidesChannel(...) call. So I think it *will* grab the first device (by index) that a) can serve this channel b) is not used for live tv. - Jukka Vaisanen

2 2

← Newer
1
2
3
4
5
6
7
...
17
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

vdr February 2006