[linux-dvb] [ANNOUNCE] DVB API improvements End-user point of viwer

Markus Rechberger mrechberger at gmail.com
Thu Sep 25 19:44:29 CEST 2008


On Thu, Sep 25, 2008 at 6:22 PM, Jörg Knitter <joerg.knitter at gmx.de> wrote:
> VDR User wrote:
>> 2008/9/25 Sacha <sacha at hemmail.se>:
>>
>>> 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 at linuxtv.org
> http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
>



More information about the linux-dvb mailing list