Re: [vdr] [linux-dvb] [Wanted] dvb-ttpci maintainer
Goga777 wrote: Oliver Endriss wrote: So - if someone wants to take over the dvb-ttpci drivers he should speak up now. The sooner the better. ah, it's very pity :( will you stay with VDR project ? Sure. Oliver -- VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/ ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [v4l-dvb-maintainer] [Wanted] dvb-ttpci maintainer
hermann pitton wrote: Am Mittwoch, den 24.09.2008, 19:22 +0200 schrieb Oliver Endriss: Hi, due to the way S2API was pushed through (I would call it a plot) there is not much motivation left to spend my time with DVB. So - if someone wants to take over the dvb-ttpci drivers he should speak up now. The sooner the better. Oliver, you and Manu still stand for dvb with highest respect from _all_ I know about. And for all I know else, maybe I know nothing, this was for sure not a plot. Except of course a majority of plumbers at the same place at the same time can create/propose some facts. No. They can discuss/propose anything they like, but 8 people don't have any right to make decisions. (This is why I call it a plot.) There are basic democratic rules which must be followed in a community: (1) Make a proposal (2) Discuss the proposal (3) Finally, _after_ the discussion: A poll to find a decision. ... Think it over. Well, I had enough time to think about it... Oliver -- VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/ ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] [Announce] svdrpservice-0.0.4
Hi there, a new release of the svdrpservice-Plugin is available from http://vdr.schmirler.de HISTORY 0.0.4 - Italian translation (thanks to Diego Pierotto) - Commandline parameter for default server IP and port (suggested by [EMAIL PROTECTED]) - Automatic charset conversion (suggested by [EMAIL PROTECTED]) Includes patches for VDR 1.6.1 to make it report its charset in the SVDRP greeting message - Gettext support for VDR 1.5.7+ Credits to Udo Richter for his po218n.pl backward compatibility script - Accept empty responses (status code + space character) - No longer strip trailing whitespace from responses - Configurable timeouts ** What is the svdrpservice-plugin all about? It's a little helper used by a couple of other plugins (e.g. remotetimers and remoteosd) to contact an other VDR using SVDRP. So it doesn't make sense to install svdrpservice as long as no other plugin requires it. ** Some notes on the new charset conversion feature If two connected VDRs are using different charsets (e.g. a VDR 1.6 with UTF-8 and a VDR 1.4 with ISO-8859-15), svdrpservice will do an on-the-fly conversion. However the server must report the charset it uses or otherwise svdrpservice won't convert. Since VDR 1.6.0-2 and 1.7.1 the charset is included in the SVDRP greeting message. In the patches subdirectory of the plugin sources you will find patches for older VDRs (affects only a single line). Note that you don't need to patch the client VDR (i.e. the one running svdrpservice). Let me give you an example: - Server VDR running 1.6.0-2, client VDR running 1.4.7: You're all fine. No patch required - Server VDR running 1.4.7, client VDR running 1.6.0-2: You need to patch the server VDR here ** What bugs will be fixed by svdrpservice-0.0.4 - A remoteosd connection aborted whenever a menu with empty title was opened (e.g. extrecmenu plugin) - The name of a recording as returned by the SVDRP command LSTR may end with a space character. Previous svdrservice versions stripped that off. Some features of remotetimers 0.1.0 (not released yet) will fail on these recordings if an old svdrpservice version is running. Enjoy, Frank ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [v4l-dvb-maintainer] [Wanted] dvb-ttpci maintainer
Hi, On Do, Sep 25, 2008 at 12:54:58 +0200, Oliver Endriss wrote: There are basic democratic rules which must be followed in a community: (1) Make a proposal Yes We have multiproto, since 2006. (2) Discuss the proposal Was done since 2006 (3) Finally, _after_ the discussion: A poll to find a decision. Great thing. Why was multiproto not merged after your code review november 2007 I thing Manu wanted to do the s2 stuff himself and did not accept any community help. Yes I read most of the old mails from last year. In most cases Manu wrote that multiproto is not ready. The fact is, that many people are using (not ready multiproto stuff) since two years. The basic democratic rules should integrate the community and not only two multiproto developers. 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! The current situation is not acceptable for endusers / other developers Please don't stop your great work on ttpci Oliver. Regards Halim ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [linux-dvb] [v4l-dvb-maintainer] [Wanted] dvb-ttpci maintainer
Halim Sahin wrote: Hi, On Do, Sep 25, 2008 at 12:54:58 +0200, Oliver Endriss wrote: There are basic democratic rules which must be followed in a community: (1) Make a proposal Yes We have multiproto, since 2006. (2) Discuss the proposal Was done since 2006 (3) Finally, _after_ the discussion: A poll to find a decision. Great thing. Why was multiproto not merged after your code review november 2007 I thing Manu wanted to do the s2 stuff himself and did not accept any community help. http://lwn.net/Articles/297301/ API and core related patches: 31 + 1 patches, total 32 in all. http://www.kernel.org/pub/linux/kernel/people/manu/dvb_patches/ The people who contributed some way or the other (in the final stages): on the API changes alone. (Not mentioning about the people who initially provided many comments.) Marco Schluessler [EMAIL PROTECTED] Arvo Jarve [EMAIL PROTECTED] Reinhard Nissl [EMAIL PROTECTED] Oliver Endriss [EMAIL PROTECTED] Anssi Hannula [EMAIL PROTECTED] These folks on a whole, contributed to ~14 of the patches. Yes I read most of the old mails from last year. In most cases Manu wrote that multiproto is not ready. The fact is, that many people are using (not ready multiproto stuff) since two years. After the code review, it was left for testing. Thanks to the VDR community/Klaus for providing support for the same, so it could be tested in real life. As you can see quite some of the changes came during the test phase, as you can see from the timestamps in the multiproto tree. Regards, Manu ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [v4l-dvb-maintainer] [Wanted] dvb-ttpci maintainer
The basic democratic rules should integrate the community and not only two multiproto developers. 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 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 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. 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 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 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. 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...) I hope people could still have some energy for commenting this? Mika ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [v4l-dvb-maintainer] [Wanted] dvb-ttpci maintainer
-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 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
Re: [vdr] [v4l-dvb-maintainer] [Wanted] dvb-ttpci maintainer
Hi, On Fri, 26 Sep 2008, Niels Wagenaar wrote: [..] Maybe it's bad that 2 years of development has gone down the drain. [..] (talking about mutliproto) Only a small part of all multiproto changes will go down the drain: The drivers written especially for multiproto can and will be converted and merged. The same will happen with the dvb-driver-core changes. Preferable by Manu, as he knows those drivers and their hardware best. S2API (DVBv5) mainly adds features to the user-interface (include/linux/frontend.h) along with some necessary changes in the dvb-driver-core. The latter are relatively small and not incompatible with the needs of multiproto's internal changes. The dvb-driver-core mechanisms can be changed at any time - whereas the user-interface cannot. Patrick. -- Mail: [EMAIL PROTECTED] WWW: http://www.wi-bw.tfh-wildau.de/~pboettch/ ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
