Hi,

I also try to use VDR with freevo. Currently, vdr runs on my freevo box as a
daemon and I use the tvtime plugin (tv plugin) to view the /dev/video data (I
use a full featured dvb card).

I have the same wishlist as you and especially:
    - being able to start recordings from freevo gui
    - generate fxd file for a recorded show
    - batch converting recorded files to divx or what else (mpeg2 is good, but
a bit huge)
    - being able to drive vdr with my freevo remote control (currently I use
two different remotes: one to control vdr and the other one for freevo).

If I can help you to develop anything, or to test, or what else... I know 2 or
3 other users interested by these features (and who can contribute too I
think).

Sincerely,

Stéphane


----- Original Message ----- 
From: "Thomas Weber" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, September 09, 2004 1:58 PM
Subject: Re: [Freevo-devel] VDR integration


> Hey,
>
> > Yes, I'm resurrecting vdrpylib:
> >
> >
http://cvs.sourceforge.net/viewcvs.py/freevo/freevo/WIP/RobShortt/lib/vdrpylib/
> >
> >
> > This is an interface to VDR using SVDRP and VDR files if available on
> > the system (epg, timers, recordings...).
> >
> Yes. The lib is very nice. I already enhanced Ove's plugin with SVDRP
> support. For connection data i added several VDR_SVDRP_xxxx variables to
> local_conf.py.
>
> We need to think about a proper OO design, though. Your svdrpylib is
> already object oriented and has a couple of
> functions to get, for example, timers, epg or channel data back from
> vdr. These types differ unfortunately completly with those
> from freevos EPG/Tvguide implementation. So we need either a wrapper to
> construct the tvguide from svdrpylib objects or a bunch of proper
> subclasses.
> IMHO the subclass solution would be cleaner. What do you think?
>
> >
> > -usage of mplayer.  Better yet, I want an MPEG PS from VDR.  This
> > should be easily handled by most programs.  We'd also like to be able
> > to timeshift live TV, this should make it easier.
> >
> Yeah. I remember we talked in IRC about this topic. On of my most
> important "must haves" is client/server streaming. So i suggest to use
> VDR's streamserver Plugin as a foundation to get the needed MPEG stream.
> Using this we could also overcome vdr's "only 1 svdrp client allowed"
> problem. (read on for more thoughts)
>
> > BTW have you tried using TVTime with the /dev/videoX device created by
> > the DVB driver?
>
> Sure. Its working like a charm. For owners of full featured cards, this
> is the best way to get a picture from the card. The complete mpeg
> decoding is done by the dvb card. Hence i started to use SVDRP to
> communicate to VDR opposed to Ove's approach of using XINE events.
>
> >
> >> - manage scheduled and finished recordings in freevo's gui
> >
> >
> > We can interface with the timers.conf to schedule recordings.
> > Actually we could still maintain the schedule totally in freevo and
> > have a recording plugin to add a timer for "now" at the time of
> > recording.  We can get a list of VDR recordings (finished ones) from
> > SVDRP/vdrpylib or even have VDR's recording directory in TV_RECORD_DIR
> > or VIDEO_ITEMS.
>
> Yes. Thats what i would like to have. Keep the OO design in mind, though.
>
> >
> >> - convert recordings to divx or other format using freevo's gui and
> >> propably the vdr-convert package.
> >
> >
> > Are also are / will be Freevo plugins for transcoding / compressing
> > video.
> >
> Agreed.
>
> >
> > Personally, I don't think there should be a "vdr mode" per se.  I
> > think if things are configured properly and there are Freevo plugins
> > for VDR activated it should Just Work, meaning it will integrate VDR
> > information / channels / recordings into the existing Freevo interfaces.
> >
> Exactly. One uses just the TV section to access VDR transparently.
>
> > I have some other ideas to follow in our quest here:
> >
> > -Look at the Xine plugin for VDR.  That plugin creates some fifos for
> > Xine <-> VDR communication and MPEG data.  The VDR side also uses that
> > plugin as its primary display device... _very_ _cool_ IMO... I don't
> > use the tv-out on my DVB card at all.  Perhaps we could talk to the
> > vdr-xine author and learn the interface.  The VDR side could be used
> > for lots more than Xine.  It might be easy to develop an mplayer input
> > plugin for it.
> >
> I'm in touch with that guy. The sourcecode is also easy to read. I didnt
> take,however, a look at the lowlevel guts yet.
>
> >
> > -Look at streamdev.  That VDR plugin is actually two plugins,
> > streamdev-server and streamdev-client.  There are at least two
> > interfaces there, the VTP (Video Transport Protocol) and HTTP.  The
> > HTTP interface is the easiest to use but there are other advantages to
> > the VTP interface using the streamdev-client plugin.  You can have a
> > VDR machine running with no DVB card using the streamdev-client plugin
> > to provide its "device" for input.
> >
> Combining a remote streamdev server with a local VDR process is a ideal
> combination. I use a local vdr with XINE as viewer, for example. If we
> can get vdr's xine-plugin to interface with mplayer, we're done.
> This has IMHO several advantages compared to the "raw" http connection mode:
> - the local vdr is much more responsive to commands
> - forward/rewind/jumping without any problems
> - metadata like recording info and such is visible in the vdr osd
> - same look-and-feel at both the client and the server
>
> So we would need 2 SVDRP connections for client/server mode. One for the
> server to set/get timers, EPG data and recording metadata and one for
> the local client to control the live TV mode and the record player.
>
>
> Greetings,
>
> -- 
> Thomas
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by BEA Weblogic Workshop
> FREE Java Enterprise J2EE developer tools!
> Get your free copy of BEA WebLogic Workshop 8.1 today.
> http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click
> _______________________________________________
> Freevo-devel mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/freevo-devel
>



-------------------------------------------------------
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM.
Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php
_______________________________________________
Freevo-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/freevo-devel

Reply via email to