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 on my system. Any chance of a 1.8 release soon?
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 packages for "version 2" players, nor libxine2-dev packages (not to mention vdpau support) so I don't see what use they are.
On Mon, Jan 10, 2011 at 10:51 AM, Tony Houghton h@realh.co.uk 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 than gathering the bits and pieces and getting it to live nicely on my system. Any chance of a 1.8 release soon?
Most users will agree that VDR is very stable regardless of its "stable" or "developer" status. I have nearly no problems at all and am running the latest developer version. For that matter, I update to every version that see's release.
I've never used debian package sources to compile from. Instead, I just grab all the sources I use from their respective host locations and compile -- a process that's very easily scriptable (which is what I've done).
I wouldn't hold my breath on VDR-1.8.0 being released soon. And I also wouldn't hold much value to it aside of being an announcement because as previously mentioned, the current developer version works great and is very stable for most users.
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 packages for "version 2" players, nor libxine2-dev packages (not to mention vdpau support) so I don't see what use they are.
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
It's simple to compile and again, something easily scriptable. VDPAU support in xine-lib-1.2 isn't flawless (depending on circumstances), but it works great. I'd definitely, and do, recommend it.
My advice would be you stop insisting on using debian sources for this stuff. Both VDR and xine-lib-1.2 are easily obtainable from their original sources, compile easily, and no hassling with screwy debian sources necessary.
On Mon, Jan 10, 2011 at 11:09 AM, VDR User user.vdr@gmail.com 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 meant there's only one official xine-lib-1.1 tree and one official xine-lib-1.2 tree so I'm not sure what you're confused about unless you're considering whatever cloned trees may exist. Honestly, I see no reason to bother with anything other then the official tree unless it provides you something you need which is missing from the official tree. Other people may offer other options but FWIW I used the official xine-lib-1.1 tree for vdpau up until vdpau support was merged into xine-lib-1.2, at which time I switched to xine-lib-1.2 and haven't touched 1.1 since. It's always been easy and I've never used anything other then the official trees.
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 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 alongside xine-lib-1.2 despite your saying it was merged in.
It's simple to compile and again, something easily scriptable. VDPAU support in xine-lib-1.2 isn't flawless (depending on circumstances), but it works great. I'd definitely, and do, recommend it.
My advice would be you stop insisting on using debian sources for this stuff. Both VDR and xine-lib-1.2 are easily obtainable from their original sources, compile easily, and no hassling with screwy debian sources necessary.
I use my HTPC for other stuff as well as VDR so I'd rather hack VDR to make it compatible with a (some would say "the") standard Linux distro than the other way round. Therefore I think the Debian packages' "screwiness" saves me a lot of hassle instead of adding to it.
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 alongside xine-lib-1.2 despite your saying it was merged in.
VDPAU support was merged into xine-lib-1.2 some time ago. The old tree xine-lib-1.2-vdpau is simply an alias for xine-lib-1.2.
On Mon, Jan 10, 2011 at 12:52 PM, Tony Houghton h@realh.co.uk 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 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 alongside xine-lib-1.2 despite your saying it was merged in.
Well, no.. I'll explain... As you said, the top level repository lists several tree's. However, there are only two tree's for xine-lib:
xine-lib/xine-lib Media player library back end (1.1; stable development branch)
xine-lib/xine-lib-1.2 Media player back end (1.2; unstable development branch)
Both clearly marked as 1.1 and 1.2. There isn't any and hasn't been a separate vdpau development tree for quite some time. Any leftover tree's now would simply point to one of the two listed above. A quick search of the changelog for xine-lib-1.2 reveals:
13 months ago Merge from 1.1; merge vdpau (with adjustments for 1.2). changeset Darren Salt linux@youmustbejoking.demon.co.uk [Fri, 20 Nov 2009 03:46:10 +0000] rev 11335 Merge from 1.1; merge vdpau (with adjustments for 1.2).
Hopefully that takes care of any confusion you have.
It's simple to compile and again, something easily scriptable. VDPAU support in xine-lib-1.2 isn't flawless (depending on circumstances), but it works great. I'd definitely, and do, recommend it.
My advice would be you stop insisting on using debian sources for this stuff. Both VDR and xine-lib-1.2 are easily obtainable from their original sources, compile easily, and no hassling with screwy debian sources necessary.
I use my HTPC for other stuff as well as VDR so I'd rather hack VDR to make it compatible with a (some would say "the") standard Linux distro than the other way round. Therefore I think the Debian packages' "screwiness" saves me a lot of hassle instead of adding to it.
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.
Best regards, Derek
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 editing a few paths in the Makefile I want to avoid, I also like runvdr supplied with Debian packages, I'd miss that.
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 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 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 alongside xine-lib-1.2 despite your saying it was merged in.
It's simple to compile and again, something easily scriptable. VDPAU support in xine-lib-1.2 isn't flawless (depending on circumstances), but it works great. I'd definitely, and do, recommend it.
My advice would be you stop insisting on using debian sources for this stuff. Both VDR and xine-lib-1.2 are easily obtainable from their original sources, compile easily, and no hassling with screwy debian sources necessary.
I use my HTPC for other stuff as well as VDR so I'd rather hack VDR to make it compatible with a (some would say "the") standard Linux distro than the other way round. Therefore I think the Debian packages' "screwiness" saves me a lot of hassle instead of adding to it.
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:
I prefer to use the vdr-sxfe frontend. I presume it does work with xinelib 1.2 because it's present in yavdr, but it's a pity it's bundled with the VDR plugin, from the point of view of building just the frontend because I've already got the VDR plugin catered for.
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 something. When that comes back to xine, xine crashes and I end up with a black screen with the command prompt in the upper left and the "X" mouse pointer in the middle and vdr still chugging away in the back ground. I have to restart vdr/xine/xorg to get it back up. He gave me a patch in irc channel 3 months ago which reduce the problem but didn't remove it. A couple weeks ago I updated and found the patch was still not in. Hopping a better fix had been put in, I used it stock and now have to restart several times a week, sometimes a day. Signal is strong, but the local broadcasters are morons and even with a strong signal and steady picture it will just crash because of some very minor blip in the stream. I also see the picture and audio go to a freeze frame studder. but that is fixable by simply switch channels. I have turned it on and found a green screen with no audio. This also corrects with a channel change.
Xine also has too much extra junk and its related dependencies which are not needed.
On 1/11/2011 11:33 AM, Tony Houghton wrote:
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:
I prefer to use the vdr-sxfe frontend. I presume it does work with xinelib 1.2 because it's present in yavdr, but it's a pity it's bundled with the VDR plugin, from the point of view of building just the frontend because I've already got the VDR plugin catered for.
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 player that works with xineliboutput in one day, but working out how to get the OSD would be a bit harder. If whatever plugins gstreamer chooses automatically to handle the TS etc turn out not to be suitable it can easily be forced to use ffmpeg (or any other compatible plugin) instead. It also has VDPAU and VA plugins.
On Tue, Jan 11, 2011 at 12:41 PM, Tony Houghton h@realh.co.uk 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 player that works with xineliboutput in one day, but working out how to get the OSD would be a bit harder. If whatever plugins gstreamer chooses automatically to handle the TS etc turn out not to be suitable it can easily be forced to use ffmpeg (or any other compatible plugin) instead. It also has VDPAU and VA plugins.
I think the idea is that he'd like to get away from using xinelib altogether in place of something else (ffmpeg). I'm not sure how using gstreamer, that uses xineliboutput, that uses xinelib would provide that. However, it sounds like gstreamer can just be forced to use ffmpeg so that may be a solution. So you're suggesting for example, a vdr-gstreamer plugin which uses ffmpeg to decode right? Would be nice to have the option available but afaik the only vdpau-supported output plugins for vdr are all based on xinelib. And by all I mean vdr-xine and xineliboutput.
On 11/01/11 20:52, VDR User wrote:
On Tue, Jan 11, 2011 at 12:41 PM, Tony Houghtonh@realh.co.uk 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 player that works with xineliboutput in one day, but working out how to get the OSD would be a bit harder. If whatever plugins gstreamer chooses automatically to handle the TS etc turn out not to be suitable it can easily be forced to use ffmpeg (or any other compatible plugin) instead. It also has VDPAU and VA plugins.
I think the idea is that he'd like to get away from using xinelib altogether in place of something else (ffmpeg). I'm not sure how using gstreamer, that uses xineliboutput, that uses xinelib would provide that. However, it sounds like gstreamer can just be forced to use ffmpeg so that may be a solution. So you're suggesting for example, a vdr-gstreamer plugin which uses ffmpeg to decode right? Would be nice to have the option available but afaik the only vdpau-supported output plugins for vdr are all based on xinelib. And by all I mean vdr-xine and xineliboutput.
Perhaps I misunderstood how xineliboutput works, but I thought that when using a remote client the VDR plugin component doesn't actually depend on libxine, but just streams to a socket in a format that libxine can decode. And that stream is just a standard TS except that some of the packets contain OSD data? MPlayer and VLC can read the stream (not sure about with VDR 1.7, but they could with the old PES version and I don't see why they wouldn't work with TS too) and ignore the OSD. So any client based on gstreamer and/or ffmpeg can already understand most of the stream, it just needs a way to extract and display the OSD. Using the existing xineliboutput plugin would save writing a new VDR plugin which would just duplicate the functionality of one we already have.
On 12 January 2011 10:23, Tony Houghton h@realh.co.uk wrote:
On 11/01/11 20:52, VDR User wrote:
On Tue, Jan 11, 2011 at 12:41 PM, Tony Houghtonh@realh.co.uk 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 ffmpeg. It't not a full client - server solution like xineliboutput is, but it does have a shmem client server setup which might work for you.
It doesn't support vdpau though, if that's what you need.
I've recently tries out yavdr 0.3a setting up a vdr box from scratch and I'm very impressed by how easy it was to get everything set up. I only had to configure channels.conf and the lirc remote setup, and everything was working out of the box, even vdpau with 1080p support.
On Tue, Jan 11, 2011 at 4:40 PM, Torgeir Veimo torgeir@netenviron.com 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 ffmpeg. It't not a full client - server solution like xineliboutput is, but it does have a shmem client server setup which might work for you.
It doesn't support vdpau though, if that's what you need.
Isn't softdevice abandoned? Someone had told me that it's no longer developed. At any rate vdpau support is a requirement so anything that doesn't have it can automatically be ruled out. I do agree that it would be nice to have an ffmpeg-based vdr plugin but at present the only vdpau capable option I'm aware of depends on libxine.
On 12 January 2011 13:09, VDR User user.vdr@gmail.com wrote:
On Tue, Jan 11, 2011 at 4:40 PM, Torgeir Veimo torgeir@netenviron.com 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.
At any rate vdpau support is a requirement so anything that doesn't have it can automatically be ruled out. I do agree that it would be nice to have an ffmpeg-based vdr plugin but at present the only vdpau capable option I'm aware of depends on libxine.
I guess that what you'd really want would be a pure VDPAU playback device, not necessarily using ffmpeg.
On Tue, Jan 11, 2011 at 7:32 PM, Torgeir Veimo torgeir@netenviron.com 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.
At any rate vdpau support is a requirement so anything that doesn't have it can automatically be ruled out. I do agree that it would be nice to have an ffmpeg-based vdr plugin but at present the only vdpau capable option I'm aware of depends on libxine.
I guess that what you'd really want would be a pure VDPAU playback device, not necessarily using ffmpeg.
That would be great actually. Or just having another option period besides something dependent on libxine. The guy who suggested ffmpeg originally said it's vdpau implementation works much better for him, as I've heard others mention as well. My experience is that libxine-based (I've only used vdr-xine btw) works pretty well. However, it would still be nice to have more options available, especially for those who aren't as lucky as I with libxine.
As is always the case though, user needs/wants depend on developers time, effort, and interest. I'm not sure what all it would take to write an output plugin for VDR that uses the ffmpeg vdpau library but maybe someone with the ability to do one will give it a shot.
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 who suggested ffmpeg originally said it's vdpau implementation works much better for him, as I've heard others mention as well. My experience is that libxine-based (I've only used vdr-xine btw) works pretty well. However, it would still be nice to have more options available, especially for those who aren't as lucky as I with libxine.
On Wednesday 12 Jan 2011, Torgeir Veimo wrote:
On 12 January 2011 13:09, VDR User user.vdr@gmail.com wrote:
On Tue, Jan 11, 2011 at 4:40 PM, Torgeir Veimo
torgeir@netenviron.com 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.
Unfortunately, it does seem to have been abandoned. I'm still using it with vdr 1.7.0 (I've never managed to get it to work with any more recent versions, probably because it doesn't like the change to TS).
I'm reading this (and similar threads) with interest: no HD in my area yet but it is meant to be coming this year. All of the current HD options seem to be a bit hit and miss so I've not really had a go at that yet.
Softdevice uses libavcodec to decode and then a number of different methods to output the decoded frames. I'm using it with a Matrox card for output and this works really well. It's a nice, lightweight solution that doesn't depend on having an X server running but doesn't support a client- server setup.
At any rate vdpau support is a requirement so anything
that doesn't have it can automatically be ruled out. I do agree that it would be nice to have an ffmpeg-based vdr plugin but at present the only vdpau capable option I'm aware of depends on libxine.
I guess that what you'd really want would be a pure VDPAU playback device, not necessarily using ffmpeg.
What would be nice is if the decoding functions in ffmpeg / libavcodec supported vdpau. I don't know whether that is even possible or whether it is only possible to decode "directly to HDMI", for example, and not just decode and then use something else to output the decoded frames.
Maybe this is now possible: I've not looked at ffmpeg for a while, although my experiences of ffmpeg is that there are huge interface changes between releases that break things!
Cheers,
Laz
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 the motherboard sound card via SPDIF) but now I can get HD video with multichannel audio through VDR and also switch from the VDR main menu into Boxee (need to add this yourself) to handle playing local media (and free movies provided in the library) as well as running apps such as BBC iplayer and all the hundreds of other TV apps available (You Tube, Browser, Flickr, CNET, NASA TV etc).
I also compiled up the vomp mediaplayer plugin to drive my 2 Hauppauge Media MVPs (TV and media distributed through the house) and hooked it up to my rotor (rotor plugin seems pretty unstable though and crashes VDR regularly) and use channel scan to find sat channels.
I'm really pleased with it as it makes a great HTPC and Internet TV App solution and it has a high WAF.
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 (mostly addressing audio sync issues when I used the motherboard sound card via SPDIF) but now I can get HD video with multichannel audio through VDR and also switch from the VDR main menu into Boxee (need to add this yourself) to handle playing local media (and free movies provided in the library) as well as running apps such as BBC iplayer and all the hundreds of other TV apps available (You Tube, Browser, Flickr, CNET, NASA TV etc).
Sounds good. How are you running iPlayer, etc.? Through Firefox or equivalent?
My current setup headless setup (control by remote only) so I can't run anything else like a browser withough ssh-ing in (and I'd need X, too!). If I change it all and am forced to use X for the video output, I could also run other apps too, although it would be nice to do it all from just the remote...
I also compiled up the vomp mediaplayer plugin to drive my 2 Hauppauge Media MVPs (TV and media distributed through the house) and hooked it up to my rotor (rotor plugin seems pretty unstable though and crashes VDR regularly) and use channel scan to find sat channels.
I've got a couple of Media MVPs hanging off of my setup too! They won't do HD, though. :-(
Cheers,
Laz
On Wed, Jan 12, 2011 at 12:02 PM, Laz laz@club-burniston.co.uk 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 of my setup too! They won't do HD, though. :-(
No, but my other screens are both 19" so HD doesn't really matter to me - the screens are too small to warrant HD.
There is a Media MVP HD out, but its not supported yet - I think there is some work going on (see VOMP forum) but I wouldn't hold your breath for awhile, if ever, due to the API not being public.
Cheers
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 play other formats. But then that is part of ffmpeg, so a player based on ffmpeg would have it rulling out the big attraction for some for xineliboutput
etc....
On 1/11/2011 8:32 PM, Torgeir Veimo wrote:
On 12 January 2011 13:09, VDR Useruser.vdr@gmail.com wrote:
On Tue, Jan 11, 2011 at 4:40 PM, Torgeir Veimotorgeir@netenviron.com 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.
At any rate vdpau support is a requirement so anything that doesn't have it can automatically be ruled out. I do agree that it would be nice to have an ffmpeg-based vdr plugin but at present the only vdpau capable option I'm aware of depends on libxine.
I guess that what you'd really want would be a pure VDPAU playback device, not necessarily using ffmpeg.
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 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 player that works with xineliboutput in one day, but working out how to get the OSD would be a bit harder. If whatever plugins gstreamer chooses automatically to handle the TS etc turn out not to be suitable it can easily be forced to use ffmpeg (or any other compatible plugin) instead. It also has VDPAU and VA plugins.
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. 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's more convenient for me to use a client-server setup) and replacing 3 with something based on ffmpeg and/or gstreamer.
From xineliboutput's README:
: (xine-lib is not required for server in network-only usage)
network usage can include localhost.
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 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 player that works with xineliboutput in one day, but working out how to get the OSD would be a bit harder. If whatever plugins gstreamer chooses automatically to handle the TS etc turn out not to be suitable it can easily be forced to use ffmpeg (or any other compatible plugin) instead. It also has VDPAU and VA plugins.
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
On Wed, Jan 12, 2011 at 10:31 AM, Tony Houghton h@realh.co.uk wrote:
- A stream server plugin.
- An integrated player plugin based on xine.
- 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's more convenient for me to use a client-server setup) and replacing 3 with something based on ffmpeg and/or gstreamer.
From xineliboutput's README:
: (xine-lib is not required for server in network-only usage)
network usage can include localhost.
And you get VDR's full osd doing this?
On 12/01/11 18:42, VDR User wrote:
On Wed, Jan 12, 2011 at 10:31 AM, Tony Houghtonh@realh.co.uk wrote:
- A stream server plugin.
- An integrated player plugin based on xine.
- 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's more convenient for me to use a client-server setup) and replacing 3 with something based on ffmpeg and/or gstreamer.
From xineliboutput's README:
: (xine-lib is not required for server in network-only usage)
network usage can include localhost.
And you get VDR's full osd doing this?
Yes, if you use a libxine-based player which supports it (the support is now in libxine). So to replace xine with something else someone needs to work out how xineliboutput serves up the OSD and write something to read it. If it's embedded as private data packets or whatever in the TS I think it should be possible to hook into ffmpeg's or gstreamer's demuxers to get access to it.
On Wed, Jan 12, 2011 at 11:15 AM, Tony Houghton h@realh.co.uk wrote:
- A stream server plugin.
- An integrated player plugin based on xine.
- 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's more convenient for me to use a client-server setup) and replacing 3 with something based on ffmpeg and/or gstreamer.
From xineliboutput's README:
: (xine-lib is not required for server in network-only usage)
network usage can include localhost.
And you get VDR's full osd doing this?
Yes, if you use a libxine-based player which supports it (the support is now in libxine). So to replace xine with something else someone needs to work out how xineliboutput serves up the OSD and write something to read it. If it's embedded as private data packets or whatever in the TS I think it should be possible to hook into ffmpeg's or gstreamer's demuxers to get access to it.
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.
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 insist on the decoding being done by the VDR plugin? It's far more flexible if the VDR plugin serves a stream without decoding it and the player is separate. And that way we only need a new player, a suitable streaming plugin, including OSD, already exists in xineliboutput.
On Wed, Jan 12, 2011 at 2:33 PM, Tony Houghton h@realh.co.uk 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 insist on the decoding being done by the VDR plugin? It's far more flexible if the VDR plugin serves a stream without decoding it and the player is separate. And that way we only need a new player, a suitable streaming plugin, including OSD, already exists in xineliboutput.
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 know some people have had success turning VDR into a server/client system but when I tried it, it was trash and a long way from usable in a 'stable' or 'daily use' VDR environment so I'm not that easily convinced the idea is a great one.
Don't get me wrong however, I'm not knocking any alternative to something that is completely independent of xinelib. If what you suggests is really so simple, _stable_, and provides _all_ necessary functionality for the user then I'm all for it. Until something exists in reality that we can test though, it's all just tossing around ideas. Although I personally have success with the xinelib+vdr-xine combo, I'm more then willing to test other options that include vdpau support and are 100% independent of xinelib and anything else I don't need or want.
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 know some people have had success turning VDR into a server/client system but when I tried it, it was trash and a long way from usable in a 'stable' or 'daily use' VDR environment so I'm not that easily convinced the idea is a great one.
The client-server model is almost essential to me. I wouldn't be interested in a solution that ties me to watching on one PC only and won't let me turn off playback without also preventing background recording. I'd be using mythtv by now if the DVB-S support in the setup tool wasn't completely broken.
VDR's inherent limitations are that you can't have more than one client using it at once with separate OSDs etc, but that's acceptable to me as long as I have a choice of which room to watch in. Client-server doesn't have to make it unreliable, but admittedly it does increase complexity and therefore the likelihood of bugs.
If written in a modular way the same bits of code could be used in two different plugins, one completely inetgrated and one client-server, so I won't say I'm completely disinterested in an all-in-one plugin.
Tony Houghton skrev 2011-01-13 18:44:
The client-server model is almost essential to me. I wouldn't be interested in a solution that ties me to watching on one PC only and won't let me turn off playback without also preventing background recording. I'd be using mythtv by now if the DVB-S support in the setup tool wasn't completely broken. [...]
For DVB-T, one option that I am eagerly awaiting user experience reports on, is a setup using dvblast/mumudvb or some such on the server and then multiple vdr clients using the iptv plugin. It does require you to have as many DVB adapters as MUX'es though, but here in Sweden that translates to at most 7 and in practice 4-5.
/Johan
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 wrote:
On Wed, Jan 12, 2011 at 10:31 AM, Tony Houghtonh@realh.co.uk wrote:
- A stream server plugin.
- An integrated player plugin based on xine.
- 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's more convenient for me to use a client-server setup) and replacing 3 with something based on ffmpeg and/or gstreamer.
From xineliboutput's README:
: (xine-lib is not required for server in network-only usage)
network usage can include localhost.
And you get VDR's full osd doing this?
Yes, if you use a libxine-based player which supports it (the support is now in libxine). So to replace xine with something else someone needs to work out how xineliboutput serves up the OSD and write something to read it. If it's embedded as private data packets or whatever in the TS I think it should be possible to hook into ffmpeg's or gstreamer's demuxers to get access to it.
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 served by getting the softdevice plugin actively maintained again, including a developer with an interest in VDPAU.
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 monitors, using VDR in a window in a desktop environment. The second you've required the user to have a full blown desktop, you've entered the realm of poor design. The ideal situation would be to have minimal requirements/dependencies and no bloat.
Additionally, an OSD that takes advantage of vdpau as well so you not only get full HDTV, but also a full high resolution/high color OSD with low hardware requirements & cost to the user to go along with it. I know the OSD has been a point of debate but the truth is people do spend a lot of time in the OSD and because of that, there's no reason that can't be an enjoyable user experience. Chalking it up as mere "eye candy" completely disregards that fact. It's no different to the reason why people put nice stereos in their car... to have a better experience while using it. Given the choice between a nice Benz or a base model Kia...how many people would actually choose the Kia? Not many, so lets not pretend otherwise.
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 for box maintenance. Not computer monitors, using VDR in a window in a desktop environment. The second you've required the user to have a full blown desktop, you've entered the realm of poor design. The ideal situation would be to have minimal requirements/dependencies and no bloat.
Client-server doesn't require a desktop environment. You can just as easily arrange for the player client to start automatically and have VDR handle the remote control. My preference for being able to turn the player off goes back a long way though, to when VDR didn't have good support for playing other video files. There are a lot of people who also use XBMC etc.
Additionally, an OSD that takes advantage of vdpau as well so you not only get full HDTV, but also a full high resolution/high color OSD with low hardware requirements & cost to the user to go along with it. I know the OSD has been a point of debate but the truth is people do spend a lot of time in the OSD and because of that, there's no reason that can't be an enjoyable user experience. Chalking it up as mere "eye candy" completely disregards that fact. It's no different to the reason why people put nice stereos in their car... to have a better experience while using it. Given the choice between a nice Benz or a base model Kia...how many people would actually choose the Kia? Not many, so lets not pretend otherwise.
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 plugin. I think the ability to antialias the text would be the biggest improvement, it often looks jagged.
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 need some rewriting/patching in core VDR, not just a plugin. I think the ability to antialias the text would be the biggest improvement, it often looks jagged.
The next developer version of VDR will contain full True-Color OSD support. I'm in the final stages of implementing all that's necessary to do that, like background image, transparent and movable overlayed pixmaps and the like.
Klaus
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 plugin. I think the ability to antialias the text would be the biggest improvement, it often looks jagged.
The next developer version of VDR will contain full True-Color OSD support. I'm in the final stages of implementing all that's necessary to do that, like background image, transparent and movable overlayed pixmaps and the like.
Klaus
Wow! The world may be changing!!
Will this be a 1.8 release, or still in the 1.7 development train?
Any ETA?
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 test it before pronouncing it "stable" ;-)
Klaus
On Thu, Jan 13, 2011 at 1:40 PM, Klaus Schmidinger Klaus.Schmidinger@tvdr.de 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 need some rewriting/patching in core VDR, not just a plugin. I think the ability to antialias the text would be the biggest improvement, it often looks jagged.
The next developer version of VDR will contain full True-Color OSD support. I'm in the final stages of implementing all that's necessary to do that, like background image, transparent and movable overlayed pixmaps and the like.
Wow, wasn't expecting that! Did you get a new tv or something? ;)
On 14.01.2011 18:33, VDR User wrote:
On Thu, Jan 13, 2011 at 1:40 PM, Klaus Schmidinger Klaus.Schmidinger@tvdr.de 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 need some rewriting/patching in core VDR, not just a plugin. I think the ability to antialias the text would be the biggest improvement, it often looks jagged.
The next developer version of VDR will contain full True-Color OSD support. I'm in the final stages of implementing all that's necessary to do that, like background image, transparent and movable overlayed pixmaps and the like.
Wow, wasn't expecting that! Did you get a new tv or something? ;)
No. It's more like I got sick and tired of permanently hearing how "bad" VDR's OSD is...
Klaus
On Tue, Jan 11, 2011 at 12:20 PM, Timothy D. Lenz tlenz@vorgon.com 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 you're not alone there. I believe ffmpeg is more actively developed as well which would explain why it has better vpdau support. Xine's vdpau support has come a long way but there are still a few bugs that need to be addressed. Guess we'll see which comes first, an ffmpeg VDR plugin, or xine being fixed. Not sure I would hold my breath for either however. ;)
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 decoder engine.decoder_priorities.ffmpegaudio:1 # priority for ffmpegvideo decoder engine.decoder_priorities.ffmpegvideo:1
Just increase codec priorities.
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 Kosunen wrote:
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 decoder engine.decoder_priorities.ffmpegaudio:1 # priority for ffmpegvideo decoder engine.decoder_priorities.ffmpegvideo:1
Just increase codec priorities.
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Am Montag, den 10.01.2011, 18:51 +0000 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 packages for "version 2" players, nor libxine2-dev packages (not to mention vdpau support) so I don't see what use they
If it's just about the VDPAU support, you can use the xine 1.1.19 from my repository which includes VDPAU support an seems to work well on Squeeze.
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
Tobias
On 10/01/11 19:28, Tobias Grimm wrote:
Am Montag, den 10.01.2011, 18:51 +0000 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 packages for "version 2" players, nor libxine2-dev packages (not to mention vdpau support) so I don't see what use they
If it's just about the VDPAU support, you can use the xine 1.1.19 from my repository which includes VDPAU support an seems to work well on Squeeze.
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
I get a lot of audio problems too, I was hoping maybe this had improved, especially pulseaudio support, in the 1.2 branch.
On 10/01/11 19:28, Tobias Grimm wrote:
Am Montag, den 10.01.2011, 18:51 +0000 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 packages for "version 2" players, nor libxine2-dev packages (not to mention vdpau support) so I don't see what use they
If it's just about the VDPAU support, you can use the xine 1.1.19 from my repository which includes VDPAU support an seems to work well on Squeeze.
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
I see you have VDR 1.7 packages there too, I'd definitely be interested in those. Would you recommend multipatch over standard?
Am Montag, den 10.01.2011, 20:56 +0000 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:
Tobias
On 10/01/11 22:36, Tobias Grimm wrote:
Am Montag, den 10.01.2011, 20:56 +0000 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:
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 h@realh.co.uk 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 yaVDR repositories?
2011/1/11 Dominic Evans oldmanuk@gmail.com:
On 11 January 2011 01:14, Tony Houghton h@realh.co.uk 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 yaVDR repositories?
cause its ubuntu and he uses debian ? ;)
cause its ubuntu and he uses debian ? ;)
The yavdr packages works fine on debian (or at least as on ubuntu)...
-- eric
On 11/01/11 12:16, Eric Valette wrote:
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: libmagickcore2 (>= 7:6.5.7.8) but it is not installable Depends: libmagickwand2 (>= 7:6.5.7.8) but it is not installable Depends: libmodplug0c2 (>= 1:0.7-4.1) but it is not installable Depends: libmpcdec3 but it is not installable
AFAICT those packages are obsolete in Debian Squeeze or newer. If I try to install them from Lenny I'll probably have problems with other things that depend on ImageMagick.
And yavdr doesn't include sxfe for some reason.
And yavdr doesn't include sxfe for some reason.
That is complete nonsense: https://launchpad.net/~yavdr/+archive/stable-vdr/+files/xineliboutput-sxfe_1...
Gerald
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...
You could have just pointed out that launchpad's index only lists source packages so I had to search for xineliboutput instead of sxfe. But you went the extra mile with an insult and a link to a package guaranteed to be of no use to me. Thank you very much.
On 01/11/2011 03:18 PM, Tony Houghton wrote:
On 11/01/11 12:16, Eric Valette wrote:
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.Your problem are with xine not vdr...
I use XBMC as a front end...
--eric
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:
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.Your problem are with xine not vdr...
True, but I think I need updated xine packages to go with VDR. The stock Debian unstable ones don't seem to work at all with VDR 1.7 (probably because of the change to TS format). Tobias Grimm's ones do, but VDPAU really isn't usable in that version, so I'll have to try compiling 1.2.
On 10/01/11 19:28, Tobias Grimm wrote:
Am Montag, den 10.01.2011, 18:51 +0000 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 packages for "version 2" players, nor libxine2-dev packages (not to mention vdpau support) so I don't see what use they
If it's just about the VDPAU support, you can use the xine 1.1.19 from my repository which includes VDPAU support an seems to work well on Squeeze.
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
I'm now using the VDR packages from here (except I'm using sid instead of squeeze) and they seem to be working well. Unfortunately that is except for the VDPAU plugin. On my HTPC it's very jerky and tends to start flickering after a while. On my main PC the flickering also popped up, but it was smoother. But I was testing SD so I wouldn't have thought it's because my HTPC's GPU is too weak (I even tried setting the deinterlacing to "bob"). It can play 720p H264 videos with mplayer.
I don't get any picture at all on HD channels, with or without VDPAU.
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.
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 "required" did solve the problem.
In other words, its the patches series that breaks HD for me not original vdr1.7.16. I did not spend the time to manually apply each package one by one as unfortunately you need to recompile plugins as well (live, streamdev, epgserach, ...).
--eric
On Monday 10 Jan 2011, Tobias Grimm wrote:
Am Montag, den 10.01.2011, 18:51 +0000 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 packages for "version 2" players, nor libxine2-dev packages (not to mention vdpau support) so I don't see what use they
If it's just about the VDPAU support, you can use the xine 1.1.19 from my repository which includes VDPAU support an seems to work well on Squeeze.
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've always built vdr and a range of plugins from source, all under Debian. I've just been browsing the contents of your repository and I see that you do have what looks like most of the plugins I'm currently using in there. One question before I test your pre-compiled version...
I'm currently using the softdevice plugin but I've never managed to get it to work with any versions of vdr newer than 1.7.0 (probably due to the 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 think all I ever got was a black screen whenever I tried to build CVS softdevice against anything newer than 1.7.0!
I also have another plugin which controls some LEDs hung of the parallel port which light up when recordings are active, etc. (based on a plugin I found years back which I'm pretty sure is no longer developed). How easy is it to combine a single plugin built from source into a .deb based setup?
Cheers,
Laz
2011/1/14 Laz laz@club-burniston.co.uk:
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 controls some LEDs hung of the parallel port which light up when recordings are active, etc. (based on a plugin I found years back which I'm pretty sure is no longer developed). How easy is it to combine a single plugin built from source into a .deb based setup?
Tobias has created some time back a command called debianize-vdr-plugin. Using that it should be matter of minutes to create a deb from your plugin (for your local use).
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.7.16, so it will probably not work.
I also have another plugin which controls some LEDs hung of the parallel port which light up when recordings are active, etc. (based on a plugin I found years back which I'm pretty sure is no longer developed). How easy is it to combine a single plugin built from source into a .deb based setup?
As Steffen already answered, it's as easy as running debianize-vdr-plugin. This works for most of the plugins and should at least give you something, that can be easily tweaked.
Tobias
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 me. It doesn't contain any special patches for 1.7.16, so it will probably not work.
I may give it a quick go: I'll have to work out whether installing it will break my currently working system. I'm pretty sure everything is under /usr/local and so shouldn't be overwritten: it pays to be paranoid!
:-)
I also have another plugin which controls some LEDs hung of the parallel port which light up when recordings are active, etc. (based on a plugin I found years back which I'm pretty sure is no longer developed). How easy is it to combine a single plugin built from source into a .deb based setup?
As Steffen already answered, it's as easy as running debianize-vdr-plugin. This works for most of the plugins and should at least give you something, that can be easily tweaked.
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?
Cheers,
Laz
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 required to build VDR-plugins.
Tobias
-
Dominic Evans -
Eric Valette -
Eric Valette
-
Gerald Dachs -
Johan Andersson -
Klaus Schmidinger -
L. Hanisch -
Laz -
Morfsta -
Pauli Borodulin -
Pertti Kosunen -
Simon Baxter -
Steffen Barszus -
Timothy D. Lenz -
Tobi -
Tobias Grimm
-
Tony Houghton -
Torgeir Veimo -
VDR User