[vdr] VDR Development

Oliver Endriss o.endriss at gmx.de
Sun Sep 7 20:57:22 CEST 2008


Georg Acher wrote:
> I also don't think that a vdr-repository would help in the development
> speed. Either the whole development procedure needs to be changed (more
> maintainer with KLS's approval) or it has no advantage compared to the
> .tgz-distribution.
> 
> But I think the repository stuff is only marginal. The design itself
> matters. When looking at the experiences at Reel, there are some things to
> be considered in the (far) future of vdr 2.0:
> 
> - vdr has grown/evolved since 2000, but is still based in its design on the FF
> card and its capabilities. There are now different signal source setups
> (LNBs, rotor, multiproto, mixed tuners or shared tuners/CAMs like in the
> NetCeiver, and not forgetting the IPTV variants), various output types and
> devices (FF, DXR3, HDE, X11, ...) and especially more expectations what a
> PC-based STB should be able to do (playback of other media, "home
> automatisation", etc.).
> 
> - It allows no real server/client distinction. It is quite common to have a
> real file server somewhere in the house, but it's hard to get a vdr running
> on it and viewing on other clients. Even the recordings sharing of two vdrs
> is not that easy (touch update here and there...). One of the main
> advantages of Unix was resource sharing and distribution in heterogenous
> networks (like X over network), but vdr is currently focused only on "its"
> platform.
> 
> - The current plugin concept allows only a very limited access or
> modfications in the core behaviour. At least without core patches...
> 
> - Based on the long evolution history, vdr IMO also has some design
> problems. Every object interacts with each other, I'm personally lost in the
> inheritance-graph of dozens of identically named
> Get/Put/Add/Del/Action/Process-calls. Also the main loop (almost 1500LOC) is
> a bit fat ;-) This makes it hard for newcomers and potential contributors. I
> guess that there are only very few people that actually know what is going
> on in the device/devbdevice/remux/libsi-core.
> 
> I still favour vdr over mythTV or MCE, because their neglect the TV side.
> But we have to face it: Radio is dying already. Old fashioned TV over
> antenna is also getting more and more unimportant and is merged with other
> data sources (IPTV, internet radio, podcasts, ...). Full convergence is no
> "if", it's a "when".
> 
> So, the main discussion topic should be: What is needed for a future-proof
> design? It is not about XML or SQL or other hype buzzwords, it's about the
> overall design and how individual modules/plugins interact with each other.
> 
> Just my EUR0.01...

Indeed this would be a very interesting discussion.

CU
Oliver

-- 
----------------------------------------------------------------
VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/
----------------------------------------------------------------



More information about the vdr mailing list