Georg Acher acher@in.tum.de 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:
full ack.
- 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 device/devbdevice/remux/libsi-core.
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 see it.
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 ... clemens