Georg Acher <acher@xxxxxxxxx> 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 _______________________________________________ vdr mailing list vdr@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
