Markus, Go on and ask the distributors to package your userspace stuff! In fact nobody wants patched applications. standardversion shipped with their distros will be prefered. On Do, Sep 25, 2008 at 07:44:29 +0200, Markus Rechberger wrote: > 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 Halim Sahin E-Mail: halim.sahin (at) t-online.de _______________________________________________ linux-dvb mailing list linux-dvb@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
