On 14.01.2011 18:33, VDR User wrote:
> On Thu, Jan 13, 2011 at 1:40 PM, Klaus Schmidinger
> wrote:
>>> AIUI VDR generates the OSD as a bitmap no matter which output plugin is
>>> used and the player only has the choice of how to overlay it on the
>>> video. So getting it rendered by VDPAU would be
On Thu, Jan 13, 2011 at 1:40 PM, Klaus Schmidinger
wrote:
>> AIUI VDR generates the OSD as a bitmap no matter which output plugin is
>> used and the player only has the choice of how to overlay it on the
>> video. So getting it rendered by VDPAU would be easy enough, but to
>> upgrade it to HD wou
Am 14.01.2011 16:30, schrieb Laz:
Sounds good. Where can I get the script? Is it in one of your packages? I
assume I'd also need to install the source for vdr to build against, or
does that get pulled in as a build dependency?
Just install vdr-dev. This includes the script and all header files
On Friday 14 Jan 2011, Tobi wrote:
> Am 14.01.2011 11:19, schrieb Laz:
> > change to TS). You have the softdevice built against vdr-1.7.16 in
> > your repository. Does this work properly or has it just that it
> > compiles and hasn't been widely tested?
>
> I guess nobody tested it yet, including
Am 14.01.2011 11:19, schrieb Laz:
change to TS). You have the softdevice built against vdr-1.7.16 in your
repository. Does this work properly or has it just that it compiles and
hasn't been widely tested?
I guess nobody tested it yet, including me. It doesn't contain any
special patches for 1
On 14.01.2011 09:19, L. Hanisch wrote:
>>> The next developer version of VDR will contain full True-Color OSD
>>> support.
> ^
>
>> Will this be a 1.8 release, or still in the 1.7 development train?
>
> I guess it would still be a 1.7.x.
It will be 1.7.17 - gotta tes
2011/1/14 Laz :
> On Monday 10 Jan 2011, Tobias Grimm wrote:
>> deb http://e-tobi.net/vdr-experimental squeeze vdr-multipatch addons
>> base backports
>> deb-src http://e-tobi.net/vdr-experimental squeeze vdr-multipatch
>> addons base backports
>
> Intriguing...
> I also have another plugin which
On Monday 10 Jan 2011, Tobias Grimm wrote:
> Am Montag, den 10.01.2011, 18:51 + schrieb Tony Houghton:
> > I'd also be interested in the developer version of xine with VDPAU
> > support. The trouble is there's a bewildering set of mercurial
> > branches. There are some libxine2 packages in Debi
The next developer version of VDR will contain full True-Color OSD support.
^
Will this be a 1.8 release, or still in the 1.7 development train?
I guess it would still be a 1.7.x.
Lars.
___
vdr mailing list
vdr@linuxtv
AIUI VDR generates the OSD as a bitmap no matter which output plugin is
used and the player only has the choice of how to overlay it on the
video. So getting it rendered by VDPAU would be easy enough, but to
upgrade it to HD would probably need some rewriting/patching in core
VDR, not just a plugi
On 13.01.2011 21:42, Tony Houghton wrote:
> ...
> AIUI VDR generates the OSD as a bitmap no matter which output plugin is
> used and the player only has the choice of how to overlay it on the
> video. So getting it rendered by VDPAU would be easy enough, but to
> upgrade it to HD would probably nee
On 13/01/11 18:57, VDR User wrote:
I agree, the less layer upon layer upon layer, the better. I also
want to point out that there are a large number of users who have
dedicated VDR boxes connected directly to tv's in an htpc environment,
using only a remote control to navigate the menus and ssh
I agree, the less layer upon layer upon layer, the better. I also
want to point out that there are a large number of users who have
dedicated VDR boxes connected directly to tv's in an htpc environment,
using only a remote control to navigate the menus and ssh for box
maintenance. Not computer mo
On 13/01/11 16:50, Timothy D. Lenz wrote:
And you are back to layer on layer on layer. If someone is going to
write something, let it be the plugin that talks to vdr and ffmpeg.
Forget xineliboutput, libxine, etc. The more middle ware we can dump the
better.
So maybe your needs would be best se
On 13/01/11 00:11, VDR User wrote:
So instead of maintaining just a plugin (which depends on ffmpeg
decoding rather then xinelibs decoding), you think maintaining a new
player altogether in addition to a plugin that streams data into it?
Not to mention forcing VDR into being a backend only. I kn
> oh, so now we need opengl and a compositing manager on top of
> everything else? You miss the point.
If you would quote mails right you would have noticed that I answered
a sentence that told that it doesn't work at all. How did I
miss this point?
> > have been far from successful. It appears t
On 01/13/11 15:46, Gerald Dachs wrote:
>>
>> On 01/13/11 13:31, Rolf Ahrenberg wrote:
>>> On Wed, 12 Jan 2011, VDR User wrote:
>>>
And you get VDR's full osd doing this?
>>> FYI, xineliboutput provides three different OSD implementations:
> xinelib, composite HUD, and opengl HUD. For example
oh, so now we need opengl and a compositing manager on top of everything
else? You miss the point.
I don't have a problem with vdr being usable as client/server. There are
advantages. But it doesn't need to be so complex and it is seperate form
the local renderer.
On 1/13/2011 7:46 AM, Geral
And you are back to layer on layer on layer. If someone is going to
write something, let it be the plugin that talks to vdr and ffmpeg.
Forget xineliboutput, libxine, etc. The more middle ware we can dump the
better.
On 1/12/2011 12:15 PM, Tony Houghton wrote:
On 12/01/11 18:42, VDR User wrot
On 13.01.2011 13:31, Rolf Ahrenberg wrote:
> On Wed, 12 Jan 2011, VDR User wrote:
>
>> And you get VDR's full osd doing this?
>
> FYI, xineliboutput provides three different OSD implementations:
> xinelib, composite HUD, and opengl HUD. For example the composite HUD
> OSD is drawn directly onto t
>
>
> On 01/13/11 13:31, Rolf Ahrenberg wrote:
>> On Wed, 12 Jan 2011, VDR User wrote:
>>
>>> And you get VDR's full osd doing this?
>>
>> FYI, xineliboutput provides three different OSD implementations:
xinelib, composite HUD, and opengl HUD. For example the composite HUD
OSD is drawn directly ont
On 01/13/2011 03:24 PM, Oliver Schinagl wrote:
I'm curious as to how you got the composite and opengl HUD's working, I
have been far from successful. It appears to just not work at all :S
I've tried composite HUD and it works and looks really nice. The bad is
that enabling composite extension
On 01/13/11 13:31, Rolf Ahrenberg wrote:
> On Wed, 12 Jan 2011, VDR User wrote:
>
>> And you get VDR's full osd doing this?
>
> FYI, xineliboutput provides three different OSD implementations:
> xinelib, composite HUD, and opengl HUD. For example the composite HUD
> OSD is drawn directly onto tra
On Wed, 12 Jan 2011, VDR User wrote:
And you get VDR's full osd doing this?
FYI, xineliboutput provides three different OSD implementations:
xinelib, composite HUD, and opengl HUD. For example the composite HUD
OSD is drawn directly onto transparent window located exactly over the
(xine-lib
On Wed, Jan 12, 2011 at 2:33 PM, Tony Houghton wrote:
>> So there's no vdr output plugin option available that uses ffmpeg for
>> vdpau decoding and also provides the user with VDR's osd.
>>
>> Hopefully someone capable of writing an output plugin will take
>> interest after reading all the recent
On 12/01/11 20:31, VDR User wrote:
So there's no vdr output plugin option available that uses ffmpeg for
vdpau decoding and also provides the user with VDR's osd.
Hopefully someone capable of writing an output plugin will take
interest after reading all the recent posts on the subject.
So you
On Wed, Jan 12, 2011 at 11:15 AM, Tony Houghton wrote:
>>> 1. A stream server plugin.
>>> 2. An integrated player plugin based on xine.
>>> 3. Standalone xine-based players for connecting to the server.
>>>
>>> I propose using 1, ignoring 2 (you can disable it with CLI options, I do
>>> this anywa
On 12/01/11 18:42, VDR User wrote:
On Wed, Jan 12, 2011 at 10:31 AM, Tony Houghton wrote:
1. A stream server plugin.
2. An integrated player plugin based on xine.
3. Standalone xine-based players for connecting to the server.
I propose using 1, ignoring 2 (you can disable it with CLI options,
On Wed, Jan 12, 2011 at 10:31 AM, Tony Houghton wrote:
> 1. A stream server plugin.
> 2. An integrated player plugin based on xine.
> 3. Standalone xine-based players for connecting to the server.
>
> I propose using 1, ignoring 2 (you can disable it with CLI options, I do
> this anyway because it
On 12/01/11 18:09, Timothy D. Lenz wrote:
xineliboutput still uses xine. So it sounds like you are saying dump vdr
and keep xine. xine is the problem, not vdr.
You misunderstand. xineliboutput has a number of components:
1. A stream server plugin.
2. An integrated player plugin based on xine.
But you still need xine to use xineliboutput. Even if not using it for
decoding. I tried onec before when someone said it could use ffmpeg and
found it still depended on xine. Just like xine needs a lot of crap
installed to compile it that is never used. KISS
On 1/12/2011 3:04 AM, Pertti Kosun
Didn't nvidia do the early ffmpeg patch as part of the example of how to
support vdpau? That would explain why they work better together.
On 1/11/2011 9:30 PM, VDR User wrote:
That would be great actually. Or just having another option period
besides something dependent on libxine. The guy w
When vdr was using the hardware video out of a nexus card, it worked
great. I had a LOT fewer problems. The video interface plugin should be
just that and nothing more.
It doesn't need support for irc in it
It doesn't need lirc support, that is in vdr
There is an mplayer plugin if you need to
xineliboutput still uses xine. So it sounds like you are saying dump vdr
and keep xine. xine is the problem, not vdr.
On 1/11/2011 1:41 PM, Tony Houghton wrote:
On 11/01/11 20:20, Timothy D. Lenz wrote:
I would prefer a ffmpeg (mplayer) based interface and dump xine because
xine/vdpau combo do
On Wed, Jan 12, 2011 at 12:02 PM, Laz wrote:
> Sounds good. How are you running iPlayer, etc.? Through Firefox or
> equivalent?
No. Boxee (and XBMC) provide BBC iplayer apps formatted for the big
screen that require only a remote control to navigate.
> I've got a couple of Media MVPs hanging off
On Wednesday 12 Jan 2011, Morfsta wrote:
> > Why not exclusively use the yaVDR repositories?
>
> My winter project has been to migrate my old hand compiled VDR-1.7.0
> system using Reel EHD to yaVDR (distro) using a Nvidia GT210 with HDMI
> audio. Its taken a bit of tweaking to get somewhere near
> Why not exclusively use the yaVDR repositories?
My winter project has been to migrate my old hand compiled VDR-1.7.0
system using Reel EHD to yaVDR (distro) using a Nvidia GT210 with HDMI
audio. Its taken a bit of tweaking to get somewhere near (mostly
addressing audio sync issues when I used th
On Wednesday 12 Jan 2011, Torgeir Veimo wrote:
> On 12 January 2011 13:09, VDR User wrote:
> > On Tue, Jan 11, 2011 at 4:40 PM, Torgeir Veimo
wrote:
> >> You can always try softdevice, which is mostly a playback interface
> >> using ffmpeg.
> >
> > Isn't softdevice abandoned?
>
> It hasn't see
On 11.1.2011 22:20, Timothy D. Lenz wrote:
I would prefer a ffmpeg (mplayer) based interface and dump xine because
xine/vdpau combo doesn't properly handle problems with the atsc stream.
You can use ffmpeg decoding with xineliboutput.
~/.xine/config_xineliboutput:
# priority for ffmpegaudio de
On Tue, Jan 11, 2011 at 7:32 PM, Torgeir Veimo wrote:
>>> You can always try softdevice, which is mostly a playback interface
>>> using ffmpeg.
>
>> Isn't softdevice abandoned?
>
> It hasn't seen any new features added for a while, but should still
> work as a software only playback device.
>
>> A
On 12 January 2011 13:09, VDR User wrote:
> On Tue, Jan 11, 2011 at 4:40 PM, Torgeir Veimo wrote:
>>
>> You can always try softdevice, which is mostly a playback interface
>> using ffmpeg.
> Isn't softdevice abandoned?
It hasn't seen any new features added for a while, but should still
work as
On Tue, Jan 11, 2011 at 4:40 PM, Torgeir Veimo wrote:
> I would prefer a ffmpeg (mplayer) based interface and dump xine
> because xine/vdpau combo doesn't properly handle problems with
> the atsc stream.
>
> You can always try softdevice, which is mostly a playback interface
> using ff
On 12 January 2011 10:23, Tony Houghton wrote:
> On 11/01/11 20:52, VDR User wrote:
>>
>> On Tue, Jan 11, 2011 at 12:41 PM, Tony Houghton
>> wrote:
I would prefer a ffmpeg (mplayer) based interface and dump xine
because xine/vdpau combo doesn't properly handle problems with
the
On 11/01/11 20:52, VDR User wrote:
On Tue, Jan 11, 2011 at 12:41 PM, Tony Houghton
wrote:
I would prefer a ffmpeg (mplayer) based interface and dump xine
because xine/vdpau combo doesn't properly handle problems with
the atsc stream.
What about something based on gstreamer? Someone who underst
On 11/01/2011 19:11, Tony Houghton wrote:
I don't get any picture at all on HD channels, with or without VDPAU.
Last time I checked the yavdr packages, I was not getting HD either.
Manually compiling vdr doing removal from the debian patches series of
everything that was not tagged as "re
On Tue, Jan 11, 2011 at 12:41 PM, Tony Houghton wrote:
>> I would prefer a ffmpeg (mplayer) based interface and dump xine because
>> xine/vdpau combo doesn't properly handle problems with the atsc stream.
>
> What about something based on gstreamer? Someone who understands that
> could probably kn
On Tue, Jan 11, 2011 at 12:20 PM, Timothy D. Lenz wrote:
> I would prefer a ffmpeg (mplayer) based interface and dump xine because
> xine/vdpau combo doesn't properly handle problems with the atsc stream.
I've seen several users express the want for an ffmpeg-based video
output plugin so it seems
On 11/01/11 20:20, Timothy D. Lenz wrote:
I would prefer a ffmpeg (mplayer) based interface and dump xine because
xine/vdpau combo doesn't properly handle problems with the atsc stream.
What about something based on gstreamer? Someone who understands that
could probably knock together a basic p
I would prefer a ffmpeg (mplayer) based interface and dump xine because
xine/vdpau combo doesn't properly handle problems with the atsc stream.
The way I understand it according to rnissl in #xine, when there is any
corruption to the stream, vdpau changes the image size, rounding the
number or
On 11/01/11 18:23, Timothy D. Lenz wrote:
xine-lib-1.2-vdpau is just a link to xine-lib-1.2. Use ether one and you
get the same. You want:
hg clone http://hg.debian.org/hg/xine-lib/xine-lib-1.2
and if you are using vdr-xine plugin:
hg clone http://hg.debian.org/hg/xine-lib/xine-ui/
I prefer
On 11/01/11 18:11, Tony Houghton wrote:
I don't get any picture at all on HD channels, with or without VDPAU.
To clarify, I don't get sound either, and this is on both PCs.
--
TH * http://www.realh.co.uk
___
vdr mailing list
vdr@linuxtv.org
http://
xine-lib-1.2-vdpau is just a link to xine-lib-1.2. Use ether one and you
get the same. You want:
hg clone http://hg.debian.org/hg/xine-lib/xine-lib-1.2
and if you are using vdr-xine plugin:
hg clone http://hg.debian.org/hg/xine-lib/xine-ui/
On 1/10/2011 1:52 PM, Tony Houghton wrote:
On 1
On 10/01/11 19:28, Tobias Grimm wrote:
Am Montag, den 10.01.2011, 18:51 + schrieb Tony Houghton:
I'd also be interested in the developer version of xine with VDPAU
support. The trouble is there's a bewildering set of mercurial branches.
There are some libxine2 packages in Debian experimenta
On 11/01/11 15:51, Eric Valette wrote:
On 01/11/2011 03:18 PM, Tony Houghton wrote:
On 11/01/11 12:16, Eric Valette wrote:
https://launchpad.net/~yavdr/+archive/stable-vdr
cause its ubuntu and he uses debian ? ;)
The yavdr packages works fine on debian (or at least as on ubuntu)...
Exce
On 11/01/11 14:37, Gerald Dachs wrote:
And yavdr doesn't include sxfe for some reason.
That is complete nonsense:
https://launchpad.net/~yavdr/+archive/stable-vdr/+files/xineliboutput-sxfe_1.0.6%2Bcvs20110110.1350-0yavdr0_i386.deb
You could have just pointed out that launchpad's index only li
On 01/11/2011 03:18 PM, Tony Houghton wrote:
On 11/01/11 12:16, Eric Valette wrote:
https://launchpad.net/~yavdr/+archive/stable-vdr
cause its ubuntu and he uses debian ? ;)
The yavdr packages works fine on debian (or at least as on ubuntu)...
Except that:
I have them running on my box
> And yavdr doesn't include sxfe for some reason.
That is complete nonsense:
https://launchpad.net/~yavdr/+archive/stable-vdr/+files/xineliboutput-sxfe_1.0.6%2Bcvs20110110.1350-0yavdr0_i386.deb
Gerald
___
vdr mailing list
vdr@linuxtv.org
http://www.li
On 11/01/11 12:16, Eric Valette wrote:
https://launchpad.net/~yavdr/+archive/stable-vdr
cause its ubuntu and he uses debian ? ;)
The yavdr packages works fine on debian (or at least as on ubuntu)...
Except that:
The following packages have unmet dependencies:
libxine2 : Depends: libmagi
> The yavdr packages works fine on debian (or at least as on ubuntu)...
LOL
Gerald
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
https://launchpad.net/~yavdr/+archive/stable-vdr
cause its ubuntu and he uses debian ? ;)
The yavdr packages works fine on debian (or at least as on ubuntu)...
-- eric
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/li
2011/1/11 Dominic Evans :
> On 11 January 2011 01:14, Tony Houghton wrote:
>> Hm, probably not unless ttxtsubs is useful in the UK. I've been using
>> the Freesat patch up till now, but I'd probably be better off using the
>> Eepg plugin. I can probably borrow Debian bits for that from yaVDR
>> :)
On 11 January 2011 01:14, Tony Houghton wrote:
> Hm, probably not unless ttxtsubs is useful in the UK. I've been using
> the Freesat patch up till now, but I'd probably be better off using the
> Eepg plugin. I can probably borrow Debian bits for that from yaVDR
> :).
Why not exclusively use the y
On 10/01/11 22:36, Tobias Grimm wrote:
Am Montag, den 10.01.2011, 20:56 + schrieb Tony Houghton:
I see you have VDR 1.7 packages there too, I'd definitely be
interested in those. Would you recommend multipatch over standard?
Depends on your needs - decide for yourself - multipatch current
On 11/01/11 00:55, VDR User wrote:
There's no hassle involved by avoiding using debian sources. If you
ever decide you would like to try it and see, I'll even help you with
a script that does it all automagically.
Thanks, but I think I'll use Tobias' packages. It isn't just little
things like
On Mon, Jan 10, 2011 at 12:52 PM, Tony Houghton wrote:
>> You appear to want xine-lib-1.2, although I have no clue why you would
>> be confused about the trees. To my knowledge, there is only one
>> available at: hg clone http://hg.debian.org/hg/xine-lib/xine-lib-1.2
>
> That's fine if you know w
Am Montag, den 10.01.2011, 20:56 + schrieb Tony Houghton:
> I see you have VDR 1.7 packages there too, I'd definitely be interested
> in those. Would you recommend multipatch over standard?
Depends on your needs - decide for yourself - multipatch currently
includes the following patches:
htt
On 10.1.2011 22:52, Tony Houghton wrote:
> [...]
That's fine if you know what you're looking for, but the front page of
xine's official site links to the top-level of hg.debian.org which
contains getting on for 50 xine-lib branches. Including
xine-lib-1.2-vdpau which is apparently being developed
On 10/01/11 19:28, Tobias Grimm wrote:
Am Montag, den 10.01.2011, 18:51 + schrieb Tony Houghton:
I'd also be interested in the developer version of xine with VDPAU
support. The trouble is there's a bewildering set of mercurial branches.
There are some libxine2 packages in Debian experimenta
On 10/01/11 19:09, VDR User wrote:
You appear to want xine-lib-1.2, although I have no clue why you would
be confused about the trees. To my knowledge, there is only one
available at: hg clone http://hg.debian.org/hg/xine-lib/xine-lib-1.2
That's fine if you know what you're looking for, but th
On 10/01/11 19:28, Tobias Grimm wrote:
Am Montag, den 10.01.2011, 18:51 + schrieb Tony Houghton:
I'd also be interested in the developer version of xine with VDPAU
support. The trouble is there's a bewildering set of mercurial branches.
There are some libxine2 packages in Debian experimenta
On Mon, Jan 10, 2011 at 11:09 AM, VDR User wrote:
> You appear to want xine-lib-1.2, although I have no clue why you would
> be confused about the trees. To my knowledge, there is only one
> available at: hg clone http://hg.debian.org/hg/xine-lib/xine-lib-1.2
Sorry, I should clarify this. I mea
Am Montag, den 10.01.2011, 18:51 + schrieb Tony Houghton:
> I'd also be interested in the developer version of xine with VDPAU
> support. The trouble is there's a bewildering set of mercurial branches.
> There are some libxine2 packages in Debian experimental, but there don't
> seem to be any
On Mon, Jan 10, 2011 at 10:51 AM, Tony Houghton wrote:
> I don't find VDR 1.6.0 very reliable and I'm wondering whether 1.7 is
> mature enough now to be worth setting up. At the moment I use Debian
> packages and although I have to recompile it to add the Freesat patch
> it's still a lot easier th
I don't find VDR 1.6.0 very reliable and I'm wondering whether 1.7 is
mature enough now to be worth setting up. At the moment I use Debian
packages and although I have to recompile it to add the Freesat patch
it's still a lot easier than gathering the bits and pieces and getting
it to live nicely
Magnus Andersson wrote:
> Rolf Ahrenberg wrote:
>
>> I don't have any channels with teletext subtitles and haven't used the
>> plugin for years. However, if someone is keen enough to make a real fix
>> and send it to me, I can update my patches...
>>
>> BR,
>> --
>> rofa
>>
>>
>>
Big t
Rolf Ahrenberg wrote:
> On Wed, 27 Jun 2007, Luca Olivetti wrote:
>
>
>> I just commented out these lines and it seems to work (though lately I'm
>> not using it very much).
>>
Thank you Luca it works if i comment out four lines in ttxtsubsdisplay.c.
>
> Well, I guess it only works if your
On Wed, 27 Jun 2007, Luca Olivetti wrote:
> I just commented out these lines and it seems to work (though lately I'm
> not using it very much).
Well, I guess it only works if your VDR is using the same charset as
the teletext subtitling stream.
I don't have any channels with teletext subtitles
Magnus Andersson wrote:
> Hello!
>
> Does vdr-ttxtsubs plugin work with any of the latest vdr developer versions?
>
>
Not for me. I get compile errors (although different) with and without
the kermanekka-patch.
/Magnus Hörlin
> I have patched vdr with
> vdr-1.5.5-subtitl
Magnus Andersson wrote:
> Hello!
>
> Does vdr-ttxtsubs plugin work with any of the latest vdr developer versions?
>
>
Not for me. I get compile errors (although different) with and without
the kermanekka-patch.
/Magnus Hörlin
> I have patched vdr with
> vdr-1.5.5-subtitl
En/na Magnus Andersson ha escrit:
> ttxtsubsdisplay.c: In member function ‘void cTtxtSubsDisplay::ShowOSD()’:
> ttxtsubsdisplay.c:415: error: ‘SetCode’ is not a member of ‘cFont’
> ttxtsubsdisplay.c:415: error: ‘I18nCharSets’ was not declared in this scope
> ttxtsubsdisplay.c:438: error: ‘SetCode’
Magnus Andersson wrote:
> Hello!
>
> Does vdr-ttxtsubs plugin work with any of the latest vdr developer versions?
>
>
Not for me. I get compile errors (although different) with and without
the kermanekka-patch.
/Magnus Hörlin
> I have patched vdr with
> vdr-1.5.5-subtitl
Hello!
Does vdr-ttxtsubs plugin work with any of the latest vdr developer versions?
I have patched vdr with
vdr-1.5.5-subtitles-0.5.0-and-ttxtsubs-0.0.5.diff and the plugin itself
with vdr-ttxtsubs-0.0.5-kermanekka-edition.diff.
http://users.tkk.fi/~rahrenbe/vdr/
On my Gentoo amd64 system with
82 matches
Mail list logo
