> -----Oorspronkelijk bericht-----
> Van: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Namens Mika
> Laitio
> Verzonden: donderdag 25 september 2008 23:03
> Aan: VDR Mailing List
> Onderwerp: Re: [vdr] [v4l-dvb-maintainer] [Wanted] dvb-ttpci maintainer
> > The basic democratic rules should integrate the community
> > and not only two multiproto developers.
> >

Democratic goes a long way and perhaps the democratic process was even't there 
in the past during the development of multiproto. People are now furious that 
during the last meet they announced S2API as the new addition to V4L. People 
are screaming for answers and are screaming that the democratic process wasn't 
there. Even some were telling that Mauro is not fit for the job. 

Sorry, I disagree entirely from an end-user point of view. I currently dislike 
multiproto because it has taken to long to merge it. While people tell us that 
2+ years is not that long, DVB-S2 channels have been available for around 1 
year on Astra 19.2e (my provider has HDTV channels since April 2008 on Astra 
23.5e) and still we don't have an API which is directly available in the 
kernel. I bought my first DVB-S2 card in November 2007 (FloppyDTV-S2) and used 
Windows with DVB Viewer Pro, from that time I watched several DVB-S2 channels 
already (although not much channels were available). 

I've experienced with multiproto and mantis quite a lot and I finally used 
three different DVB-S2 cards to get it working properly (I'm talking from May 
2008) with VDR 1.7.0. First was the S2-3200 which had locking problems, Second 
was the Technisat SkyStar HD2 which was just unstable (system lockups) and last 
I got a Hauppauge WinTV-NOVA-HD-S2.

Guess which one is working properly and very stable, the Hauppauge 
WinTV-NOVA-HD-S2 (written by Steve no less). Short and simple, I spend over € 
300,- on DVB-S2 cards to get a stable configuration with VDR 1.7.0. From an 
end-user opinion, spending this lot of money tells me that Multiproto is not 
stable enough to be merged into v4l and not stable enough for end-users.

> > Any way,  my compromise for this problem is:
> > Manu Abraham and Steven Toth should work on one of the API's
> (together) and then
> > decide which is the better solution for the new upcoming standards!

I don't think that this won't ever happen. The reason that Steve started the 
HVR-4000 SF/MF patches outside multiproto has had a reason (whatever the reason 
is). Then several people had enough and acked a new proposal to compete with 
multiproto. This tells me that certain people don't want anything to do with 
multiproto any more and that they want an alternative which is flexible enough 
for them and which will be allowed to merge sooner into v4l so that we can 
enjoy support for the new DVB techniques. 

> I agree with those who think that kernel/linuxtv should not try to
> maintain both the multiproto and S2API in the long run, that would just
> make a chaos. So only one API (preferrable backward compatible) would
> be
> the best option.

I agree entirely.
> I also like that now there is a big push for getting many drivers back
> to
> single v4l-dvb tree instead of tens of different development trees that
> makes it impossible for distros to compine a working solution for most
> of
> the cards.

Again I agree entirely.

> As a follower of this email list, I however also have small
> concern whether the vote between multiproto and s2api was really fair.
> There were not any discussion from the API calls and structures used
> in different proposals. It did not also help that Mauro who as a
> final decision maker with commit rights to v4l-dvb publicly announced
> over
> one month earlier working for S2API instead of multiproto.
>       http://www.linuxtv.org/pipermail/linux-dvb/2008-
> August/028313.html

You can also see it the other way around. They were fed up with the schedule, 
stability and problems of/with  multiproto and started on an alternative. Maybe 
it's bad that 2 years of development has gone down the drain. But if you look 
at the current status (from an end-user pov), it's not 
usuable/unstable/problematic and I don't think a merge with v4l or the kernel 
would be in order any way. I personally think that multiproto is still too much 
WIP to declared stable or useable (despite the fact that I use it with VDR 

Whether S2API was voted fair or not, people from v4l decided it was time for a 
new direction or a change. The announcement of S2API was something in the 
pipeline (I expected this to happen, I thought it would only be sooner) on 
which they thought it was a way to incorporate new DVB-techniques without the 
'problem' multiproto.

And please, don't talk about that they didn't gave the possibility to let Manu 
get his things in order. Or that he couldn't speak or whatever nonsense. The 
fact that multiproto is this far after two years of development, gives the 
people from v4l a lot of time to check the development progress, feedback and 
get an opinion about multiproto.

> But some decision must be made so that the train can get forward and my
> understanding is that both the S2API and multiproto API can be used for
> that. So in that sense I am happy that the work for getting drivers
> back
> from tens of different development trees back to v4l-trunk has started.

The different development trees for multiproto are scattered around the net. 
Even Klaus complained that multiproto(_plus) wouldn't even compile for him. I 
even don't use the official multiproto repository, I use the liplianindvb 
because I don't have to pull multiproto, patch it with a attachment from the 
linux-dvb list or a website and cross my fingers that it doesn't break (which 
happened quite a lot in the past). 

> The real win-win solution at least for the co-operation point of view
> would be if S2API and Multiproto could somehow be compined for making
> one
> superiour DTV API.

To be honest, I hope they abandon multiproto and focus entirely on S2API and 
start cleanly with the drivers. So personally I don't want to see the merge of 
multiproto with S2API. And I think that my reasons for why, are clear enough. 

> But as there has not been any emails discussing the details of these
> two API's I do not know whether it makes sense from technology point of
> view. (As the technically best API should always win in Linux...)

From an end-user point of view, I don't care which technology is the best. I 
don't want repositories after which you have to patch to fix several problems 
because after months of the availability it's still not implanted. So, I want a 
stable and working API which allows me to watch DVB-S2 channels and I want 
software which supports it. 

Multiproto had his chance for two years now. (Perhaps) the best course is to 
start over and see what S2API brings us in one month. I reckon that most of the 
linux-dvb people will see that despite the process, this is the logical step 
for v4l and new DVB techniques under Linux.

> I hope people could still have some energy for commenting this?

I kept rather quiet for a reason. It's better to read everything after a period 
of time, reflect and then give your opinion.

And my opinion is as a normal user, which has knowledge about Linux, compiling, 
patching, etc. That S2API is the way to go so we can start fresh and clean. 
Because several people told me that the lack of support and progress for new 
DVB techniques is keeping them away from Windows alternatives. And to be 
honest, I can't blame them.   

> Mika


Niels Wagenaar

vdr mailing list

Reply via email to