[vdr] Xineliboutput: can achieve similar to softdevice's mgatv option?
Can vdr-xineliboutput utilize the excellent interlaced output of a Matrox G450 with VGA>SCART cable? I'm seeing what I can only describe as video stutters/shakes with interlaced video and quick movements, long camera pans. Using latest vdr-xineliboutput, DirectFB-1.0.0 & xine-lib-1.1.5 using Gentoo ebuilds. Otherwise xineliboutput is working fantastically! (well without any sound but that's another issue for another day :-) ) -- A l a s d a i r C a m p b e l l r a g a w u @ g m a i l . c o m ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Xineliboutput: can achieve similar to softdevice's mgatv option?
On 18/04/07, Markus Schuster <[EMAIL PROTECTED]> wrote: > Can vdr-xineliboutput utilize the excellent interlaced output of a > Matrox G450 with VGA>SCART cable? I'm asking myself the same question. I've played arround with xineliboutput and softdevice the last days and came across the same issues you reported. If you make any progress please let me know! > I'm seeing what I can only describe as video stutters/shakes with > interlaced video and quick movements, long camera pans. I experience a very simmilar problem here. For a few seconds, video is very well and the next few seconds I have those problems you describe. It seams that sound also has some problems while video stutters (at least here), but it is not this noticeable. The problem does not happen when using the normal monitor as output device. I'm noticing these effects on a less noticeable basis with Softdevice, and here I get the audio stutters. With softdevice cpu can max out on my P3 550Mhz, especially when the OSD is shown. Whats strange is top shows cpu cost shifting constantly from less than 20% to +97%. I've never seen this behaviour with softdevice before (first time using xine-lib). What sort of hardware do you have? > Using latest vdr-xineliboutput, DirectFB-1.0.0 & xine-lib-1.1.5 using > Gentoo ebuilds. Exactly the same here, but on Debian Etch with all components built from source. That's vdr-xineliboutput 1.0.0rc1, DirectFB 1.0.0 and xine-lib 1.1.5 on Debian Etches default kernel (2.6.18). > Otherwise xineliboutput is working fantastically! Well, I think it's a bit hard to say that xineliboutput works fantastically as I can't rate it with this problems. But what I can say for sure is that CPU load is a bit lower than with softdevice. But sound works for me with both :) There seem to be some problems with aspect ratio with xineliboutput, but as you say, that's another issue... Greetings, Markus Fantastic was an exaggeration certainly..Just trying to be optimistic! CPU load lower with xine-lib here as well. On a purely visual basis, when xine-lib isn't stuttering (field sync tripping out?) the image is actually better than my set top box. Colours arn't as harsh, video is less pixelated , text on my scrolling news channel is very good looking, almost anti-aliased :-) However the interlacing problems are happening every couple of seconds. In the original post I was just wondering if xineliboutput has been written with the matrox specific instructions that softdevice's "-vo dfb:mgatv" uses. As I don't understand the difference between "-vo dfb:" & "-vo dfb:mgatv" I can't really say what difference this would make. Should have mentioned I'm using a 16:9 CRT to view all this, and I don't have a monitor on the first head at all. Whats funny is that when I was last struggling with vdr-softdevice on an old 4:3 TV I could easily get fantastic output when I set the aspect to 16:9, of course this caused a huge overscan, meaning it wasn't much of an option. -- A l a s d a i r C a m p b e l l r a g a w u @ g m a i l . c o m ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Xineliboutput: can achieve similar to softdevice's mgatv option?
On 19/04/07, Torgeir Veimo <[EMAIL PROTECTED]> wrote: On 19 Apr 2007, at 09:41, Alasdair Campbell wrote: > > In the original post I was just wondering if xineliboutput has been > written with the matrox specific instructions that softdevice's "-vo > dfb:mgatv" uses. As I don't understand the difference between "-vo > dfb:" & "-vo dfb:mgatv" I can't really say what difference this would > make. I belive this is entirely dependent on what xine instance you're using with xinelib. Are you using df_xine? I think it should handle field parity correctly. I'm firing up df_xine now to see if there's any similarity. OK, playing a copy of some interlaced video with scrolling text (BBC News 24). Using df_xine -a 5:4 -l 0 -s -f top 001.vdr I get perfect output! This is what Markus and I are seeing for a few seconds before the field sync gets screwed With df_xine -a 5:4 -l 0 -s -f bottom 001.vdr The output is constantly like the stuttering video we're seeing most of the time. So somehow xineliboutput is losing field sync, should be a simple fix then... :-) Needless to say I have no audio, buts it just a configuration problem at my end. -- A l a s d a i r C a m p b e l l r a g a w u @ g m a i l . c o m ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Xineliboutput: can achieve similar to softdevice's mgatv option?
Sorry for replying to myself, but in the meantime, while waiting for xineliboutput to work again, anyone reading know if I can use df_xine for the video display, while retaining xineliboutput as the lirc transport to my headless server running vdr-xineliboutput. ** I know there has been a tremendous amount of work from everyone in respect to Matrox TV-Out already, sorry to keep bugging you all ;-) ** -- A l a s d a i r C a m p b e l l r a g a w u @ g m a i l . c o m ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Xineliboutput: can achieve similar to softdevice's mgatv option?
On 19/04/07, Petri Hintukainen <[EMAIL PROTECTED]> wrote:
On Thu, 2007-04-19 at 12:53 +0100, Alasdair Campbell wrote:
>
> Using df_xine -a 5:4 -l 0 -s -f top 001.vdr
> I get perfect output! This is what Markus and I are seeing for a few
> seconds before the field sync gets screwed
>
> With df_xine -a 5:4 -l 0 -s -f bottom 001.vdr
> The output is constantly like the stuttering video we're seeing most
> of the time.
>
There should be similar setting in $HOME/.xine/config_xineliboutput
(search for video.device.directfb_field_parity)
Maybe this is due to me running as root (I know this is bad, just for
testing) but each time I run vdr-fbfe it seems to clobber the
config_xineliboutput file, and reinstate "none" for field parity.
# field parity
# { none top bottom }, default: 0
#video.device.directfb_field_parity:none
Setting wait for vertical retrace stays set at 1, after setting it a
few minutes ago. I presume I want that with my G450.
--
A l a s d a i r C a m p b e l l
r a g a w u @ g m a i l . c o m
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Xineliboutput: can achieve similar to softdevice's mgatv option?
ignore that, I was being an idiot, set to 'top' now. -- A l a s d a i r C a m p b e l l r a g a w u @ g m a i l . c o m ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Xineliboutput: can achieve similar to softdevice's mgatv option?
On 20/04/07, Markus Schuster <[EMAIL PROTECTED]> wrote: If you have the softdevice source code laying arround, you can have a look in that, especially 'video-dfb.c'. Search for 'setupStore->useMGAtv'. There are some if-constructs in there using this variable where some DirectFB settings (and maybe some other settings, haven't looked this closely) are set. I'll have a look at the softdevice src this weekend & compare with xineliboutput. -- A l a s d a i r C a m p b e l l r a g a w u @ g m a i l . c o m ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Xineliboutput: can achieve similar to softdevice's mgatv option?
On 20/04/07, Markus Schuster <[EMAIL PROTECTED]> wrote:
Am Donnerstag, 19. April 2007 15:06:54 schrieb Alasdair Campbell:
> config_xineliboutput
>
> # field parity
> # { none top bottom }, default: 0
> #video.device.directfb_field_parity:none
That's funny, my config_xineliboutput doesn't have this config option per
default...
But I can insert it and when set to 'top' video quality is quite awesome, but
there are still some small hickups and stutters here and there (even with
vsync set to 1). Maybe some other settings are still missing, that softdevice
sets...
I've noticed problems with a couple of music video channels where
there's an effect similar to a stuck CD, surely related to field sync
but probably down to poorly transmitted content. I'm not experiencing
any problems with my favourite channels.
With Bloomberg (German news/stock channel) I see a very odd behavior: To have
to video itself fullscreen, I have to enable local frontend scaling but then
the OSD is renderd much too big. So I have to enable OSD resizing/downscaling
which results in a very unnice OSD (fonts look a bit ugly and the complete
OSD is not the nicest view.).
And channels broadcasting a 16:9 signal are always scaled up to my 4:3 CRT TV,
so I have the typical 'long faces' (I think that's only a configuration
setting, but I haven't been able to locate it...)
My experiences with a 16:9 TV are different but theres some issues
with scaling & OSD that I would like to fix..
I don't want 4:3 content to stretch to my widescreen tv, so I set
Video > Crop letterbox 4:3 to 16:9 - NO
OSD > Everything here is set to NO or OFF
This isn't a bad setup, with 4:3 content, the OSD area shrinks
horizontally to 4:3 ratio, but the text stays nice and clear - I
noticed that any scaling of the OSD results in quite poor text.
However :-), I would prefer it if the OSD stayed at 16:9 resolution
all the time, with just the video layer beneath changing per content
aspect ratio. I'm not sure how I could cause this, or even it it's
possible with the framebuffer.
I'm currently not in a productive environment (that runs with a FF and VDR
1.26 :)) with software decoding, but from what I can say so long, using
DirectFB and the Matrox G450s TV-Out, softdevice is my personal favorite! I
think xineliboutput doesn't earn it's high version number in this 'special'
configuration.
BUT I have to admit that xineliboutput uses only half of the CPU power of
softdevice, so it's video decoder has to be more efficient...
Because I'm using a 550Mhz P3, my only option is to use the
xineliboutput until I figure out what is causing the big CPU load
variations. As I've never had softdevice successfully running on this
television, I can't really say anything about it's quality, though I
know there's been lots of work in respect to the matrox cards.
all the best,
--
A l a s d a i r C a m p b e l l
r a g a w u @ g m a i l . c o m
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Xineliboutput: can achieve similar to softdevice's mgatv option?
On 21/04/07, Tony Houghton <[EMAIL PROTECTED]> wrote: In <[EMAIL PROTECTED]>, Alasdair Campbell wrote: > Because I'm using a 550Mhz P3, my only option is to use the > xineliboutput until I figure out what is causing the big CPU load > variations. As I've never had softdevice successfully running on this > television, I can't really say anything about it's quality, though I > know there's been lots of work in respect to the matrox cards. Another alternative is to use the other vdr xine plugin with df_xine, which gives very good results with my Matrox (G450). About the only problem is that it sometimes doesn't scale the OSD correctly, chopping off the right hand side. Something to do with 16:9 vs 4:3 I'm sure. And I'm seeing something similar to that with More4 & other less popular channels on UK DVB-T. The lower resolution or incorrect imprinted aspect ratio causes the OSD to zoom to the left two thirds, with the right third off screen. As this only happens on one or two channels that I watch, It's not bothering me too much. xineliboutput is exactly what I need at the moment, with my headless recording server and one streaming client - I wanted to control the server osd directly for now. I don't know whether it can handle letterboxing an interlaced 16:9 picture for a 4:3 TV. I heard that softdevice gets, or used to get that wrong, as if it treated the two fields as one frame and scaled them together, rather than scaling each field separately. Maybe the hardware doesn't support the latter, in which case it would have to use slow software scaling. When I was using softdevice I had a 4:3 TV, but wanted to view 16:9 content in full (so with black horizontal bars above and below video). With this setup, interlaced video would show artifacts. I believe that's been fixed by the kind softdevice guys. My experience with softdevice was that the A/V sync was a bit off for live TV and way off for recordings. df_xine is spot on. If you want to be able to stop/start df_xine and/or watch other videos all with one remote control you can use boxstar as a front-end. I had issues with audio sync with softdevice too, can't really say how it deals now, as I'm underpowered. So boxstar will give me direct control over VDR similar to xineliboutput? I hadn't realised that. At the moment I'm not looking to change my setup, just tweak what I have :-) (Sorry if the formatting on this email is all wrong, I'm writing this with lynx on the console, as my laptop is without X at the moment...) ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Xineliboutput: can achieve similar to softdevice's mgatv option?
On 21/04/07, Petri Hintukainen <[EMAIL PROTECTED]> wrote: On Fri, 2007-04-20 at 19:21 +0100, Alasdair Campbell wrote: > > I'll have a look at the softdevice src this weekend & compare with > xineliboutput. Better to compare with xine-lib (src/video_out/video_out_directfb.c), as there's not even single line of directfb code in xineliboutput :) Xine-lib DirectFB "unscalded OSD" (hardware alpha blending) is currently disabled for some matrox cards because of problems with tv-out. See notes on revisions 1.40 and 1.42 at http://xine.cvs.sourceforge.net/xine/xine-lib/src/video_out/video_out_directfb.c?view=log (so, unscaled OSD might work with xine-lib 1.1.2 (?) and recent DirectFB (?)). - Petri ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr -- A l a s d a i r C a m p b e l l r a g a w u @ g m a i l . c o m ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Xineliboutput: can achieve similar to softdevice's mgatv option?
On 21/04/07, Petri Hintukainen <[EMAIL PROTECTED]> wrote: On Fri, 2007-04-20 at 19:21 +0100, Alasdair Campbell wrote: > > I'll have a look at the softdevice src this weekend & compare with > xineliboutput. Better to compare with xine-lib (src/video_out/video_out_directfb.c), as there's not even single line of directfb code in xineliboutput :) Xine-lib DirectFB "unscalded OSD" (hardware alpha blending) is currently disabled for some matrox cards because of problems with tv-out. See notes on revisions 1.40 and 1.42 at http://xine.cvs.sourceforge.net/xine/xine-lib/src/video_out/video_out_directfb.c?view=log (so, unscaled OSD might work with xine-lib 1.1.2 (?) and recent DirectFB (?)). I tried to give xine-lib1.1.2-r3 a go today but after rebuilding xineliboutput against xine-libs., I still receive the message "[12674] [input_vdr] WARNING: Video output driver reports it does not support unscaled overlays !" - so maybe I need an older version of xine-lib?? Unfortunatly that version is as far back as I can go with gentoo, perhaps somebody with better skills could test an older version still. Theres a chance I made a mess of trying out the older xine-lib as now I have no video just sound :-) good thing my girlfriend is out for the day...! -- A l a s d a i r C a m p b e l l r a g a w u @ g m a i l . c o m ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Xineliboutput: can achieve similar to softdevice's mgatv option?
On 21/04/07, Markus Schuster <[EMAIL PROTECTED]> wrote: Well, this changes are more than 7 month old, maybe there have been some changes to DirectFB to make it work in the meanwhile... As far as I saw it's only a two line patch, so I could try to manually revert it and compile xine-lib again... Worth a go? :) I'd volunteer but I don't trust myself.. -- A l a s d a i r C a m p b e l l r a g a w u @ g m a i l . c o m ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Xineliboutput: can achieve similar to softdevice's mgatv option?
On 22/04/07, Alasdair Campbell <[EMAIL PROTECTED]> wrote: I tried to give xine-lib1.1.2-r3 a go today but after rebuilding xineliboutput against xine-libs., I still receive the message "[12674] [input_vdr] WARNING: Video output driver reports it does not support unscaled overlays !" - so maybe I need an older version of xine-lib?? Unfortunatly that version is as far back as I can go with gentoo, perhaps somebody with better skills could test an older version still. Theres a chance I made a mess of trying out the older xine-lib as now I have no video just sound :-) good thing my girlfriend is out for the day...! I've realised that trying xine-lib1.1.2 and changing the xine-lib source during gentoo emerge both clobbered my framebuffer, to the extent where I couldn't run any dfb apps whatsoever. This must be the "problems with tv out" that was mentioned on the xine cvs page. I had to reboot to fix this. -- A l a s d a i r C a m p b e l l r a g a w u @ g m a i l . c o m ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] cFemonOsd::Show() cannot open frontend device
When trialing vdr-femon-1.1.0 with vdr-xineliboutput-1.0.0_rc1 I receive the following error when trying to view the signal information of my recording server via my streaming only client. ERROR: cFemonOsd::Show() cannot open frontend device. Is this a known problem or is there something more I need to configure for my specific setup? [I need Femon to investigate dvb-t signal issues:- with vdr running the signal to my old freeview settop box is degraded to an unusable level. Signal from common aerial is being split with a "1 in 2 out" signal amplifier. There's a 25m cable to the vdr server and a 12m cable to the set top box.] Any advice gladly received! -- A l a s d a i r C a m p b e l l r a g a w u @ g m a i l . c o m ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] cFemonOsd::Show() cannot open frontend device
On 20/05/07, Rolf Ahrenberg <[EMAIL PROTECTED]> wrote: On Sun, 20 May 2007, Alasdair Campbell wrote: > Is this a known problem or is there something more I need to configure > for my specific setup? Yes, it's a known problem reported only in xineliboutput setups: somehow "cDevice::ActualDevice()->CardIndex()" returns invalid values. I cannot reproduce this error in my FF card setup, so I'm just blaming xineliboutput for messing up VDR's devices and haven't had any efforts to debug it further. :) Thanks for letting me know. The results from femon on the console weren't too enlightening so I'll try the linux-dvb mailing list. -- A l a s d a i r C a m p b e l l r a g a w u @ g m a i l . c o m ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Xineliboutput: can achieve similar to softdevice's mgatv option?
On 21/04/07, Petri Hintukainen <[EMAIL PROTECTED]> wrote: [snip] There are two methods for OSD blending: 1) "scaled OSD": OSD is blended to each video frame in software. Because of this OSD size and resolution can't exeed video size/resolution, and OSD can't be drawn outside of video frame (=those black bars resulting from hardware scaling when fitting 4:3 video to 16:9 display or opposite). If video is lower resolution than OSD, OSD must be cropped or downscaled. (Well, another possibility would be upscaling video in software). 2) "unscaled OSD": OSD and video are mixed by hardware using either colorkeying (no opacity) or hardware RGBA layer. OSD and video can be of different size and OSD can be blended outside of video frame. OSD size is constant (fbdev primary layer size, most likely 720x576). Xine-lib directfb driver supports method 2) for only some hardware with ARGB blending capacity. For the rest method 1) is used. I have experimental patch to support colorkeying mode when hardware does not support separate ARGB OSD layer, I just need to adjust it for recent xine-libs. I was wondering if you'd had a look at the patch you mentioned. I'd happily lose osd opacity in favour of a consistant look to my vdr experience - maybe others would too. I actually struggle to read some of the text with low resolution channels. all the best -- Alasdair Campbell [EMAIL PROTECTED] ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Xineliboutput: can achieve similar to softdevice's mgatv option?
On 25/05/07, Petri Hintukainen <[EMAIL PROTECTED]> wrote: Yes, patch against xine-lib 1.1.6 is available from http://phivdr.dyndns.org/xine-lib/directfb/ Thanks so much for that! I'll be able to try it over the weekend and I'll let you know how I get on. many thanks -- A l a s d a i r C a m p b e l l r a g a w u @ g m a i l . c o m ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] Sky Freesat and VDR
As I've just been told that the scaffolding currently surrounding the communal aerial in my neighbourhood will be up for months, I'm looking at purchasing a DVB-S card. The terrestrial analogue reception is just terrible, so much that my dvb-t cards keep choking and dying. As I'm in the UK, and have a shared satellite dish I've been interested in using the Sky Freesat service. I've read on avforums that people have managed to get their freesat and even paytv cards working with TT T3200S cards + CI card + CAM. Unfortunately they're all using Windows MCE and the information is heavily windows specific. As I've no interest in HDTV (or windows), I was hoping to go for a cheaper card. Does anyone using VDR in the UK currently have this setup working? Would you care to mention the hardware you have? I'd only be looking for the full freesat channel line-up, specifically all the freeview channels I currently can't see! :-) I won't be subscribing to Sky Tv. One major issue is I don't have an extra coax cable heading to my vdr server. I was planning on installing the dvb-s card in my client and using another vdr server working in conjunction with the 'master'. Installing another cable will mean digging up 25m of earth and shifting some paving slabs :-/ Principally I'd like the whole setup to seem transparent in that I can record from the 2 dvb-t cards or the dvb-s card using the same epg, and shared recordings folders etc. Is this feasible? This is secondary to just getting a proper digital tv service working in our living room. -- A l a s d a i r C a m p b e l l r a g a w u @ g m a i l . c o m ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Configuring vdr-sxfe to use a single vdr backend for recordings/dvb cards
On 09/06/07, Petri Hintukainen <[EMAIL PROTECTED]> wrote: > On Sat, 2007-06-09 at 18:15 +0100, Andrew Herron wrote: > > I have several networked vdr machines that i want to use to connect > > back to the 'server' vdr machine. The networked vdr machines will have > > no dvb cards (they will all be located at the vdr server). How do i > > configure my vdr client machines to connect back to the server vdr > > machine and use its dvb cards/recording storage etc? > > > > Can anyone give some guidance on this type of setup or point me at a > > url where I can find out about such a config? > > If you don't watch different recordings / channels at the same time you > can just run vdr-sxfe at each client and connect to the single VDR > server. You'll get same video + OSD mirrored to all locations. > > But, if you need to have independently controlled clients with own video > and OSD, you need to run several instances of VDR - it doesn't matter if > you run all VDR instances on server or at each client. I run several VDR > instances on the server: > - less maintenance, only one installation of VDR and >plugins required > - allows using diskless clients (and with less memory) > - Faster cutting / DVD burning / ... as there is no >network between VDR and disks > - no need to export/mount /video to every client > - ... > > Here's how I do it: > > master VDR: DVB cards, recordings, server for client 1: > vdr -c /etc/vdr \ > -P"xineliboutput --local=none --remote=37890" \ > -Pstreamdev-server > server for client 2: > vdr -c /etc/vdr2 \ > -D 10 \ > -P"xineliboutput --local=none --remote=37892" \ > -Pstreamdev-client > server for client 3: > vdr -c /etc/vdr3 \ > -D 10 \ > -P"xineliboutput --local=none --remote=37894" \ > -Pstreamdev-client > > + other options / plugins you normally use. > > Using -D 10 option for client VDR instances "forces" all DVB cards for > master VDR. Streamdev plugin is used to provide live view for client > VDR's, it is not required to just watch recordings. > You must use separate configuration directory for each VDR (-c option). > Without it you'll most likely break all recordings (all VDRs record all > timers in paraller to same recording directory). > > And at clients: > Client 1: > vdr-sxfe > Client 2: > vdr-sxfe xvdr://:37892 > Client 3: > vdr-sxfe xvdr://:37894 > > If you use RTP between vdr and vdr-sxfe, using separate RTP address or > port for each xineliboutput server instance might be good idea. > > Also it might be good idea to disable recording at all but the "master" > vdr. Recording the same timer on two VDR instances will most likely > corrupt whole recording. Besides that, doing all recordings directly > from DVB card (no streamdev in middle) makes things simpler and less > error prone. It is probably even impossible to do several recordings > from different transponders using single streamdev instance. > I use timersync plugin to disables recording on client VDRs. All timers > are still visible at each client and you can create/modify timers at any > client just as before. Plugin synchronizes all modifications to timers > between VDR instances and takes care that all recordings are made only > by "master" vdr. Still, if you have some kind of autotimer plugins etc. > that generate timers automatically it might be better to run those only > at server vdr... This system is just what I'm looking to create, however I have one or two questions. (As usual..) Is it possible to have one of the VDR 'servers/instances' to be running on one of the clients rather than the main server pc? The exact same setup except Client2 has an instance of VDR running in the background with 1 dvb card saving files to the server's /video mounted over nfs. Ideally all Clients + Master VDR Server will see channels on Client 2's satellite feed and be able to register timers on that server. If there was a way for PCI buses to traverse networks, then the location of the 3rd card wouldn't be an issue, but I don't believe that's possible... There is currently no way for me to have all 3 DVB cards in the same box. -- A l a s d a i r C a m p b e l l r a g a w u @ g m a i l . c o m ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR with two DVBS cards
On 13/06/07, Andrey Vlassov <[EMAIL PROTECTED]> wrote: > Hi, > > could somebody point me in right direction? lots of useful info here: http://www.linuxtv.org/vdrwiki/index.php/Main_Page > I am looking into configuring a second DVBS card to use with vdr. > > Configuration: > > Athlon 1.2GHz > MB: ABIT > Memory: 512MB > OS: Mandriva 2006 > vdr: 1.4.5 > DVBS1: Nexus-S > DVBS2: Twinhan 1025a > > At this time I use Nexus-S and it works fine. > > What modification/patches will require to make both cards work with vdr? > Is there any documentation for this case? As far as I know, once you've confirmed both cards are being recognized and working independently of VDR - your first step - then VDR will require no changes other than 'number of DVB cards ' in the Setup menu. -- A l a s d a i r C a m p b e l l r a g a w u @ g m a i l . c o m ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR with two DVBS cards
On 13/06/07, Klaus Schmidinger <[EMAIL PROTECTED]> wrote: > There is no such option in VDR's Setup menu. Sorry, I was thinking of "Primary DVB interface" - something totally different.. -- A l a s d a i r C a m p b e l l r a g a w u @ g m a i l . c o m ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Configuring vdr-sxfe to use a single vdr backend for recordings/dvb cards
On 16/06/07, Petri Hintukainen <[EMAIL PROTECTED]> wrote: > On Wed, 2007-06-13 at 19:16 +0100, Alasdair Campbell wrote: > > Is it possible to have one of the VDR 'servers/instances' to be > > running on one of the clients rather than the main server pc? > > Yes. Then you don't need the -D option. > > > The exact same setup except Client2 has an instance of VDR running in the > > background with 1 dvb card saving files to the server's /video mounted > > over nfs. > > Ideally all Clients + Master VDR Server will see channels on Client > > 2's satellite feed and be able to register timers on that server. > > This is more complicated :) > > I think you need to set every timer manually to the system where it is > supposed to be recorded. Timersync won't work as it disables all > recording at client(s). Using timersync and enabling recording at the > client won't work if you use streamdev: both systems will see the same > channels and would record the same timers in paraller. > > Maybe something like this might work: > VDR1: (2x DVB-?): > streamdev-server, streamdev-client connected to VDR2 > VDR2: (1x DVB-S): > streamdev-server, streamdev-client connected to VDR1 > VDR3: (no DVB): > 2 instances of streamdev-client: one connected to VDR1 and another to > VDR2. > > Note that circular streamdev setup doesn't work without patching > ( http://www.vdr-developer.org/mantisbt/view.php?id=198 ) > > > If there was a way for PCI buses to traverse networks, then the > > location of the 3rd card wouldn't be an issue, but I don't believe > > that's possible... > > No, but transferring the device interface (/dev/dvb/...) over network is > possible with something like nbd (network block device). I think I saw > similar redirector for DVB devices few years ago: > http://linuxtv.org/mailinglists/linux-dvb/2004/08-2004/msg00326.html > But it seems quite old and unmaintained. I remember reading about this years ago, if it could work then it would be ideal for my situation - maybe for others too. Vadim Epmak's address is bouncing so I'll ask on the DVB mailing list and see if anyone else ever got it up and running. I'm keen on trying it out myself, and have started reading about porting drivers to 2.6 kernels. Could be an interesting way to learn more C ;-) -- A l a s d a i r C a m p b e l l r a g a w u @ g m a i l . c o m ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Configuring vdr-sxfe to use a single vdr backend for recordings/dvb cards
On 18/06/07, Alasdair Campbell <[EMAIL PROTECTED]> wrote: > On 16/06/07, Petri Hintukainen <[EMAIL PROTECTED]> wrote: > > On Wed, 2007-06-13 at 19:16 +0100, Alasdair Campbell wrote: > > > Is it possible to have one of the VDR 'servers/instances' to be > > > running on one of the clients rather than the main server pc? > > > > Yes. Then you don't need the -D option. > > > > > The exact same setup except Client2 has an instance of VDR running in the > > > background with 1 dvb card saving files to the server's /video mounted > > > over nfs. > > > Ideally all Clients + Master VDR Server will see channels on Client > > > 2's satellite feed and be able to register timers on that server. > > > > This is more complicated :) > > > > I think you need to set every timer manually to the system where it is > > supposed to be recorded. Timersync won't work as it disables all > > recording at client(s). Using timersync and enabling recording at the > > client won't work if you use streamdev: both systems will see the same > > channels and would record the same timers in paraller. > > > > Maybe something like this might work: > > VDR1: (2x DVB-?): > > streamdev-server, streamdev-client connected to VDR2 > > VDR2: (1x DVB-S): > > streamdev-server, streamdev-client connected to VDR1 > > VDR3: (no DVB): > > 2 instances of streamdev-client: one connected to VDR1 and another to > > VDR2. > > > > Note that circular streamdev setup doesn't work without patching > > ( http://www.vdr-developer.org/mantisbt/view.php?id=198 ) > > > > > If there was a way for PCI buses to traverse networks, then the > > > location of the 3rd card wouldn't be an issue, but I don't believe > > > that's possible... > > > > No, but transferring the device interface (/dev/dvb/...) over network is > > possible with something like nbd (network block device). I think I saw > > similar redirector for DVB devices few years ago: > > http://linuxtv.org/mailinglists/linux-dvb/2004/08-2004/msg00326.html > > But it seems quite old and unmaintained. > > I remember reading about this years ago, if it could work then it > would be ideal for my situation - maybe for others too. Vadim Epmak's > address is bouncing so I'll ask on the DVB mailing list and see if > anyone else ever got it up and running. > > I'm keen on trying it out myself, and have started reading about > porting drivers to 2.6 kernels. Could be an interesting way to learn > more C ;-) In hindsight, I believe learning C on my own by porting a driver to the 2.6 kernel was a tad optimistic.. Sill won't compile, and I haven't got to grips with the changes in the dvb api from when this was written. No response yet on the linuxtv list. I'll keep working at the code - it could be a fun way to learn, and the principle seems quite straight-forward. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] femon and xineliboutput
On 02/07/07, Simon Natterer <[EMAIL PROTECTED]> wrote: > Hi, > > when I try to start femon with xineliboutput nothing apears. It seems to > to start but nothing is shown on screen (using vdr-sxfe or xine > directly). Starting femon on console works when vdr is not running. All > other plugins seem to work. Experimenting with OSD settings in > xineliboutput options didn't solve the problem. > > femon 1.1.3 > xineliboutput 1.0.0-rc2 > vdr 1.4.7 > > Any ideas? Hi Simon, Try this post from 20th May : "[vdr] cFemonOsd::Show() cannot open frontend device" You could check your logs for the above line to confirm we've got the same issue. all the best, ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] File play problem..
On 21/08/07, JJussi <[EMAIL PROTECTED]> wrote: > And how you do that with Gentoo... If I change something, gentoo compile > process will notice that.. Suspend the emerge just after the source has been unpacked and any patches applied. Might take you a couple of times to get it just before it starts compiling, but at least this is a way to try out changes before you confirm it all works and write your own ebuild. The file to edit should be here: /var/tmp/portage/media-plugins/vdr-xineliboutput-1.*.*/wor k/xineliboutput-1.*.*/Makefile ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] next features?
On Nov 19, 2007 1:31 AM, Magnus Hörlin <[EMAIL PROTECTED]> wrote: > Klaus Schmidinger wrote: > > Maybe it actually is about time for me to build a new VDR. > > I'll probably take a look at the Reel Extension HD PCI. > > But that means I'll also need a new motherboard with at least > > five PCI slots (for 3 DVB-S cards, 1 DVB-T and the Extension HD). > > On my desktop PC I'm using a passively cooled Pentium M with 1.86GHz, > > which works really good, so maybe that's also a viable choice for > > a new VDR. I guess it goes without saying that modern motherboards > > have a gigabit Ethernet port and graphics on board. > > Does anybody have a recommendation for such a board? Can't you just buy a 2nd hand Pentium 4 board and another P4 mobile? Save the environment and your wallet! No gigabit ethernet, but stick a Matrox in the AGP slot and get component PAL output.. matrox G450 costs 10 euros... ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] next features?
On Nov 19, 2007 2:08 AM, Halim Sahin <[EMAIL PROTECTED]> wrote: > Hmm HDTV with a matrox card What I mean is H264 video gets decoded by the extra horsepower of the P4, matrox is used with software output device in vdr. Are you planning on buying an HD television set Klaus? Then ignore what I had to say and throw out one your dvb-s cards. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] next features?
On Nov 18, 2007 9:54 PM, Klaus Schmidinger <[EMAIL PROTECTED]> wrote: > On 11/18/07 19:16, Alasdair Campbell wrote: > > On Nov 19, 2007 2:08 AM, Halim Sahin <[EMAIL PROTECTED]> wrote: > >> Hmm HDTV with a matrox card > > > > What I mean is H264 video gets decoded by the extra horsepower of the > > P4, matrox is used with software output device in vdr. > > > > Are you planning on buying an HD television set Klaus? Then ignore > > I already have one ;-) > > > what I had to say and throw out one your dvb-s cards. > > I don't want to lose the ability to record 3 DVB-S transponders > in parallel, and I also need the DVB-T card. It seems like you have two totally different options, depending on whether you go for hardware or software decoding of HD content. If the Reel HD card turns out to be a winner, then I'd suggest you buy a board with the Intel 865PE chipset, lots of second hand options out there. If you go for one with gigabit ethernet, you'll likely be buying a top line board, well looked after and with sata ports, DDR400 support, good bios options for undervolting/clocking. 5 PCI slots and an AGP slot to stick in a suitable card for installing an OS. Doubt many will come with on board video. Of course if you go for software decoding you're in a different boat: new RAM required; USB tuners or PCIe->PCI adaptor; new PSU?; most good boards wouldn't have onboard video, so a need to buy a cheap PCIe graphics card to install in gui mode. I know what I'd go for...it's just a shame that hardware HD decoding hasn't grown enough for there to be some competition and innovation. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] HDTV - 2B or not 2B
Lauri Tischler wrote: > Füley István wrote: >>> Oops, that's really not so good... one can't comment about HDTV with a >>> resolution which is not full HDTV : 1920x1080... >> Ok, this means that my setup is a low-end instead of being "average" as I >> stated before, therefore my considerations about HDTV was totally wrong. >> >> But to buy a 1000+ Euro TV set? That's another reason for me to stay SD. > > Not really, FullHD also means large, minimum 42", it is quite senseless > to to watch good picture on a postcard, so you start at €1500 You forgot to add the €20,000 building an extension to your house, if you don't want your living room to be dominated by a 42" diagonal piece of plastic. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] HDTV - 2B or not 2B
Lauri Tischler wrote: > Alasdair Campbell wrote: >> Lauri Tischler wrote: >>> Not really, FullHD also means large, minimum 42", it is quite senseless >>> to to watch good picture on a postcard, so you start at €1500 >> You forgot to add the €20,000 building an extension to your house, if >> you don't want your living room to be dominated by a 42" diagonal piece >> of plastic. > > Thats peanuts, considering you spend the same amount for cables alone > http://www.pearcable.com/sub_products_anjou_sc.htm 'Made in the U.S.A. for superior quality' - Don't matter where you make it, it better be good quality at $500 a foot. "Highly recommended" - Dave Clark "In extended listening sessions, I found the cables' greatest strength to be its PRAT. Simply put these are very danceable cables. Music playing through them results in the proverbial foot-tapping scene with the need or desire to get up and move." - Dave Clark What the fudd is he talking about? PRAT? Danceable? Ain't that the musician's responsibility? I wonder what sort of cable the engineer was using when he mixed the album. Someone explain to me how these cables are more 'honest' than the rest. "Okay so the Anjous are rather pricey at $2750 for a meter pair, but they are impeccably built, sound quite nice, and should keep you happy for a quite a while." Sound quite nice AND well built? Where's my credit card..? Will I ever be happy with my speaker cables? Do I want to be happy?!? ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] HDTV - 2B or not 2B
VDR User wrote: > On Nov 22, 2007 7:30 AM, Füley István <[EMAIL PROTECTED]> wrote: >> To be clear: I did not say, that we don't need HD at all. I just said, >> that normal TV stations should stay in SD, and only a couple of premium >> (PPV, etc) channels should go HD. But the situation is more clear: not me >> is gonna be who decide the future of television but the market :) > > If HD is no better or not real increase in quality then why switch > from SD at all? If it's not any better then how have these providers, > hardware makers, etc. all tricked s many people into believing HD > -IS- better quality? Maybe it's simply because it is and all the user > needs as proof is his own two eyes. Like it or not HDTV is here to > stay, and it's taking over. H264 is here to stay. Change is nothing > to be scared of, especially when it's for the better. The only thing > scary about it is being left behind and wishing you would have done > something about it sooner. > > Btw, do you still prefer music on cassette tape? ;) (just kidding) I certainly prefer listening to music on dmm 180g vinyl to a poorly mastered compact disc, and I've never seen a cheap CRT look anywhere near as bad as some LCDs I've seen over the years.. Shops in Britain kept the CRT and LCD displays apart, so shoppers with a limited short term memory failed to notice the washed-out colour and lack of black in the BULK of lcd TVs sold in the last 5 years. Now there's fortunatly no CRTs to compare with. (I understand the contrast on the latest FullHD tvs can be superb). I do believe HD for films, concerts & wildlife docs must be amazing to watch, but as it is terrestrial HD in the UK is still two years away, and will require DVB-T2 receivers. At the point when my cards stop receiving a signal I might start worrying about being 'left behind'. UK Terrestrial HD plans: http://www.ukfree.tv/fullstory.php?storyid=1107051325 SD bitrates to be reduced, 3 HD channels for 9 hours a day, more people without a proper signal. Progress! and a few billion pounds in OFCOM's coffers. (To be paid off by people replacing their IDTVs and set top boxes on redundancy..) ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] HDTV - 2B or not 2B
Beside all that, I do believe VDR needs to integrate H264 & HD recording, along with support built-in for multiple frontends. Hopefully I can lend a hand with the coding (in about 6 years). ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] HDTV - 2B or not 2B
VDR User wrote: > Just curious... Why did you buy a dvb card? Antennas work just fine > and are less expensive. Everyone else was buying them ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] UK users - multiple BBC One/Two/News in channels list
Hi, Been a while since I've used VDR. Have it setup after scanning using the scan program, however something is strange. There are multiple versions of some channels, such as BBC One/Two/News, Channel 4 etc. Some of these either have video and no EPG, have video and EPG, or have EPG and no video... Obviously what I'm looking for is the video & the EPG - this works for BBC One, but when I tune to the BBC Two which has the EPG visible, I receive no signal found message. If any UK users have a cluestick on how to fix this, please let me know. It seems like VDR is updating the channels.conf but not merging the information, because a fresh scan using dvbutils does not show multiple versions for the same channel. Any help appreciated.. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] UK users - multiple BBC One/Two/News in channels list
On 3 November 2010 20:48, Luca Olivetti wrote: > Al 03/11/10 21:31, En/na Alasdair Campbell ha escrit: >> There are multiple versions of some channels, such as BBC >> One/Two/News, Channel 4 etc. Some of these either have video and no >> EPG, have video and EPG, or have EPG and no video... Obviously what >> I'm looking for is the video& the EPG - this works for BBC One, but >> when I tune to the BBC Two which has the EPG visible, I receive no >> signal found message. > > Terrestrial or satellite? Sorry forgot to say - it's Terrestrial. > I'm not really sure, but the issue should be the same in both cases: the > service id should be sufficient to identify a channel, regardless of the > transponder, but since some broadcasters reuse the same id in more than one > transponder, vdr uses both the transponder and the service id to > differentiate channels. > The result is that when a channel changes transponder (like the uk channels > recently did), vdr would probably find a new channel instead of replacing > the tuning data of the existing one. Ah so, the initial tuning file I'm using from dvbutils is out of date, and VDR finds the new transponders instantly? > Well, I think there should be a better way, but the only current option is > to let vdr update all channels and manually delete the old, non working > ones. I've left VDR set at "Add New Transponders" which presumably is the most promiscuous mode, and will see what it comes up with over the next hour or so. Thanks for the reply! > > > Bye > -- > Luca > > ___ > 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] UK users - multiple BBC One/Two/News in channels list
On 3 November 2010 23:18, Torgeir Veimo wrote: > From memory, I think the frequencies in channels.conf ends up being > 166khz off the actual frequency. I remember having to tweak the > channels.conf file manually, then turn off automatic updates. Can you > post your file here? After leaving it for a few hours this is what I have, note BBC ONE at the very bottom, the EPG is available here but no video stream, same with BBC TWO elsewhere. channels.conf attached (hope attachments are allowed on this list!) channels.conf Description: Binary data ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
