On Sun, Sep 07, 2008 at 05:46:01PM +0200, Halim Sahin wrote:
> FULLACK Oliver,
> You have forgotten the point:
>
> * help to add dvb-s2 support into main kernel!!
Which one?
SCNR :-)
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...
--
Georg Acher, acher@xxxxxxxxx
http://www.lrr.in.tum.de/~acher
"Oh no, not again !" The bowl of petunias
_______________________________________________
vdr mailing list
vdr@xxxxxxxxxxx
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
