[vdr] [ANNOUNCE] VDR developer version 1.7.24

Udo Richter udo_richter at gmx.de
Wed Feb 29 20:45:54 CET 2012

Am 29.02.2012 17:50, schrieb Tony Houghton:
> On Wed, 29 Feb 2012 16:48:33 +0100
> Manuel Reimer <manuel.reimer at gmx.de> wrote:
>> What does this mean? Do you plan built-in networking support or do
>> you plan to improve streamdev? IMHO it is a big task to make really
>> good networking support. Keeping this code separate (means: A plugin)
>> isn't a that bad idea, I think. Of course, this plugin could be
>> delivered directly with VDR, like the other "built-in" plugins.
> I don't think a plugin is enough. For better client-server VDR
> needs to support multiple clients watching different channels with
> different OSDs simultaneously.

Not necessarily. I think the key solution is to modularize VDR's
internal structures, with well defined interfaces between them. A
receiving module that provides stream sources, a recording module that
does all the timer work, a frontend module that can display, a storage
module that can store and provide videos, for example.
A timer menu that belongs to a recording backend, a recording menu that
displays content of storage modules, several frontends that can connect
to one recording backend or several storage modules, and all can connect
to different sources.

With defined and pluggable structures between them, its easy to have
them either locally connected or linked over network. Whether that's
done by a plugin or VDR internally doesn't matter.

In any case this would be the biggest rewrite of major parts of VDR
ever, with lots of breakage, total loss of plugin compatibility and very
long development cycle.



More information about the vdr mailing list