Re: [vdr] xine, eepg and 64 bits
Hi, Did you solve the eepg problem? I am experiencing the same error. Slackware64-current, just upgraded a bunch of stuff (including xserver), previously successful compile of eepg when recompiled eepg gives me the same error as below. The libvdr-eepg.so from the earlier compile still works so no broken vdr from that point. Custom kernel, VDR and other plugins compile without issue. Just eepg bails with the reported error. So suspicion initially lies with eepg but it compiled fine before the update so... I am inspecting the Slackware-current updates to see what could have broken this build and if anyone can provide some ideas to assist that would be welcomed. Ian. On 15 Aug 2010, at 07:44, marti...@embl.de marti...@embl.de wrote: I upgraded my installation to arch linux x86-64 (from ubuntu 32bits) and now using the same source files for vdr-1.7.15 everything compiles and works except two things: a) the eepg plugin refuses to compile: eepg.c:2687:35: error: expected ‘)’ before ‘*’ token eepg.c:2776:16: error: expected constructor, destructor, or type conversion before ‘(’ token eepg.c:4222:31: error: expected ‘}’ at end of input Can somebody help ideally by pointing out what I need to do to get it to compile and failing that supplying a 64 bits compiled libvdr-eep.so.1.7.15 ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] LNB settings - what should they be?
On 25 Sep 2010, at 10:20, Simon Baxter wrote: Hi My dvb-s LNB is a Ku-Band LNBG DKF-2024. The box says: Input 11.70-12.50 Ghz L.O. 10.75 Ghz Noise 0.6dB Gain 60dB If I set VDR up as follows: Use DiSEqC:no SLOF (MHz):10750 Low LNB frequency (MHz): 11700 High LNB frequency (MHz): 12500 When I change channels I get: Sep 25 21:15:18 localhost vdr: [2058] ERROR: frontend 0/0: Invalid argument Sep 25 21:15:18 localhost kernel: DVB: adapter 0 frontend 0 frequency 12456000 out of range (95..215) If I set it to Use DiSEqC:no SLOF (MHz):11300 Low LNB frequency (MHz): 11300 High LNB frequency (MHz): 11300 I don't get this error, but get: Sep 25 21:15:57 localhost vdr: [2058] frontend 0/0 timed out while tuning to channel 3, tp 112456 Sep 25 21:17:02 localhost vdr: [2058] frontend 0/0 timed out while tuning to channel 3, tp 112456 Sep 25 21:18:07 localhost vdr: [2058] frontend 0/0 timed out while tuning to channel 3, tp 112456 I'm using a dm1105 dvb-s card which works under Windows on the same box, but szap and VDR do not. I can scan channels though with: ./scan dvb-s/OptusB1-NZ -l 11300 -x 0 OptusB1-NZ being: S 12456000 H 2250 AUTO S 12483000 H 2250 AUTO Any suggestions? An 'it works for me' and a suggestion. - 'it works for me': I have a Universal LNB, I'm in the UK, my VDR settings are (setup.conf), LnbFrequHi = 10600 LnbFrequLo = 9750 LnbSLOF = 11700 - A Suggestion: From, http://www.satsig.net/cgi-bin/yabb/YaBB.pl?board=ivsat-asia;action=display;num=1142160105 Receivers typically accept L band signals in a range starting at 950 MHz. If you want to receive satellite signals starting at 10.7 GHz then you need a LNB LO of 9.75 GHz. Maybe Astro are starting some services in the band 10.7 - 10.95 GHz ? For satellite TV, 'universal' LNBs with switchable LO frequencies of 9.75 and 10.6 GHz seem to be common. For Ku band reception, LO frequencies of 10, 10.75 and 11.3 GHz are also available. No idea, just guessing, try rearranging your values in the same sort order a my 'it works for me' section, High LNB frequency (MHz): 11700 Low LNB frequency (MHz): 10750 SLOF (MHz):12500 Don't know if this will fry your silicon. ?? Ian. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [PATCH] Add support for shared frondends cards
On 21 Sep 2010, at 16:06, support.intranet wrote: The attached patch (for VDR 1.7.16) implements support for multituner cards where only one tuner can be active at one time, the so called shared frontend cards (notably the HVR-4000 and its derivatives). Currently VDR tries to open all the frontends on startup, with the result that the first frontend (usually DVB-S) works, but the second (usually DVB-T) fails with Device or resource busy error. The patch adds a new configuration option to setup.conf, called OnDemand; it defaults to 0 (exactly the current behaviour). If set to 1, tuners will be appropriately opened and closed when switching channels. I've tested it with the vnsi plugin and XBMC. I'd be happy if someone could review it and tell me if there is anything to correct and if it is possible to mainline it. Alberto aod.diff___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr Ciao Alberto, Interesting work. I live in the UK and have an HVR4000 for DVB-S. Unfortunately DVB-T reception is poor where I live (hence the satellite solution - additional multilnb to point at 28.2E and 13.0E for L'Eridita) so I cannot fully test this past patching and compiling which I assume will work as you state you have tested. Looking at the patch, there is something about inhibit epgscan. I do not know much about vdr internals. Would patching vdr and enabling the ondemand option stop epg from updating? A slight negative if this is the case. Ian. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Impact in cDevice::GetDevice
Good Morning, From what I recall of discussions held on this list the reasons are based on, in no particular order :), First - initial basic common sense then an iterative process involving - satisfaction of common corner use cases - satisfaction of problem use cases - keeping most people happy most of the time - keeping some people happy some of the time i.e. a can of worms. I am sure others can provide a more insightful technical response. Ian. On 24 Aug 2010, at 06:57, Rainer Blickle wrote: Hi, in the method cDevice::GetDevice the device with the least impact is searched (the block with imp = x; imp |= ). For calculating the impact (higher value = bigger impact) some facts are used. The most prio fact is prefer the primary device for live viewing, the least prio is prefer CAMs that are known to decrypt this channel. Does anyone know why the facts are ordered in this way ? Why ?: At the moment i'm developing a patch providing alternative channels. An alternative channel is a channel providing the same programme as the original channel, but with another receiving technique (like DVB-T instead of DVB-C). My alternative technique is analoge (via pvrinput). For this, i introduced a new fact programme is received from an alternative channel. Therefor i have to define the priority of this new fact regarding the impact. So i'd like to know more why the prio is as it is. Regards, Rainer ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] feature request easy diseqc setup and channelscan for vdr
On 6 Feb 2010, at 11:57, Klaus Schmidinger wrote: On 02.02.2010 07:35, Ian Bates wrote: On 1 Feb 2010, at 22:24, abbe normal wrote: On 2/1/10, VDR User user@gmail.com wrote: On Mon, Feb 1, 2010 at 7:12 AM, Halim Sahin halim.sa...@t-online.de wrote: Hi List and Klaus, It would be really nice if vdr could support diseqc setup directly in vdr. I don't know if this can be done by a plugin but the current solution is difficult for endusers. Setting a diseqc.conf needs some knowledge in diseqc and it's commands. A simple interface for creating a diseqc.conf can improove the usability of vdr! Personally I think adding support for multiple diseqc switches is a more important feature as I've noticed several users asking how to do this in VDR -- which it unfortunately doesn't support. I think this is actually one of the reasons some guys fumble around trying to cascade their diseqc switches. However, not all switches can be cascaded and so they're left stuck. Can't cascade, and no support for multiple switches. hey guys i agree multi cards should be able to use mutli diseqc configs... or at least be able to assign them to different switches that could be used... would be nice to add more dishes and lnbs to my setup... would like to do c and ku band dvb as well as have at least 2 to 3 fixed dishes with lnbs on them now im limited to 4 max or use a very costly switch... abby Dear all, I have a diseqc-patch I that hacked together a couple of years ago relating to multi-cards/multi-switches that has served my purpose well. It may not be the best way, it may even be the wrong way. I will drag it out of the VDR box for all to see but that will not be for a couple of days. MOTIVATION I have three LNBs (28.2/5, 19.2, 13.0) and two cards, each card attached to a 4-way diseqc switch. Despite the switches being the same model and bought at the same time each one responds to a different set of diseqc commands to change LNB. IIRC one seemed to behave as a cascade of 2-way switches, the other responded to the more usual commands for a 4-way switch. DESCRIPTION Enter my hack. It allows diseqc commands to be defined on a per-card basis (numbered 1, 2, ...). How you determine which number corresponds to which card is left as an exercise for the reader (hint: the margin may not be big enough). These defines are placed in 'diseqc-multi.conf' and start with the card number but are otherwise the same format as those found in 'diseqc.conf'. CONFIGURATION Configuration options within VDR are: - use only the diseqc.conf defines, - use only the diseqc-multi.conf, - use the disqc-multi.conf if a card definition appears otherwise use the diseqc.conf defines. I don't like the introduction of a separate diseqc-multi.conf file, and also those additional setup options in VDR. What about simply extending the existing diseqc.conf file to accept device numbers, as in: 1 2 4: S19.2E 11700 V 9750 t v W15 [E0 10 38 F0] W15 A W15 t S19.2E 9 V 10600 t v W15 [E0 10 38 F1] W15 A W15 T S19.2E 11700 H 9750 t V W15 [E0 10 38 F2] W15 A W15 t S19.2E 9 H 10600 t V W15 [E0 10 38 F3] W15 A W15 T 3 5: S13.0E 11700 V 9750 t v W15 [E0 10 38 F4] W15 B W15 t S13.0E 9 V 10600 t v W15 [E0 10 38 F5] W15 B W15 T S13.0E 11700 H 9750 t V W15 [E0 10 38 F6] W15 B W15 t S13.0E 9 H 10600 t V W15 [E0 10 38 F7] W15 B W15 T This could mean that devices 1, 2 and 4 can receive S19.2E, while devices 3 and 5 can receive S13.0E. If no device numbers (followed by a ':') are given, a setup where every device can receive every satellite is assumed. Once a line with device numbers (followed by a ':') appears, these apply to all following diseqc lines, until the next line with device numbers is seen. If a diseqc line is parsed without a previous device line, that diseqc line applies to all devices. Klaus Dear Klaus, all, That sounds good. Using this proposal I would configure my system with the following diseqc.conf: # diseqc.conf S28.2E a1... S28.2E a2... S28.2E a3... S28.2E a4... S19.2E b1... S19.2E b2... S19.2E b3... S19.2E b4... S13.0E c1... S13.0E c2... S13.0E c3... S13.0E c4... 2: S28.2E A1... S28.2E A2... S28.2E A3... S28.2E A4... S19.2E B1... S19.2E B2... S19.2E B3... S19.2E B4... S13.0E B1... S13.0E B2... S13.0E B3... S13.0E B4... # EOF where [a-cA-C][1-4]... are diseqc command sequences. If I understand correctly, with Klaus' proposal my 'normal' switch (card 1) would use the [a-c][1-4]... commands, and my problem switch (attached to card 2) would use the [A-C][1-4]... commands. Any additional cards would also use the [a-c][1-4]... commands. Unless I have understood incorrectly this gets my vote, if someone implements! Ian. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] feature request easy diseqc setup and channelscan for vdr
On 1 Feb 2010, at 22:24, abbe normal wrote: On 2/1/10, VDR User user@gmail.com wrote: On Mon, Feb 1, 2010 at 7:12 AM, Halim Sahin halim.sa...@t-online.de wrote: Hi List and Klaus, It would be really nice if vdr could support diseqc setup directly in vdr. I don't know if this can be done by a plugin but the current solution is difficult for endusers. Setting a diseqc.conf needs some knowledge in diseqc and it's commands. A simple interface for creating a diseqc.conf can improove the usability of vdr! Personally I think adding support for multiple diseqc switches is a more important feature as I've noticed several users asking how to do this in VDR -- which it unfortunately doesn't support. I think this is actually one of the reasons some guys fumble around trying to cascade their diseqc switches. However, not all switches can be cascaded and so they're left stuck. Can't cascade, and no support for multiple switches. hey guys i agree multi cards should be able to use mutli diseqc configs... or at least be able to assign them to different switches that could be used... would be nice to add more dishes and lnbs to my setup... would like to do c and ku band dvb as well as have at least 2 to 3 fixed dishes with lnbs on them now im limited to 4 max or use a very costly switch... abby Dear all, I have a diseqc-patch I that hacked together a couple of years ago relating to multi-cards/multi-switches that has served my purpose well. It may not be the best way, it may even be the wrong way. I will drag it out of the VDR box for all to see but that will not be for a couple of days. MOTIVATION I have three LNBs (28.2/5, 19.2, 13.0) and two cards, each card attached to a 4-way diseqc switch. Despite the switches being the same model and bought at the same time each one responds to a different set of diseqc commands to change LNB. IIRC one seemed to behave as a cascade of 2-way switches, the other responded to the more usual commands for a 4-way switch. DESCRIPTION Enter my hack. It allows diseqc commands to be defined on a per-card basis (numbered 1, 2, ...). How you determine which number corresponds to which card is left as an exercise for the reader (hint: the margin may not be big enough). These defines are placed in 'diseqc-multi.conf' and start with the card number but are otherwise the same format as those found in 'diseqc.conf'. CONFIGURATION Configuration options within VDR are: - use only the diseqc.conf defines, - use only the diseqc-multi.conf, - use the disqc-multi.conf if a card definition appears otherwise use the diseqc.conf defines. CAVEATS For my purpose this patch works well. I am aware there exist other multi-satellite/multi-card patches that may address a similar problem but I haven't used them. You'll have to wait a couple of days before I can pull it off my vdr box. Current version works with vdr-1.7.11. This patch has survived with minimal/no changes from at least the first vdr-1.6 releases. Sorry to whet your appetites without satiating them. Ian. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.7.11
On 6 Jan 2010, at 13:22, Tomasz Bubel wrote: [...] - Added support for DVB cards with multiple fontends. Note that this only works for DVB cards where each frontend can be used independently of all the others on the same adapter. [...] Any chance of using using DVB-T frontend on HVR-4000? This card have 2 separate frontends. And as quoted on http://www.linuxtv.org/wiki/index.php/Hauppauge_WinTV-HVR-4000: Multiple frontends are supported: DVB-S/S2 and DVB-T appear as /dev/dvb/adapterN/frontend0 and /dev/dvb/adapterN/frontend1 respectively. Due to a hardware limitation, the two frontends cannot be used simultaneously. However they can be used sequentially within the same application. The driver handles the mutual exclusion appropriately. Ping. I have this card and I am aware that the frontends cannot be used simultaneously. I was unaware of the statement regarding sequential use within the same application. With even just a little thought I can see that this is not at all the same as 'simultaneous.' It does raise at least the possibility of a VDR setup config to use DVB-T rather than DVB-S, instead of the game of symlinks that I play at the moment (manual, one time choice of DVB-T or DVB-S, not satisfactory and low WAF). I can imagine that something like this is not a simple addition to implement but if there is currently momentum in this direction then more 'effort' at this stage will be more effective than at a later date. I have not given this much thought at all and I am yet to explore the potential of the SourceCaps patch. These comments are really an expression of interest in developments of the features of the HVR4000 (that I imagine most VDR/HVR4000 users share). Enough of my babbling. Best wishes, Ian. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] lirc-0.8.6 moved socket to /var/run/lirc/lircd
On 29 Sep 2009, at 20:54, Matthias Schwarzott wrote: On Dienstag, 29. September 2009, Helmut Auer wrote: Hi list! lirc starting from version 0.8.6, does use the socket /var/run/ lirc/lircd instead of /dev/lircd, so all apps not using liblirc_client need to be changed. Else IR will not work in VDR. There are two possibilities: 1. Shell code to check which of the two sockets do exist and adding relevant command-line-parameter to vdr (--lirc=/var/run/lirc/lircd). 2. Patching VDR to check both pathes and using the existing one. 3. Change lirc to use /dev/lircd In gen2vdr ( =gentoo ) I set: LIRCD_OPTS=-o /dev/lircd in /etc/conf.d/lircd :) Nice to know that it can be changed, but I have a big BUT: Does irw and all other apps using liblirc_client then still work? I doubt, as they have the new name compiled in. I confirm irw does not work when using the '-o wherever' switch with lirc-0.8.6 (cvs from about a month ago). I guessed but was not sure it had something to do with a compiled-in patch. I came across this issue when playing with an xbmc-pvr install. While debugging the install my work around was as 1. above. Ian. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] Editing recordings and no instant video update when moving markers
Hello, When editing recordings I am struggling to fine tune marker placement as adjustments made with '4' and '6' keys while moving the marker as indicated by the time line do not update the video display with the corresponding position in the recording. Current setup: SW: VDR-1.7.9 (with freesat patch), NVIDIA driver 185-something, xineliboutput and xine as outptut plugins, ffmpeg-svn / xine-lib-1.2- hg from about two weeks ago, v4l-dvb-hg from about two weeks ago, slackware64-current OS HW: M2NPV-VM with onboard Nvidia 6150, Athlon something 64 bit dual core (at least 2.1GHz), a couple of SATA disks. - This problem only occurs with TS recordings, PES recordings made with vdr-1.7.0 with this setup work as expected. - With the xineliboutput plugin the display does not update at all when moving the marker. - With xine plugin the display updates but with seemingly random time intervals, from almost realtime as expected to delays of 1-5 seconds to sometimes not at all, depending on the recording and the position of the marker. I have a tedious workaround: set marker, play - If adjustment needed then - select marker, adjust with '4' or '6', play, repeat until no further adjustment needed. Does anyone have the same problem? Does anyone NOT have this problem? What can I do to fix this? Best wishes, Ian. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Where do you live and what kind of broadcast do you receive?
Country: UK (receiving Astra 28.2E, Astra 19.2E and Hotbird-13E) Transmission: DVB-S, DVB-S2 (DVB-T technically available but locally poor reception) Encoding: MPEG-2 SD, H.264 Hardware: Hauppauge NOVA PCI (DVB-S), Hauppauge HVR4000 (DVB-S/S2) (-T available but untested) ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] HVR-4000, vdr-1.7.2 and v4l-dvb'hg ?
Gregoire Favre wrote:
On Tue, Dec 30, 2008 at 11:36:41AM +0100, Oleg Roitburd wrote:
That was my fist assumption too, BUT frontend0 is DVB-S and don't tune
to any DVB-S channels (or DVB-S2) so I guess there is another problem.
I have no DVB-T channel in VDR to test.
Is someone able to use his HVR-4000 with vdr-1.7.2 ?
Thanks.
DVB: registering adapter 1 frontend 0 (Conexant CX24116/CX24118)...
DVB: registering adapter 1 frontend 1 (Conexant CX22702 DVB-T)...
cx88[1]/2: subsystem: 14f1:0084, board: Geniatech DVB-S [card=52]
cx88[1]/2: cx2388x based DVB/ATSC card
CX24123: detected CX24123
DVB: registering new adapter (cx88[1])
DVB: registering adapter 2 frontend 0 (Conexant CX24123/CX24109)...
The problem is certainly in :
DVB: registering adapter 1 frontend 0 (Conexant CX24116/CX24118)...
DVB: registering adapter 1 frontend 1 (Conexant CX22702 DVB-T)...
The card tune well for example with kaffeine to BBC HD.
Any idea on how to use it with VDR (dvb-t is of second interest to me) ?
--
VDR doesn't support MFE (Multifrontend) features of S2API
in dvbdevice.c
cDvbName(const char *Name, int n) {
snprintf(buffer, sizeof(buffer), %s%d/%s%d, DEV_DVB_ADAPTER, n, Name,
0);
}
-
It will tries always frontend0
Hello G-F, all,
A data point which you may already have. I am using:
- an HVR4000
- recent S2API v4l-dvb from HG
- vdr-1.7.0 with patches from this mailing list (h264, s2api)
- recent xineliboutput from CVS
and I am able to receive DVB-S and DVB-S2 channels
I also have not tried DVB-T (due to lack of signal).
I have not upgraded to vdr 1.7.2 as I understood changes involving the
switch to TS had not been addressed by xineliboutput (not tested).
--
__
Ian Bates
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] xineliboutput: viewing 16:9 content on 4:3 output device
Torgeir Veimo wrote: So (finally) a direct question: how do people with 4:3 output devices and vdr with xineliboutput configure their boxes? (shameless plug) Did you actually try softdevice? Dear Torgeir, Nothing shameless about the plug! Yes, I have tried softdevice (recent CVS and recent SVN of ffmpeg). It is actually what I use for viewing streamed TV (from my main VDR) on my not-so-perfect laptop LCD. The crop to 4:3 feature works in the way I hoped (4:3 shown as is, 16:9 cropped to show central 4:3 portion). However, as most things in life, there are some things that do not work as I would like for main TV viewing: 1. The default deinterlace options, IMHO, do not compare to the tvtime plugin available using xineliboutput (compare fast-action streams such as tennis, snooker and football) 2. I cannot watch HDTV content, which I am able to do with the xineliboutput plugin. For sure the deinterlace is of more importance than viewing HDTV (why would I want to do that on a standard CRT in any case? Proof of concept and anticipation of a future TV upgrade is the answer). Both xineliboutput and softdevice, as many users I am sure will testify, are good pieces of software. However, for my use, both have their pros and cons. I usually explore as many configuration options as I can, but please if there is something I have missed that will allow me to have, 1. Excellent deinterlacing 2. Watchable HDTV/H264 3. 16:9 cropped to 4:3 then please let me know! In the mean time I am looking at the patch Darren Salt brought to my attention for xine-lib, and the xine post plugin 'expand' (with special attention to Reinhard Nissl's center_cut/crop_out mode') to see if I can hack something for xineliboutput, re cropping 16:9 to 4:3. Noone hold their breath though. Thanks to everyone for their help and suggestions. More welcome too. Kind Regards, Ian. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] xineliboutput: viewing 16:9 content on 4:3 output device
Dear all, I have lurked a while on this list but until now have not had reason to post. I am unable to configure xineliboutput to my liking. I don't imagine I am the only one with this issue, but I have not been able to find a solution, either by trial and error or by googling. I would appreciate to hear how other people configure their vdr boxes. My output device is a 4:3 analog TV. Watching a 4:3 stream is fine in the sense that the full real estate of the TV is used. Watching a 16:9 stream results in (depending on various settings I have tried) either the stream 'compressed' vertically to maintain the 16:9 ratio (with black bars top and bottom), or a vertically 'stretched' image that loses the 16:9 ratio but fills the entire TV screen. What I would like is to maintain the stream 16:9 ratio but by by cropping the left and right sections of the stream that fall 'outside' the TV, so the full real estate of the TV is used, at the expense of losing some stream information. I have played with various xineliboutput settings, all through the OSD plugin setup menu. My current settings are roughly: LOCAL FRONTEND: Using Xv and set to fullscreen and stretched-to-window video. Aspect ratio set to 4:3 (although PanScan and CenterCutOut looked promising but don't do what I thought they might). VIDEO: aspect ratio set to automatic. Anything else seems to force the aspect ratio to that value. Software scaling does not seem to be the route to follow either. Autocrop 4:3 letterbox to 16:9 is disabled, but also looked promising, but I could not obtain the bahaviour I desire. So (finally) a direct question: how do people with 4:3 output devices and vdr with xineliboutput configure their boxes? Some brief details of my system: I am using vdr 1.6.0, a recent-ish (last few days) xineliboutput CVS version running under X (i.e. vdr-sxfe) on a NVIDIA 6150 device with the binary NVIDIA module (TV-out at 720x576) watching DVB-S streams (thanks to a NOVA-S-Plus and a HVR4000 with multiproto, for what that is worth), all connected to a 4:3 aspect ratio TV. I thought this would be a quick question but I have managed to write an epic! Sorry about that. Best wishes, Ian. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
