Georg Acher <[EMAIL PROTECTED]> 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.
maybe using git, where you can pull into your own repository for privat
vdr hacking and let other people check it out may be worth a thought.
> 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.).
i always wondered why dvb support was directly compiled in while other
back and frontends were supposed to be plugins. this clearly leaves a
sign that dvb is the "preferd" plattform.
> - 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.
for me the biggest obstacle so far in many years of vdr usage. i have
already layed down CAT5 into the living room, why do i still have to
connect directly to the satelite dish to get flawless live viewing?
> - 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
not only that, but also are many standard containers reimplemented in
the core source that increase LOC count for no good, at least i can't
> 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".
yes, there is currently no better software for watching, recording and
replaying TV if one uses vdr with a FF card.
best regards ...
vdr mailing list