On Thu, Sep 25, 2008 at 6:22 PM, Jörg Knitter <joerg.knitter@xxxxxx> wrote: > VDR User wrote: >> 2008/9/25 Sacha <sacha@xxxxxxxxxx>: >> >>> Following your discussion from an end-user point of viwer I must say that I >>> wholy agree with this statement: >>> >>> <But 2 years to get a new API is really too much. And during these 2 years, >>> 2 >>> >>> <different trees for 2 differents drivers was totally insane. We >>> (applications >>> >>> <devs) are always making our best to bring DVB to users as easily as >>> possible. >>> >>> <And trust me, the multiproto story has complicated users life A LOT. This >>> must NEVER happen again. >>> >>> We, end-users want our stuff working now! >>> >> >> I assume you'd also like something that is well-designed, tested, and >> stable rather then slapped together and rushed... But you know what >> they say about assumptions! >> > > I have to agree with the claim Sacha said. > > I am also "just" an end-user, got a TT3200 with VDR 1.7 working with all > the guides and even wrote an article on it. But it was and is still a > pain - for 2 years now. > > With the introduction of the alternative S2API I was hoping that this > long wait is over after waiting endlessly after the announcement, > multiproto is ready "in a few weeks". > > I have followed the discussion all the two (?) years, and I did just > filter out information about, when the API could be ready, and I was > shocked by all the really bad personal attacks that happened last year > (or the year before) and the splits that results now in four > "repositories" (kernel, multiproto, hvr4000-stuff and mcentral), often > with dozens of patches postet here or at vdrportal that need to be > applied to get a DVB card running. > > And the main reasons for this is not really technical, it seems to me > that they are personal. Open source projects claim to be better than > commercial products, but the things that happened and currently happen > are a good reason to see also the disadvantage of community development. > > I understand all sides: > 1) Manu does not want to to give up his work that he worked for long 2 > years. > 2) Markus Rechberger also did a lot of work, but I remember him to be > very insulting to other developers - and quite uncooperative by starting > his own tree. Linux development with MCC as leader might indeed be hard > ;)... just a small side note here, uncooperative because people wanted me to go into a definitely wrong direction back then knowledge was limited by both parties (this is the final truth of it back then). On the other side it was the uncooperativeness and dumping of alot code and issues which have been solved back then already with the help of a lot people. I don't bother anymore I found other ways to have everything be possible to coexist in the kernel, and I actually prefer this coexisting solution now which also provides full support and even has a higher backward compatibility than the things which got pushed through back in time. I'd rather prefer to forget about what happened here because it's a full mess caused by several people with limited knowledge years ago and todays position about it is totally different. You can also find patched enduser applications on mcentral.de which can be used with other devices and provide extra features which are required in order to get devices work properly. There's gqradio patched to support lirc and digital audio automatically, same with vlc and tvtime (the last one also having different video output plugins which allow software rendering if xvideo hardware acceleration isn't available. Still one fact till now is that not all devices which have worked in v4l-dvb-experimental back in time are now supported by v4l-dvb on linuxtv.org and nor all the em28xx based devices are yet in the em28xx-new tree, whereas the second one is the result of heavy refactoring and better manufacturer support for some back then reverse engineered components (-which is good that they got replaced in order to raise the signal strength). Markus > 3) The S2API guys are fed up with all the waiting. Maybe there is indeed > no technical reason behind the decision for S2API as I am also wondering > why there is no answer to THE question. But waiting endlessly really is > no solution... > > The situation I see can not be solved by endless discussion, and even if > MCC would switch to multiproto (again), there discussion would continue > endlessly. > > I just see two options to get a fair decision: > 1) Allowing both APIs exist parallel for a short time and see who is the > winner (as mentioned). > 2) Let the community decide (all interested developers and even > end-users like me and Sacha) with some kind of online vote. Communicate > clearly before which "important" developer favours which API. As none of > the API seems to have a real advantage/disadvantage, users like me will > have to vote for both or decide on personal taste ;) > > I favour option 2) as I also don´t like applications that rely on > certain hardware (if only one API is supported). > > With kind regards > > Joerg Knitter > > _______________________________________________ > linux-dvb mailing list > linux-dvb@xxxxxxxxxxx > http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb > _______________________________________________ linux-dvb mailing list linux-dvb@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
