-----Oorspronkelijk bericht----- Van: lamikr@pilppa.org [mailto:vdr-bounces@linuxtv.org] 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 1.7.0).

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

Regards,

Niels Wagenaar