Idea: we always use our recordserver. We have a vdr record
plugin. Before a program should be recorded (e.g. 5 minutes before
that, normal padding), the recordserver will call that plugin. Now the
start stop daemon starts vdr and the plugin schedules the recording in
vdr.
I'm not sure if this is necessary at all. VDR has its own scheduler which is easily controllable via svdrp (tcpip) access.
So basicly its sufficient to interface vdr to query for scheduled programs whenever a user enters the timer menu.
When one starts/changes a timed recording, freevo can send the data to vdr.
This means: let vdr be the primary scheduler and database for timers because its doing its job very well.
Personally i'm considering vdr+some freevo plugins as just some sort of recordserver implementiation.
You might ask: why should this be the better solution?
- it interfaces also with remote vdr installations (the usual "server" in one's basement)
- its compatible to vdr timer plugins like the tvtv plugin to schedule timers via web interface (http://tvtv.de)
- its (IMHO) cleaner and easier.
- vdr is a very lightweight daemon. Let it run instead of start/stopping it.
- vdr streaming clients rely on a always-on vdr instance.
- vdr has VPS support in the current developer releases. Stopping vdr renders this useless.
I would like to second this, I fully agree. VDR is simply very mature already in managing these things, and the other arguments, like running it as a deamon all the time, with possibilities of connecting clients, or management via vdradmin are IMHO also strong enough.
One could argue that retrieving epg data and scheduled recordings via svdrp from vdr every time a user displays freevo's recordserver information in the freevo's OSD or web server is slow. Wouldn't be some sort of caching and parallel background syncronization help, in order to let VDR's database be the master repository for that (only for DVB, and let freevo handle other TV sources like analog capture cards or PVRs, which it does pretty well)?
I think most of you core freevo devs (at least Rob said once on IRC) wouldn't want to get to see VDRs OSD when using VDR from within Freevo. Maybe VDR's OSD looks ugly compared with Freevo's, especially compared to how it will hopefully soon look like in bmovl2 for example, but maybe some sort of mplayer-based client could be developed (similar to the vdr-xine plugin which displays VDR's OSD) which acts on the same time as Freevo OSD canvas via bmovl2, and when VDR is accessed from Freevo, it would just stream the video from the VDR deamon and re-implement a nice, freevo-themed version of VDR's OSD, perfectly integrated into Freevo's Look'n'Feel. This would have the advantage that operation would be really seemless, without that ugly switching between Freevo's OSD and mplayer playing video or TV (at least under DirectFB). Of course, it may have the disadvantage that, if mplayer crashes, Freevo crashes too (at least the VDR deamon would survive and finish recordings ;-) ).
However, I think that such a bivalent plugin should have to link against VDR itself, too, like other VDR video output plugins (dxr3, softdevice, vdr-xine) do, in order to have access to all the information needed by the OSD. Or maybe the info available through SVDRP is enough?
What do you think of it, am I talking bullshit?
Lucian
------------------------------------------------------- This SF.Net email is sponsored by: Sybase ASE Linux Express Edition - download now for FREE LinuxWorld Reader's Choice Award Winner for best database on Linux. http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click _______________________________________________ Freevo-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freevo-devel
