Re: [vdr] VDR Development
Klaus Schmidinger wrote: On 09/07/08 19:42, Clemens Kirchgatterer wrote: ... i always wondered why dvb support was directly compiled in while other back and frontends were supposed to be plugins. this clearly leaves a sign that dvb is the preferd plattform. Well, it was the first one - long before there even was a plugin interface. Maybe this is worth another thought: In times of DVBAPI, Multiproto and S2API, a separated DVB plugin could easily be split into three flavors. And a core VDR that is no longer dependent on Linux kernel interfaces would be a lot more portable too. Cheers, Udo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR Development
Laz [EMAIL PROTECTED] wrote: I have always been impressed with the quality of the source code for vdr. It's the first proper C++ application I've had course to look through in any detail (many, many years of pure C behind me, though!) and I've pretty much learned all of the C++ I know from Klaus's well-laid out source code! i, by no means, want to question klaus' competence as a coder, but to call VDR proper C++ sounds really strange to me. i can accept the source formatting as being a thing of personal taste, maybe even hungarian notation, something i personally find unbearable and wrong from the ground up, but the refusal to use the STL in a C++ project leaves me dumbfounded. i CAN absolutly understand why klaus codes VDR as he does. writing a string class or a linked list is fun sometimes and as long as VDR stays a one man show it is only up to him to decide. keeping the closed development process makes things much easier for him and avoids long arguments about personal preferences. if i had an GPL project that size, i would probably do the same. do i like the way VDR is developed? hell, no! nevertheless it is, what it is. a very usable and stable program for watching, recording and replaying TV shows with a dvb card. If a new feature is needed, a lot can be achieved with plugins, or create a patch and forward on to Klaus and the list. maintaining patches over multiple revisions in a coding style that is orthogonal to your own, waiting for it to get eventually merged upstream some day, is not something many peaople like. just my 2 cents ... clemens ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR Development
Lauri Tischler [EMAIL PROTECTED] wrote: Switching to MythTV is *not* a solution to anything. MythTV is slow huge, kitchen sink where nothing really works. maybe s/MythTV/XBMC/g ? ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR Development (Number of users)
Hi On 09/05/08 18:38, VDR User wrote: ... Seeing how many people have already left VDR, it's already happening! :( I have no idea how many people actually use VDR, but you apparently have some solid numbers on how many people dropped VDR. Do you mind sharing these numbers? I do not have exact numbers but a rough guess would tell me that about 5-10 K people are using Gen2VDR. And thats surely not the main VDR Distribution ;) -- Helmut Auer, [EMAIL PROTECTED] ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR Development (Number of users)
Original-Nachricht Datum: Sun, 07 Sep 2008 13:31:22 +0200 Von: Helmut Auer [EMAIL PROTECTED] An: VDR Mailing List vdr@linuxtv.org Betreff: Re: [vdr] VDR Development (Number of users) Hi On 09/05/08 18:38, VDR User wrote: ... Seeing how many people have already left VDR, it's already happening! :( I have no idea how many people actually use VDR, but you apparently have some solid numbers on how many people dropped VDR. Do you mind sharing these numbers? I do not have exact numbers but a rough guess would tell me that about 5-10 K people are using Gen2VDR. And thats surely not the main VDR Distribution ;) How did you calculate that number? -- Release early, release often. Ist Ihr Browser Vista-kompatibel? Jetzt die neuesten Browser-Versionen downloaden: http://www.gmx.net/de/go/browser ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR Development (Number of users)
Hi Hans How did you calculate that number? By counting the downloads of fixes (which are only made once with the internal update script). And I guess that some users will never update a running system ... -- Helmut Auer, [EMAIL PROTECTED] ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR Development
Glad to see some discussion taking place here.. It's quite funny some people think hdtv, h264, and other standard or quickly-becoming-standard things are bleeding edge. You've got to be kidding! Also, to put it simply, it's ignorant to think there's nothing wrong. When many VDR users are abandoning the software for other more capable options, why do you think that is? Because it lacks support for -current needs-, and for that matter lacks support for even some of the most basic stuff! You can bash MythTV all you want but it doesn't change the fact that people are leaving VDR in favor of it. I agree that MythTV is big, poorly designed in some respects, and generally a pain to get running...but that obviously isn't stopping people. Stability is a great thing to have, but so is support for basic needs. And where is the rule that says you can't have both? Just like code is improved, so can the processes which generate the code and bring it together. It seems like some are taking this discussion as an attack on Klaus and that is NOT the case. It's absurd this has to be pointed out -again- but the intentions are only to improve VDR's development, features (even some of the most basic), and ensure that VDR will not become obsolete because it isn't keeping pace with the rest of the world. Ignoring basic needs simply because they don't apply to you isn't exactly the picture of great design or development now is it? The 'as long as it works here, everyone else can stay in the cold' attitude has never resulted in anything positive. Nobody should ever say sorry for the idea of taking a good product and making it better! ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR Development
FULLACK Oliver, You have forgotten the point: * help to add dvb-s2 support into main kernel!! Danke Gruß Halim On So, Sep 07, 2008 at 05:08:37 +0200, Oliver Endriss wrote: Guys, I can't stand this blabla any longer. Klaus stated clearly how he wants to do VDR development, and he has the right to do it his way! No matter whether you like it or not! My suggestion for those who are unhappy with the current situation: 0. Stop this discussion. 1. Read the GPL. 2. Understand the GPL. 2. Clone the existing VDR code. 3. Give it a new name to make clear, that it is not VDR. 4. Make it better (if you can). 5. Last but not least: Maintain it for 8 years or longer. 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 -- Halim Sahin E-Mail: halim.sahin (at) t-online.de ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR Development
Just a couple of observations on this discussion.. I see that some advocates of VDR repository are calling Myth project 'bloated','kitchen sink', 'not alternative to VDR'…, but, at the same time, they are pushing VDR project the same way, which will virtually transform VDR into sort of Myth-2, because the most important advantages of VDR can persist only as long as Klaus has fun, hence motivation to continue development of his great project. And he clearly stated that collective development way is not appropriate to his own development style and his view on how VDR project should be managed. Well ok, we all expect open source development to be driven by personal need, but it is the combination of code created by many people who each had their own needs which is where the magic lies. Again, why do we need Myth-2 if we already have Myth-1 incorporating all the mentioned magic.. A well maintained bazaar-style project is generally thought to produce much higher quality code. Look at the Linux kernel and compare it to any other operating system. Linux kernel development is a good example of the fact that greatness of a project is dependant in the first place on the person who leads the project. Importance of the chosen tool (community tree, or something else) is in the second place. Collective development via repository, or single coder ruling - this is just a tool that the project leaders have fun and convenience to use for their projects. A lot of projects use community tree as their tool of development, but it doesn’t necessarily guarantee to them so high level of appreciation that Linux kernel has, for example.. _ Invite your mail contacts to join your friends list with Windows Live Spaces. It's easy! http://spaces.live.com/spacesapi.aspx?wx_action=createwx_url=/friends.aspxmkt=en-us___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR Development
Oliver Endriss [EMAIL PROTECTED] wrote: Guys, I can't stand this blabla any longer. why do you read the blabla then and even bother feeding the thread? please be so tolerant and let people discuss VDR related topics on the vdr mailing list. thank you. Klaus stated clearly how he wants to do VDR development, and he has the right to do it his way! No matter whether you like it or not! so what? My suggestion for those who are unhappy with the current situation: 0. Stop this discussion. 1. Read the GPL. 2. Understand the GPL. 2. Clone the existing VDR code. 3. Give it a new name to make clear, that it is not VDR. 4. Make it better (if you can). 5. Last but not least: Maintain it for 8 years or longer. thank you for aducating us in forking a GPL project. SCNR ... clemens ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR Development
On Sun, Sep 07, 2008 at 05:46:01PM +0200, Halim Sahin wrote: FULLACK Oliver, You have forgotten the point: * help to add dvb-s2 support into main kernel!! Which one? SCNR :-) I also don't think that a vdr-repository would help in the development speed. Either the whole development procedure needs to be changed (more maintainer with KLS's approval) or it has no advantage compared to the .tgz-distribution. But I think the repository stuff is only marginal. The design itself matters. When looking at the experiences at Reel, there are some things to be considered in the (far) future of vdr 2.0: - vdr has grown/evolved since 2000, but is still based in its design on the FF card and its capabilities. There are now different signal source setups (LNBs, rotor, multiproto, mixed tuners or shared tuners/CAMs like in the NetCeiver, and not forgetting the IPTV variants), various output types and devices (FF, DXR3, HDE, X11, ...) and especially more expectations what a PC-based STB should be able to do (playback of other media, home automatisation, etc.). - It allows no real server/client distinction. It is quite common to have a real file server somewhere in the house, but it's hard to get a vdr running on it and viewing on other clients. Even the recordings sharing of two vdrs is not that easy (touch update here and there...). One of the main advantages of Unix was resource sharing and distribution in heterogenous networks (like X over network), but vdr is currently focused only on its platform. - The current plugin concept allows only a very limited access or modfications in the core behaviour. At least without core patches... - Based on the long evolution history, vdr IMO also has some design problems. Every object interacts with each other, I'm personally lost in the inheritance-graph of dozens of identically named Get/Put/Add/Del/Action/Process-calls. Also the main loop (almost 1500LOC) is a bit fat ;-) This makes it hard for newcomers and potential contributors. I guess that there are only very few people that actually know what is going on in the device/devbdevice/remux/libsi-core. I still favour vdr over mythTV or MCE, because their neglect the TV side. But we have to face it: Radio is dying already. Old fashioned TV over antenna is also getting more and more unimportant and is merged with other data sources (IPTV, internet radio, podcasts, ...). Full convergence is no if, it's a when. So, the main discussion topic should be: What is needed for a future-proof design? It is not about XML or SQL or other hype buzzwords, it's about the overall design and how individual modules/plugins interact with each other. Just my EUR0.01... -- Georg Acher, [EMAIL PROTECTED] http://www.lrr.in.tum.de/~acher Oh no, not again ! The bowl of petunias ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR Development
On Sun, Sep 7, 2008 at 8:08 AM, Oliver Endriss [EMAIL PROTECTED] wrote: Guys, I can't stand this blabla any longer. Then don't read this thread. Klaus stated clearly how he wants to do VDR development, and he has the right to do it his way! No matter whether you like it or not! What's your point? At one point he also said he didn't intend to support HDTV because he doesn't use it, as well as said he had no intention to move away from mpeg-pes. Thanks to the discussions input on this mailing list by the users, he has changed his mind. My suggestion for those who are unhappy with the current situation: 0. Stop this discussion. I will NEVER suggest to prohibit or censor discussion, especially at a place where open discussion should be promoted. We all have the right to our opinions and I see no crime in voicing them. Judging by the number of responses, many people have strong opinions on the subject regardless of which side of the fence they stand on, and I'm glad to read them all. Your idea that we should just shut up and if we don't like it, then make a fork, maintain it for 8 years bla bla bla, is a bit childish at best. Sorry, but nobody here needs your permission or approval to discuss VDR related topics on the VDR mailing list. Again, my suggestion is to do what I do Don't read threads that don't interest me. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR Development
Hi, On So, Sep 07, 2008 at 06:44:46 +0200, Georg Acher wrote: On Sun, Sep 07, 2008 at 05:46:01PM +0200, Halim Sahin wrote: FULLACK Oliver, You have forgotten the point: * help to add dvb-s2 support into main kernel!! Which one? I don't know. But I have forgotten another important point: Help to develope an fullfeatured, h264 capable card, or hw accelerated video driver for radeon/nvidia/intel cards. (greener VDR?) Nice stuff h264, HDTV. We need hdtv capable hardware!!! regards Halim ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR Development
Georg Acher [EMAIL PROTECTED] wrote: I also don't think that a vdr-repository would help in the development speed. Either the whole development procedure needs to be changed (more maintainer with KLS's approval) or it has no advantage compared to the .tgz-distribution. maybe using git, where you can pull into your own repository for privat vdr hacking and let other people check it out may be worth a thought. But I think the repository stuff is only marginal. The design itself matters. When looking at the experiences at Reel, there are some things to be considered in the (far) future of vdr 2.0: full ack. - vdr has grown/evolved since 2000, but is still based in its design on the FF card and its capabilities. There are now different signal source setups (LNBs, rotor, multiproto, mixed tuners or shared tuners/CAMs like in the NetCeiver, and not forgetting the IPTV variants), various output types and devices (FF, DXR3, HDE, X11, ...) and especially more expectations what a PC-based STB should be able to do (playback of other media, home automatisation, etc.). i always wondered why dvb support was directly compiled in while other back and frontends were supposed to be plugins. this clearly leaves a sign that dvb is the preferd plattform. - It allows no real server/client distinction. It is quite common to have a real file server somewhere in the house, but it's hard to get a vdr running on it and viewing on other clients. Even the recordings sharing of two vdrs is not that easy (touch update here and there...). One of the main advantages of Unix was resource sharing and distribution in heterogenous networks (like X over network), but vdr is currently focused only on its platform. for me the biggest obstacle so far in many years of vdr usage. i have already layed down CAT5 into the living room, why do i still have to connect directly to the satelite dish to get flawless live viewing? - Based on the long evolution history, vdr IMO also has some design problems. Every object interacts with each other, I'm personally lost in the inheritance-graph of dozens of identically named Get/Put/Add/Del/Action/Process-calls. Also the main loop (almost 1500LOC) is a bit fat ;-) This makes it hard for newcomers and potential contributors. I guess that there are only very few people that actually know what is going on in the device/devbdevice/remux/libsi-core. not only that, but also are many standard containers reimplemented in the core source that increase LOC count for no good, at least i can't see it. I still favour vdr over mythTV or MCE, because their neglect the TV side. But we have to face it: Radio is dying already. Old fashioned TV over antenna is also getting more and more unimportant and is merged with other data sources (IPTV, internet radio, podcasts, ...). Full convergence is no if, it's a when. yes, there is currently no better software for watching, recording and replaying TV if one uses vdr with a FF card. best regards ... clemens ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR Development
VDR does need some of its core functionality upgraded - for example something like the Reel channel scan is badly missing, you should be able to easily scan for transponders from within VDR, just like most satellite receivers. +1 Hmmm. My VDR automatically updates its channel list by itself, and adds all channels and transponders I ever needed. (which is far from what other receivers I know do.) The only thing I miss is a built-in way to get rid of channels that are gone. (I do have my own solution though.) ah, you are watching the Astra 19.2 E , yes ? Astra has corrected service tables (nit, sdt,...) due to this vdr can update and add new channels. Please, try to delete your channels.conf and start to scan Astra with reelchannelscan, Will you find dvb-s2 channels ?? Goga ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR Development
With regards to dvb cards that include mpeg4 hardware decoders... There aren't many even in development and the ones that do actually (if they do) make it to production will be very expensive. At the cost of the card you can build a pc capable of the same and a lot more for your money. In conversations I've had with dvb devs, the demand for such a card just isn't big enough to bring the price down to something the average user will pay. For this reason I don't think it's wise to continue treating VDR in a way that assumes most users dusted off the old piece of crap pc in their closet and put a full-featured card in it. There is no way to ignore the fact that home entertainment is moving to htpc-based setups, especially now that hardware is cheap enough that you can build a powerful pc for little expense. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR Development
On Sun, Sep 07, 2008 at 07:21:04PM +0200, Halim Sahin wrote: * help to add dvb-s2 support into main kernel!! Which one? I don't know. :-) I guess nobody does... But I have forgotten another important point: Help to develope an fullfeatured, h264 capable card, or hw accelerated Been there, done that already :-) The HDE from Reel decodes h264, I wrote a lot of the driver stuff for it. So there is (at least one) h264-decoder card, and btw, vdr is the main platform for the HDE. video driver for radeon/nvidia/intel cards. There are rumours that Ati is planning such drivers... In the long term special decoder cards will vanish, but I think it will still take some time. -- Georg Acher, [EMAIL PROTECTED] http://www.lrr.in.tum.de/~acher Oh no, not again ! The bowl of petunias ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR Development
Georg Acher wrote: I also don't think that a vdr-repository would help in the development speed. Either the whole development procedure needs to be changed (more maintainer with KLS's approval) or it has no advantage compared to the .tgz-distribution. But I think the repository stuff is only marginal. The design itself matters. When looking at the experiences at Reel, there are some things to be considered in the (far) future of vdr 2.0: - vdr has grown/evolved since 2000, but is still based in its design on the FF card and its capabilities. There are now different signal source setups (LNBs, rotor, multiproto, mixed tuners or shared tuners/CAMs like in the NetCeiver, and not forgetting the IPTV variants), various output types and devices (FF, DXR3, HDE, X11, ...) and especially more expectations what a PC-based STB should be able to do (playback of other media, home automatisation, etc.). - It allows no real server/client distinction. It is quite common to have a real file server somewhere in the house, but it's hard to get a vdr running on it and viewing on other clients. Even the recordings sharing of two vdrs is not that easy (touch update here and there...). One of the main advantages of Unix was resource sharing and distribution in heterogenous networks (like X over network), but vdr is currently focused only on its platform. - The current plugin concept allows only a very limited access or modfications in the core behaviour. At least without core patches... - Based on the long evolution history, vdr IMO also has some design problems. Every object interacts with each other, I'm personally lost in the inheritance-graph of dozens of identically named Get/Put/Add/Del/Action/Process-calls. Also the main loop (almost 1500LOC) is a bit fat ;-) This makes it hard for newcomers and potential contributors. I guess that there are only very few people that actually know what is going on in the device/devbdevice/remux/libsi-core. I still favour vdr over mythTV or MCE, because their neglect the TV side. But we have to face it: Radio is dying already. Old fashioned TV over antenna is also getting more and more unimportant and is merged with other data sources (IPTV, internet radio, podcasts, ...). Full convergence is no if, it's a when. So, the main discussion topic should be: What is needed for a future-proof design? It is not about XML or SQL or other hype buzzwords, it's about the overall design and how individual modules/plugins interact with each other. Just my EUR0.01... Indeed this would be a very interesting discussion. CU 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] VDR Development
Hello, On So, Sep 07, 2008 at 08:25:56 +0200, Georg Acher wrote: Been there, done that already :-) The HDE from Reel decodes h264, I wrote a lot of the driver stuff for it. So there is (at least one) h264-decoder card, and btw, vdr is the main platform for the HDE. Yes right that might be an option for short time. Micronas stopped the support of the used chips I think. How many boards can be equipped with the available chips How many boards are available for vdr users? I like to have a more general solution! Regards Halim ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR Development
On 09/07/08 19:42, Clemens Kirchgatterer wrote: ... i always wondered why dvb support was directly compiled in while other back and frontends were supposed to be plugins. this clearly leaves a sign that dvb is the preferd plattform. Well, it was the first one - long before there even was a plugin interface. Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR Development
Il giorno sab, 06/09/2008 alle 02.58 +0200, [EMAIL PROTECTED] ha scritto: but vdr has not evolved for years ! no real new features, it's still meant to be used with one ff dvb-s card. there's a plugin interface but most of the time you don't want to hear about bugs when somebody is using a plugin. what's the point then ? And, what about this blackmail thing ? Wouldn't it be simpler to say i don't have time anymore, my needs won't evolve and i don't want to code features i won't use, please carry on ! ? I'm neither Klaus not a regular of this list, but I think you're not being fair here: Klaus has every right to say he won't develop on a community tree; it is, after all, his own free time. BTW, if I remember well, Klaus has coded several features (i.e. subtitles) he himself said he didn't use. Like it or not, VDR is a cathedral-style project: this has led to higher code quality and very good stability, at the expense of a slower development pace and the lack of some bleeding-edge features in the mainline. If you want those features, you can use a patch posted on this list (e.g. for hdtv, sourcecaps) or use a plugin (e.g. for teletext subtitles). Many distributions include those patches or provide a way for the user to easily appy them. Of course, you're also free to develop your own patches for new features: if they're good enough, I'm sure they'll eventually find their way into the mainline, as it happened, e.g., with the shutdown handling rewrite some time ago. You say you want to fork it: what would you accomplish with that? It's not as if the code would magically write itself. I've yet to see a single prospective developer say if it were forked I'd write X. (And, BTW, there's nothing forbidding him to write X in form of a patch and post it on this list.) On the other hand, by forking you'd probably lose Klaus, who has written by himself the majority of VDR code and knows it like no one else. Finally, I personally fail to see why people switching to MythTV is a bad thing; VDR is not a religion, I think everyone should use whichever software he thinks suits best his needs. I'm very happy with VDR and won't be switching anytime soon. Davide ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR Development
Davide Cavalca wrote: ... I'm neither Klaus not a regular of this list, but I think you're not being fair here: Klaus has every right to say he won't develop on a community tree; it is, after all, his own free time. BTW, if I remember well, Klaus has coded several features (i.e. subtitles) he himself said he didn't use. Like it or not, VDR is a cathedral-style project: this has led to higher code quality and very good stability, at the expense of a slower development pace and the lack of some bleeding-edge features in the mainline. If you want those features, you can use a patch posted on this list (e.g. for hdtv, sourcecaps) or use a plugin (e.g. for teletext subtitles). Many distributions include those patches or provide a way for the user to easily appy them. Of course, you're also free to develop your own patches for new features: if they're good enough, I'm sure they'll eventually find their way into the mainline, as it happened, e.g., with the shutdown handling rewrite some time ago. You say you want to fork it: what would you accomplish with that? It's not as if the code would magically write itself. I've yet to see a single prospective developer say if it were forked I'd write X. (And, BTW, there's nothing forbidding him to write X in form of a patch and post it on this list.) On the other hand, by forking you'd probably lose Klaus, who has written by himself the majority of VDR code and knows it like no one else. Finally, I personally fail to see why people switching to MythTV is a bad thing; VDR is not a religion, I think everyone should use whichever software he thinks suits best his needs. I'm very happy with VDR and won't be switching anytime soon. Davide, I have been following VDR development since June 2000 and I have been subscribed to this list since January 2002. I could not have put it better than you did above. I totally agree with everything you said. Carsten. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR Development
On Saturday 06 of September 2008, Davide Cavalca wrote: Il giorno sab, 06/09/2008 alle 02.58 +0200, [EMAIL PROTECTED] ha scritto: but vdr has not evolved for years ! no real new features, it's still meant to be used with one ff dvb-s card. there's a plugin interface but most of the time you don't want to hear about bugs when somebody is using a plugin. what's the point then ? And, what about this blackmail thing ? Wouldn't it be simpler to say i don't have time anymore, my needs won't evolve and i don't want to code features i won't use, please carry on ! ? I'm neither Klaus not a regular of this list, but I think you're not being fair here: Klaus has every right to say he won't develop on a community tree; it is, after all, his own free time. BTW, if I remember well, Klaus has coded several features (i.e. subtitles) he himself said he didn't use. Like it or not, VDR is a cathedral-style project: this has led to higher code quality and very good stability, at the expense of a slower development pace and the lack of some bleeding-edge features in the mainline. If you want those features, you can use a patch posted on this list (e.g. for hdtv, sourcecaps) or use a plugin (e.g. for teletext subtitles). Many distributions include those patches or provide a way for the user to easily appy them. Of course, you're also free to develop your own patches for new features: if they're good enough, I'm sure they'll eventually find their way into the mainline, as it happened, e.g., with the shutdown handling rewrite some time ago. You say you want to fork it: what would you accomplish with that? It's not as if the code would magically write itself. I've yet to see a single prospective developer say if it were forked I'd write X. (And, BTW, there's nothing forbidding him to write X in form of a patch and post it on this list.) On the other hand, by forking you'd probably lose Klaus, who has written by himself the majority of VDR code and knows it like no one else. Finally, I personally fail to see why people switching to MythTV is a bad thing; VDR is not a religion, I think everyone should use whichever software he thinks suits best his needs. I'm very happy with VDR and won't be switching anytime soon. I wanted to tell my opinion to this list too, but I 100% agree with you Davide and I think I'm not able to tell it better way. BR, Ales ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR Development
Thanks for the words of understanding several people have posted here. I'm pretty amazed myself how fast time went by this summer, and how little time I had to work on VDR. I do have a version 1.7.1 sitting here that's almost ready, but there are some things I'd still like to go into it. I'll do my best to come up with a reasonable version this weekend. Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR Development
FULLACK Carstenand Davide, On Sa, Sep 06, 2008 at 10:45:54 +0200, Carsten Koch wrote: Davide Cavalca wrote: ... I'm neither Klaus not a regular of this list, but I think you're not being fair here: Klaus has every right to say he won't develop on a community tree; it is, after all, his own free time. BTW, if I remember well, Klaus has coded several features (i.e. subtitles) he himself said he didn't use. Like it or not, VDR is a cathedral-style project: this has led to higher code quality and very good stability, at the expense of a slower development pace and the lack of some bleeding-edge features in the mainline. If you want those features, you can use a patch posted on this list (e.g. for hdtv, sourcecaps) or use a plugin (e.g. for teletext subtitles). Many distributions include those patches or provide a way for the user to easily appy them. Of course, you're also free to develop your own patches for new features: if they're good enough, I'm sure they'll eventually find their way into the mainline, as it happened, e.g., with the shutdown handling rewrite some time ago. You say you want to fork it: what would you accomplish with that? It's not as if the code would magically write itself. I've yet to see a single prospective developer say if it were forked I'd write X. (And, BTW, there's nothing forbidding him to write X in form of a patch and post it on this list.) On the other hand, by forking you'd probably lose Klaus, who has written by himself the majority of VDR code and knows it like no one else. Finally, I personally fail to see why people switching to MythTV is a bad thing; VDR is not a religion, I think everyone should use whichever software he thinks suits best his needs. I'm very happy with VDR and won't be switching anytime soon. Davide, I have been following VDR development since June 2000 and I have been subscribed to this list since January 2002. I could not have put it better than you did above. I totally agree with everything you said. Carsten. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr Halim Sahin E-Mail: halim.sahin (at) t-online.de ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR Development
Davide Cavalca wrote: Il giorno sab, 06/09/2008 alle 02.58 +0200, [EMAIL PROTECTED] ha scritto: but vdr has not evolved for years ! no real new features, it's still meant to be used with one ff dvb-s card. there's a plugin interface but most of the time you don't want to hear about bugs when somebody is using a plugin. what's the point then ? And, what about this blackmail thing ? Wouldn't it be simpler to say i don't have time anymore, my needs won't evolve and i don't want to code features i won't use, please carry on ! ? I'm neither Klaus not a regular of this list, but I think you're not being fair here: Klaus has every right to say he won't develop on a community tree; it is, after all, his own free time. BTW, if I remember well, Klaus has coded several features (i.e. subtitles) he himself said he didn't use. Like it or not, VDR is a cathedral-style project: this has led to higher code quality and very good stability, at the expense of a slower development pace and the lack of some bleeding-edge features in the mainline. If you want those features, you can use a patch posted on this list (e.g. for hdtv, sourcecaps) or use a plugin (e.g. for teletext subtitles). Many distributions include those patches or provide a way for the user to easily appy them. Of course, you're also free to develop your own patches for new features: if they're good enough, I'm sure they'll eventually find their way into the mainline, as it happened, e.g., with the shutdown handling rewrite some time ago. You say you want to fork it: what would you accomplish with that? It's not as if the code would magically write itself. I've yet to see a single prospective developer say if it were forked I'd write X. (And, BTW, there's nothing forbidding him to write X in form of a patch and post it on this list.) On the other hand, by forking you'd probably lose Klaus, who has written by himself the majority of VDR code and knows it like no one else. Finally, I personally fail to see why people switching to MythTV is a bad thing; VDR is not a religion, I think everyone should use whichever software he thinks suits best his needs. I'm very happy with VDR and won't be switching anytime soon. Davide ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr Couldn't have said it better. Spot on. I think the majority of long-time users like myself feels exactly the same way. Years ago I tried both Myth and VDR and the choice of VDR was easy for me then. If it would have been today maybe it would have a different outcome but so what? To have to choose between to good thing is't that bad, is it? I have helped at least 20 (mostly non-linux users) people set up their own VDR-boxes and everybody loves it. /Magnus Hörlin ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR Development
VDR User wrote: What ever happened to the idea of setting up VDR deveopment on mercurial to allow the main contributors who want to work on it to do so without hassle/delay? My 2c on this: Lets think this through: An open VDR repository for everyone to get in their personal 'I want this' patches. Surely this will lead to chaos, since no one really oversees the needs of all VDR users. (Take sourcecaps vs. lnbsharing as example.) So we have to restrict things. Only a few trusted dev's getting write access. In any case changes that go beyond simple bug fixing would require discussions about whether things go into the right direction, and I'm pretty sure that none of the trusted dev's would ever check in any changes without a previous ack by Klaus anyway. So if Klaus ack's anything anyway, why does anyone except Klaus actually need write access? There are however some pro's for a public repository: - With a public repository, the need for frequent developer releases wouldn't be that high, as people who really want the latest greatest could pull it at any time. Dev releases could be done less frequent at more stable points. - Bug fixes can be pushed between point releases more easily. (There are bug fix patches that are waiting for 1.6.0-2 or 1.7.1 for some time now.) - With a distributed repository system like Mercurical, it would also easily be possible to do external user branches to support more cutting-edge features, as long as some other maintainer keeps them up to date. Think of it as something like the -mm kernels, or as the bigpatch / extensions-patch. And if things get Klaus' approval, they can be easily merged back into main VDR too. To sum up things: A public repository may be useful, but probably in a different way than some people think. Cheers, Udo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR Development
On Saturday 06 September 2008 11:34:30 kafifi wrote: FULLACK Carsten and Davide. Klaus, Thanks a lot for your great job. Good news to hear that development will restart soon ;-) Ditto on all the above! I have been using vdr full time since about 2002. It suits my needs as a set-top-box rather than an all-singing all-dancing media-centre application (if need be, I can use plugins such as softplay or mplayer for playing back avis, etc. but that very rarely happens!). I have toyed with mythtv at times and it was a nightmare to set up and it only had very flakey DVB support at the time. I have always been impressed with the quality of the source code for vdr. It's the first proper C++ application I've had course to look through in any detail (many, many years of pure C behind me, though!) and I've pretty much learned all of the C++ I know from Klaus's well-laid out source code! :-) Many projects I've used over the years which I've built from CVS source are often broken spectacularly. By contrast, Klaus's development versions are usually pretty rock-solid. Any bugs can be quickly ironed out because Klaus knows _all_ that has been changed without having to backtrack through revision logs including changes from various coding styles! If a new feature is needed, a lot can be achieved with plugins, or create a patch and forward on to Klaus and the list. I'm sure Klaus takes on board all suggestions and - seeing as it is a hobby - will get to stuff eventually. I will not be leaving vdr any time soon! :-) Cheers, Laz ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR Development
Davide Cavalca wrote: You say you want to fork it: what would you accomplish with that? It's not as if the code would magically write itself. I've yet to see a single prospective developer say if it were forked I'd write X. (And, BTW, there's nothing forbidding him to write X in form of a patch and post it on this list.) On the other hand, by forking you'd probably lose Klaus, who has written by himself the majority of VDR code and knows it like no one else. btw. there is a vdr fork repository (svn://reelbox.org) reel-multimadia has its own 1.4.7 dvb-s2, h.264 capable vdr they (Georg Acher?) wrote there own extension för dvb-s2 and they extended vdr to there needs it could be interesting to hear of the experience they have made (backports, using vdr 1.7.x in the future?) ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR Development
[EMAIL PROTECTED] wrote: but vdr has not evolved for years ! maybe because it was bleeding edge as it started, it only used the (european) digital dvb standard since then the whole tv marked developed to dvb-s/-c/-t (in europe) an even now with dvb-s2 and h.264, vdr is fit enough to get a patch to support that (there not that many free hdtv sources), there is a iptv plugin too did you ever used one of the first vdr´s ? the development is constant and only because there is no fancy website, boasting about all the stuff, does not mean there isn't development (link layer protocol, plugins, ...) no real new features, it's still meant to be used with one ff dvb-s card. no thats simply wrong, it started with the dxr3-plugin and at the moment there are soft plugins (mpeg2/h.264) for decoding and there is a new hardware solution too with a plugin (eHD) you can even use vdr headless just with a bunch of budget cards or VIDEGOR (http://i30www.ira.uka.de/p2p/videgor/index.en.html) there's a plugin interface but most of the time you don't want to hear about bugs when somebody is using a plugin. what's the point then ? because klaus does program vdr not plugins, they can mean trouble for the vdr-core functions (and patches are more dangerous), thats the reason people are alway asked to try it with vanilla vdr without plugins And, what about this blackmail thing ? Wouldn't it be simpler to say i don't have time anymore, my needs won't evolve and i don't want to code features i won't use, please carry on ! ? why is a clear statemant from someone hwo started development for its own purpose and tells (all the time) that it is still the same blackmail? (btw. klaus has done a lot of development for things he never saw as really useful for himself i.e. utf8 or subtitles) imho: i would´nt trust someone who develops vdr for so long in its spare time - may be he develops vdr for its own or will write code for another project or idea (software that controls the whole house with natural spoken words or something other useful) - but i don't think he will stop coding ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR Development
Enough people have unthinkingly ackd Davide's message. It deserves some serious criticism. I'm neither Klaus not a regular of this list, If you say so. but I think you're not being fair here: Klaus has every right to say he won't develop on a community tree; it is, after all, his own free time. BTW, if I remember well, Klaus has coded several features (i.e. subtitles) he himself said he didn't use. Several. Is that all? Well ok, we all expect open source development to be driven by personal need, but it is the combination of code created by many people who each had their own needs which is where the magic lies. Like it or not, VDR is a cathedral-style project: this has led to higher code quality and very good stability Compared to what? A well maintained bazaar-style project is generally thought to produce much higher quality code. Look at the Linux kernel and compare it to any other operating system. , at the expense of a slower development pace Yes, a very high cost. and the lack of some bleeding-edge features in the mainline. There is no bleeding edge repository, so life at the edge is more difficult for developers than it should be. If you want those features, you can use a patch posted on this list (e.g. for hdtv, sourcecaps) or use a plugin (e.g. for teletext subtitles). All those features should have been included in the main program a long time ago. Sourcecaps I believe has existed as a patch for about four *years* and has it's own web page. Absolutely ridiculous. I am lost for words. Many distributions include those patches or provide a way for the user to easily appy them. Yes the distributions unfortunately have to clean things up themselves, and as a result they are far behind the current development. Why should they or you hunt the lists for patches? Of course, you're also free to develop your own patches for new features: if they're good enough, Yes, you are always free to do various things, and that is an oft-used excuse in the open source world for various failings. Seriously who will put much effort in if it will their work will languish as a mere patch for a long time? I'm sure they'll eventually find their way into the mainline, as it happened, e.g., with the shutdown handling rewrite some time ago. Eventually is not good enough. How can you be sure enough to make it worth the effort? You say you want to fork it: what would you accomplish with that? It's not as if the code would magically write itself. The initial request was for a source repository, not necessarily a fork. Creating a repository would dramatically improve things. After 145 or so days without any release, there is a lot of code which has been posted as patches implementing vital features (such as H.264) which could immediately be merged in. Add to that all the long-standing patches which could be merged in quickly, and a number of the most essential plugins, plus sets of skins/themes/logos, plus some more minor plugins, plus plugins which have fallen into disrepair because nobody has tested them with a recent version. Then fix the makefiles so the config files and plugins actually go in senssible places. I could go on. There are a lot of very quick, very easy wins if a repository is created. And developers will know exactly where the bleeding edge is, and will be able to see clearly what needs to be fixed or can be added. And if a few of the best developers have write access, then things will not grind to a halt when Klaus goes on holiday and he will find that his workload decreases so that it becomes more fun for him. And users will be able to get a usable system up and running quickly without hunting the web for patches and plugins. It is currently *far* too difficult for all but the most persistent people. I've yet to see a single prospective developer say if it were forked I'd write X. Developers just usually don't talk like that. It's too hypothetical. (And, BTW, there's nothing forbidding him to write X in form of a patch and post it on this list.) As above. On the other hand, by forking you'd probably lose Klaus, If it were a fork, then by definition it would be without Klaus, but we started off talking about a repository. Klaus is still generally accepted as the leader of the project. The main issue is improving the development techniques he and everyone else uses. who has written by himself the majority of VDR code and knows it like no one else. Including the patches? Some of them are almost indispensable. Finally, I personally fail to see why people switching to MythTV is a bad thing; As a VDR user you really should care! VDR only works as well as it does because so many people have taken an interest in it, tested it, provided feedback, written patches and plugins, and promoted it. A project needs continual attention if it is to continue working well. If the interest falls then it will not be updated to work with updates to
Re: [vdr] VDR Development
On 09/06/08 16:34, Hans Werner wrote: ... After 145 or so days without any release, there is a lot of code which has been posted as patches implementing vital features (such as H.264) which could immediately be merged in. If I'm not mistaken the currently available patch for H.264 is based on the PES recording format, which will be the next thing to vanish! That's why I'm currently working on switching to TS recording format. It just didn't make sense to me to introduce H.264 recording in PES format and *then* switch to TS... Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR Development
On 09/06/08 16:34, Hans Werner wrote: ... After 145 or so days without any release, there is a lot of code which has been posted as patches implementing vital features (such as H.264) which could immediately be merged in. If I'm not mistaken the currently available patch for H.264 is based on the PES recording format, which will be the next thing to vanish! That's why I'm currently working on switching to TS recording format. It just didn't make sense to me to introduce H.264 recording in PES format and *then* switch to TS... Klaus Ok, I understand. Naturally there are often prerequisites which mean that a particular patch cannot be immediately applied. But your phrasing is quite telling: *I'm* currently working on switching to TS. I believe the TS recording story has been going on for some time. You said the same thing on May 4 2008 http://linuxtv.org/pipermail/vdr/2008-May/016762.html Here's a patch from December 2006 (perhaps there are problems with it, I don't know) http://fepg.org/patches/vdr-1.4.0-ts-recording-0.0.3.diff Here's a mention of the problem in 2004 http://linvdr.org/mailinglists/vdr/2004/05/msg00217.html I find it hard to believe it is really difficult to fix. There are lots of other people who could have helped crack the problem a long time ago. You do not need to do things the hard way and do all the heavy lifting yourself. It has a real impact on people if they can't use H.264 as a result. So how about creating a repository and picking a few trusted lieutenants to help you merge code? Regards, Hans -- Release early, release often. GMX startet ShortView.de. Hier findest Du Leute mit Deinen Interessen! Jetzt dabei sein: http://www.shortview.de/[EMAIL PROTECTED] ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR Development
Hans Werner wrote: Sourcecaps I believe has existed as a patch for about four *years* and has it's own web page. Absolutely ridiculous. I am lost for words. So I guess mythtv has something like that, right? Also, I've never heard of anyone doing a more general patch that also integrates things like the lnbsharing patch, or allowing different diseqc setups for different cards. So much for developers that would contribute if there just was a public repository. The same developers could already write patches and improve them until they match Klaus' quality needs. Cheers, Udo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR Development
What did I start?! For what its worth, I think VDR had DVB-S2 support (albeit patches) long before MythTV.. VDR does need some of its core functionality upgraded - for example something like the Reel channel scan is badly missing, you should be able to easily scan for transponders from within VDR, just like most satellite receivers. I've always found setting up channel lists painful. Also, other functions such as rotor, better disecq and sourcecaps etc should also be embedded within the core functionality by now. Perhaps a step towards a repo would be for people to work simply on these core patches with the aim to actually getting them integrated. Like mini projects, working with Klaus on the final quality on each one. Perhaps this might be a half way solution that satisfies more people and eventually Klaus might then have his lieutenants to give further access to. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR Development
On 09/06/08 17:40, Hans Werner wrote: On 09/06/08 16:34, Hans Werner wrote: ... After 145 or so days without any release, there is a lot of code which has been posted as patches implementing vital features (such as H.264) which could immediately be merged in. If I'm not mistaken the currently available patch for H.264 is based on the PES recording format, which will be the next thing to vanish! That's why I'm currently working on switching to TS recording format. It just didn't make sense to me to introduce H.264 recording in PES format and *then* switch to TS... Klaus Ok, I understand. Naturally there are often prerequisites which mean that a particular patch cannot be immediately applied. But your phrasing is quite telling: *I'm* currently working on switching to TS. That means I am currently changing my VDR code (meaning: the copy on my disk) in a way that it will finally use TS. I did look at patches I became aware of, but in some areas had other ideas how to do things. I believe the TS recording story has been going on for some time. You said the same thing on May 4 2008 http://linuxtv.org/pipermail/vdr/2008-May/016762.html So? At that time I started working in that area, and then came a rather busy and beautiful summer. I'm beginning to feel like a defendent here who has to justify his each and every action... Here's a patch from December 2006 (perhaps there are problems with it, I don't know) http://fepg.org/patches/vdr-1.4.0-ts-recording-0.0.3.diff There's no sign of PAT/PMT generation/parsing in that patch. If we're going to use TS, it should be a TS that can be actually used. I don't plan on continuing to use PES as recording format. Existing PES recordings will be playable, but new recordings will be TS only. Here's a mention of the problem in 2004 http://linvdr.org/mailinglists/vdr/2004/05/msg00217.html This was about recording encrypted streams and decrypting them later. IMHO a rather special application. Most people, I assume, have CAMs and will record the decrypted version directly. Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR Development
Morfsta wrote: VDR does need some of its core functionality upgraded - for example something like the Reel channel scan is badly missing, you should be able to easily scan for transponders from within VDR, just like most satellite receivers. Hmmm. My VDR automatically updates its channel list by itself, and adds all channels and transponders I ever needed. (which is far from what other receivers I know do.) The only thing I miss is a built-in way to get rid of channels that are gone. (I do have my own solution though.) Also, other functions such as rotor, better disecq and sourcecaps etc should also be embedded within the core functionality by now. Sure, agreed. But I don't see that there are developers that push this forward. Most features get developed to basic functionality, and then development stops, and the patch is merely ported from one version to the next. Before things can be included, they need to be thoughtfully improved to the best possible solution for all needs, because once included, the feature will stay for a very long time. A patch can just be dropped in favor of a better one, a core feature cannot. Perhaps a step towards a repo would be for people to work simply on these core patches with the aim to actually getting them integrated. Like mini projects, working with Klaus on the final quality on each one. Been there, done that. Takes a lot more time than you would think, but is definitely worth it. ;) Cheers, Udo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR Development
Original-Nachricht Datum: Sat, 06 Sep 2008 18:01:48 +0200 Von: Udo Richter [EMAIL PROTECTED] An: VDR Mailing List vdr@linuxtv.org Betreff: Re: [vdr] VDR Development Hans Werner wrote: Sourcecaps I believe has existed as a patch for about four *years* and has it's own web page. Absolutely ridiculous. I am lost for words. So I guess mythtv has something like that, right? Kaffeine looks like it does (in dvbrc you see: DVB0_LNB0_source=Astra-19.2E,Hotbird-13.0E and you can have multiple DVB cards). Not sure about MythTV but don't underestimate it. Anyway the point is that VDR almost has this nice capability, but sadly it is not quite there, because sourcecaps only exists as a patch. Something is wrong. Also, I've never heard of anyone doing a more general patch that also integrates things like the lnbsharing patch, or allowing different diseqc setups for different cards. I think you are suggesting that there are improvements beyond sourcecaps+lnbsharing which could be made. Definitely, but how many steps away from the current release do you think someone is willing to develop? Patches should be short term tools for moving code into a repository, nothing more. After that you carry on and work on further improvements. So much for developers that would contribute if there just was a public repository. The same developers could already write patches and improve them until they match Klaus' quality needs. The current system is not as encouraging and predictable as it should be regarding merging of innovations into the mainstream, so there is a barrier to that innovation. The way things are done in VDR means that patches can languish for years without getting merged into the mainstream. If I had written sourcecaps or lnbsharing I would be very upset that my (clearly useful) work had been ignored and not merged into the mainstream. If the development system were more welcoming to improvements (and predictable about merging patches) then there would be far more good work done. Everyone wants some quality control, but, and it may surprise some people, quality and high speed development are possible at the same time. In many ways it is easier for developers to solve big difficult problems in one big quick push because the whole problem stays in memory. A more subtle point is that patches are not necessarily independent -- you don't really know if there are any unexpected consequences of applying more than one patch until you try them all together. It's nonsense to put patches on websites for people to pull in as needed -- once you have more than one patch the result is undefined. So it is actually essential at some point to put all patches together in one place and start debugging the whole project. And that is what a repository is for. Hans -- Release early, release often. GMX startet ShortView.de. Hier findest Du Leute mit Deinen Interessen! Jetzt dabei sein: http://www.shortview.de/[EMAIL PROTECTED] ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR Development
Hi, Maybe you should read the CONTRIBUTORS file. On Sa, Sep 06, 2008 at 08:59:45 +0300, Andrey Kuzmin wrote: Sure, agreed. But I don't see that there are developers that push this forward. Most features get developed to basic functionality, and then development stops, and the patch is merely ported from one version to the next. Do you really think that any developer could be interested and so self motivated on this field for a long time when there is a king who doesn't allow anybody foreign to approach to his kingdom? ;) ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr -- Halim Sahin E-Mail: halim.sahin (at) t-online.de ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR Development
El Sat, 06 Sep 2008 19:22:08 +0200 Udo Richter [EMAIL PROTECTED] escribió: Hmmm. My VDR automatically updates its channel list by itself, and adds all channels and transponders I ever needed. (which is far from what other receivers I know do.) In spite of that, a couple of days ago I lost film4. I had to do a satellite scan (with my actuator plugin) to recover it (it changed transponder). Bye -- Luca ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR Development
Udo Richter [EMAIL PROTECTED] writes: Lets think this through: An open VDR repository for everyone to get in their personal 'I want this' patches. Surely this will lead to chaos, indeed. since no one really oversees the needs of all VDR users. (Take sourcecaps vs. lnbsharing as example.) So we have to restrict things. Only a few trusted dev's getting write access. In any case changes that go beyond simple bug fixing would require discussions about whether things go into the right direction, and I'm pretty sure that none of the trusted dev's would ever check in any changes without a previous ack by Klaus anyway. So if Klaus ack's anything anyway, why does anyone except Klaus actually need write access? And what about global warming ? What if germany gets sunny summer weather for the next 24 months ? :) no talk, no commit, nothing for 24 months ? I insist because I'd like to know where things go. I tend to think Klaus won't have as much time as he had in the past. And it's obviously not funny to developp features you're not interested in. So what's vdr future with only one developper ? [snip] - With a distributed repository system like Mercurical, it would also easily be possible to do external user branches to support more cutting-edge features, as long as some other maintainer keeps them up to date. Think of it as something like the -mm kernels, or as the bigpatch / extensions-patch. And if things get Klaus' approval, they can be easily merged back into main VDR too. indeed ! would linuxtv.org be interested in hosting it ? -- ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR Development
Lars Bläser [EMAIL PROTECTED] writes: [...] btw. there is a vdr fork repository (svn://reelbox.org) reel-multimadia has its own 1.4.7 dvb-s2, h.264 capable vdr they (Georg Acher?) wrote there own extension för dvb-s2 and they extended vdr to there needs it could be interesting to hear of the experience they have made (backports, using vdr 1.7.x in the future?) I've tried to compile the reelchannelscan plugin without any luck. (did not persevere tho) is it reelly a fork ? I'd be really interested in hearing comments about this version. -- ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR Development
On 09/05/08 16:15, Vladimir Kangin wrote: We can dedicate server for these purpose. And our administrators would be able to support it. Does it make sense? Of course I can't prevent people from doing this. But I won't synchronize my work on some repository where others call the shots. It would most likely mean my retirement from VDR development... Klaus On Fri, 2008-09-05 at 16:02 +0200, [EMAIL PROTECTED] wrote: VDR User [EMAIL PROTECTED] writes: What ever happened to the idea of setting up VDR deveopment on mercurial to allow the main contributors who want to work on it to do so without hassle/delay? I think converting to mpeg-ts instead of pes, and the hdtv support + all things related would be much farther along by now! Very good point ! I second this. Nothing prevents you from setting a repository on your side and give access to contributors. Yeah come on, be brave and fork it ! :) ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR Development
On Fri, Sep 5, 2008 at 7:38 AM, Magnus Hörlin [EMAIL PROTECTED] wrote: Of course you can fork it, and I'm sure someone eventually will, but I think you should regard it as a totally different project and give it some other name. This would lead to plugin developers having to decide which project(s) to support and it will probably just be a mess. I think VDR is Klaus's child and should remain so. Woah, wait a minute here! Nobody is suggesting to take VDR away from Klaus! There are clearly some good coders who want to continue helping progress VDR along as they already have been. The last released VDR update (1.7.0) was made 144 days ago. Everything people needed from VDR before still holds except not much development has been done and VDR hasn't moved forward. As much as I hate to say it, this is one of the main reasons so many users have abandoned VDR in favor of MythTV and other software. Again, nobody is suggesting to take VDR from Klaus.. Just simply allow progress to be made without these huge gaps where nothing happens where the users continue to be left in the cold while VDR continues to be left behind. Surely there are coders worthy of Klaus's 'coding approval' and if he doesn't want to work on VDR directly, it would still allow those that do to move forward and he can review the code rather then write it. Or have a dev tree and main tree. People can work on dev tree and what Klaus approves of could be adopted into main tree. Let's be clear... I've been a huge advocate for VDR. I do not want to see the project die, nor do I enjoy watching so many users abandon it. However, when much needed changes aren't made, what do you expect people to do? I can promise I didn't bring this topic up again to cause a problem. Only to point out that VDR is in need of help and there must be some way to move forward. Especially for the guys who are ready willing! Best regards, -Derek ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR Development
If it would be helpful for the project VDR we can contribute by setting up server at our DC. We are supporting LinuxMCE distro and also want to help to VDR as a part of LinuxMCE project. Best regards, Vladimir On Fri, 2008-09-05 at 08:02 -0700, VDR User wrote: On Fri, Sep 5, 2008 at 7:38 AM, Magnus Hörlin [EMAIL PROTECTED] wrote: Of course you can fork it, and I'm sure someone eventually will, but I think you should regard it as a totally different project and give it some other name. This would lead to plugin developers having to decide which project(s) to support and it will probably just be a mess. I think VDR is Klaus's child and should remain so. Woah, wait a minute here! Nobody is suggesting to take VDR away from Klaus! There are clearly some good coders who want to continue helping progress VDR along as they already have been. The last released VDR update (1.7.0) was made 144 days ago. Everything people needed from VDR before still holds except not much development has been done and VDR hasn't moved forward. As much as I hate to say it, this is one of the main reasons so many users have abandoned VDR in favor of MythTV and other software. Again, nobody is suggesting to take VDR from Klaus.. Just simply allow progress to be made without these huge gaps where nothing happens where the users continue to be left in the cold while VDR continues to be left behind. Surely there are coders worthy of Klaus's 'coding approval' and if he doesn't want to work on VDR directly, it would still allow those that do to move forward and he can review the code rather then write it. Or have a dev tree and main tree. People can work on dev tree and what Klaus approves of could be adopted into main tree. Let's be clear... I've been a huge advocate for VDR. I do not want to see the project die, nor do I enjoy watching so many users abandon it. However, when much needed changes aren't made, what do you expect people to do? I can promise I didn't bring this topic up again to cause a problem. Only to point out that VDR is in need of help and there must be some way to move forward. Especially for the guys who are ready willing! Best regards, -Derek ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR Development
Every Year the same discussion! Klaus has already pointed out his side of view for several times! And I would act like him. In some kind it is a Open Project. Just take the sources and enhance them. If it's meanfull and well done, Klaus will surely adopt it into VDR. Otherwise you can patch the new Version with the enhancement and no one will blame you for that. But! Coordinating such a Team is some thing that needs time, for itselfe. But all thouse discussions, about the priority of a feature should be done befor coding starts. If there is a repository I strongly believe there are some people setting there own Priority, doing things they like to do. And afterwards, someone has to clean up the mess. I did not always agree with Klaus and his task list but! Show me some peace of software in that dimension that works such stable if it is declared to be stable. Bye, Volker aka vdrmojo P.S.: Let them check out MythTV or something else. We'll welcome them soon. And if not? So what? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Goga777 Sent: Freitag, 5. September 2008 17:30 To: VDR Mailing List Subject: Re: [vdr] VDR Development Yes, it's great idea to create the repositary for VDR Goga -Original Message- From: Vladimir Kangin [EMAIL PROTECTED] To: VDR Mailing List vdr@linuxtv.org Date: Fri, 05 Sep 2008 18:21:23 +0300 Subject: Re: [vdr] VDR Development If it would be helpful for the project VDR we can contribute by setting up server at our DC. We are supporting LinuxMCE distro and also want to help to VDR as a part of LinuxMCE project. Best regards, Vladimir On Fri, 2008-09-05 at 08:02 -0700, VDR User wrote: On Fri, Sep 5, 2008 at 7:38 AM, Magnus Hörlin [EMAIL PROTECTED] wrote: Of course you can fork it, and I'm sure someone eventually will, but I think you should regard it as a totally different project and give it some other name. This would lead to plugin developers having to decide which project(s) to support and it will probably just be a mess. I think VDR is Klaus's child and should remain so. Woah, wait a minute here! Nobody is suggesting to take VDR away from Klaus! There are clearly some good coders who want to continue helping progress VDR along as they already have been. The last released VDR update (1.7.0) was made 144 days ago. Everything people needed from VDR before still holds except not much development has been done and VDR hasn't moved forward. As much as I hate to say it, this is one of the main reasons so many users have abandoned VDR in favor of MythTV and other software. Again, nobody is suggesting to take VDR from Klaus.. Just simply allow progress to be made without these huge gaps where nothing happens where the users continue to be left in the cold while VDR continues to be left behind. Surely there are coders worthy of Klaus's 'coding approval' and if he doesn't want to work on VDR directly, it would still allow those that do to move forward and he can review the code rather then write it. Or have a dev tree and main tree. People can work on dev tree and what Klaus approves of could be adopted into main tree. Let's be clear... I've been a huge advocate for VDR. I do not want to see the project die, nor do I enjoy watching so many users abandon it. However, when much needed changes aren't made, what do you expect people to do? I can promise I didn't bring this topic up again to cause a problem. Only to point out that VDR is in need of help and there must be some way to move forward. Especially for the guys who are ready willing! ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR Development
But! Coordinating such a Team is some thing that needs time, for itselfe. But all thouse discussions, about the priority of a feature should be done befor coding starts. May be it worth just to try and see if there is a problem here at all? ;-) I belive problem here is a bit different. There is no any good will to make this project more open. It's the direct path to become obsolete. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR Development
On Fri, Sep 5, 2008 at 9:00 AM, Volker Schierz [EMAIL PROTECTED] wrote: Every Year the same discussion! Maybe because the problem is never resolved? Klaus has already pointed out his side of view for several times! People are entitled to change their mind. At one point he had no interest in supporting HDTV, DVB-S2, or changing the recording format from mpeg-pes to something people can actually use outside of VDR! In some kind it is a Open Project. Just take the sources and enhance them. If it's meanfull and well done, Klaus will surely adopt it into VDR. Otherwise you can patch the new Version with the enhancement and no one will blame you for that. Ok, but we already know the relationship of developer(s)/maintainer. But! Coordinating such a Team is some thing that needs time, for itselfe. Not really. The list of main contributors isn't that long. But all thouse discussions, about the priority of a feature should be done befor coding starts. If there is a repository I strongly believe there are some people setting there own Priority, doing things they like to do. And afterwards, someone has to clean up the mess. What's wrong with people setting their own development priorities, especially if it means progress? It would be nice for us NTSC users to not have to patch VDR but clearly adding NTSC hasn't been a priority for any european developer. You miss the whole point it seems, which is -progress-. I hope you aren't suggesting that improving software, making it more robust, and making it more useful to more people is a bad thing! Also, clean up what mess? Do you think VDR's contributors are just a bunch of lamed coders writing lamed code? I did not always agree with Klaus and his task list but! Show me some peace of software in that dimension that works such stable if it is declared to be stable. You can't possibly think that all software using an open-dev environment is unstable garbage!! The linux kernel seems to manage. DVB drivers seem to manage. Countless software seems to manage just fine! P.S.: Let them check out MythTV or something else. We'll welcome them soon. And if not? So what? How far do you think that attitude will take you? Do you really have no care at all for the VDR users. People, like myself, who have been dedicated VDR users for many years now. Are you going to tell me too bad and that I should just install MythTV instead? When VDR progress is painfully slow or stopped, how does VDR or the users benefit by this? When VDR doesn't support things that are average/standard/etc., how does VDR or the users benefit by this? I will NOT apologize for wanting VDR to continue to grow, get better, become more useful, and at least stay in line with the current times. I will NOT apologize for being disappointed to see so many users abandon VDR due to lack of needed features. I have used VDR for many years and have helped many new people to dvb get their VDR systems running. I completely appreciate the work of Klaus and everyone else thats contributed to its development and I will not be sorry for wanting it to continue forward!! ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR Development
On 09/05/08 18:38, VDR User wrote: ... Seeing how many people have already left VDR, it's already happening! :( I have no idea how many people actually use VDR, but you apparently have some solid numbers on how many people dropped VDR. Do you mind sharing these numbers? Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR Development
On Fri, Sep 5, 2008 at 9:44 AM, Klaus Schmidinger [EMAIL PROTECTED] wrote: On 09/05/08 18:38, VDR User wrote: ... Seeing how many people have already left VDR, it's already happening! :( I have no idea how many people actually use VDR, but you apparently have some solid numbers on how many people dropped VDR. Do you mind sharing these numbers? I don't keep a list of names or a tally. And I also don't think this is any secret. I will however give you an example. There was a time when the majority of dvb users I talk to used VDR, and only a few guys used MythTV. Now the opposite is true. The majority of those people are using MythTV and few are left who still use VDR. Why? Primarily lack of support for what's already been previously discussed a million times.. Lack of support for HDTV, MPEG4, DVB-S2, and a recording format that is actually usable. The only surprise to me is how many people burn their recordings to DVD. I don't have any interest in doing that but clearly a whole lot of other people do. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR Development
On Fri, Sep 05, 2008 at 06:44:00PM +0200, Klaus Schmidinger wrote: I have no idea how many people actually use VDR, but you apparently have some solid numbers on how many people dropped VDR. Do you mind sharing these numbers? I have : I would like to be able to postprocess my recordingis (H.264 one's) which seems to be really hard sofar. I'll be back when that will be possible :-) -- Grégoire FAVRE http://gregoire.favre.googlepages.com http://www.gnupg.org http://picasaweb.google.com/Gregoire.Favre ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR Development
VDR User [EMAIL PROTECTED] writes: I will however give you an example. There was a time when the majority of dvb users I talk to used VDR, and only a few guys used MythTV. Now the opposite is true. The majority of those people are using MythTV and few are left who still use VDR. Why? Primarily lack of support for what's already been previously discussed a million times.. Lack of support for HDTV, MPEG4, DVB-S2, and a recording format that is actually usable. The only surprise to me is how many people burn their recordings to DVD. I don't have any interest in doing that but clearly a whole lot of other people do. i'm not into dvb-s2 yet. Without talking about this hype technology, what about : - multiple frontend+osd support - complex channel handling (no no not talking about xml, i hate xml) - sourcecap patch (having to patch vdr for such a feature is a no-go for a lot of people) I tend to agree, in the end a lot of people will move to bloat^Wmythtv. (and i agree, a lot of people have stopped using vdr) -- ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR Development
That's really the one thing that keeps me from using VDR: no multiple frontends. And I've tried the stream-thing plugin. I actually really like VDR's interface. I believe the people I'm creating this for, my parents, would be better of with it, too. /Met vriendelijke groeten,/ *Jelle De Loecker* Kipdola Studios - Tomberg [EMAIL PROTECTED] schreef: VDR User [EMAIL PROTECTED] writes: I will however give you an example. There was a time when the majority of dvb users I talk to used VDR, and only a few guys used MythTV. Now the opposite is true. The majority of those people are using MythTV and few are left who still use VDR. Why? Primarily lack of support for what's already been previously discussed a million times.. Lack of support for HDTV, MPEG4, DVB-S2, and a recording format that is actually usable. The only surprise to me is how many people burn their recordings to DVD. I don't have any interest in doing that but clearly a whole lot of other people do. i'm not into dvb-s2 yet. Without talking about this hype technology, what about : - multiple frontend+osd support - complex channel handling (no no not talking about xml, i hate xml) - sourcecap patch (having to patch vdr for such a feature is a no-go for a lot of people) I tend to agree, in the end a lot of people will move to bloat^Wmythtv. (and i agree, a lot of people have stopped using vdr) ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR Development
Klaus Schmidinger [EMAIL PROTECTED] writes: On 09/05/08 16:15, Vladimir Kangin wrote: We can dedicate server for these purpose. And our administrators would be able to support it. Does it make sense? Of course I can't prevent people from doing this. But I won't synchronize my work on some repository where others call the shots. It would most likely mean my retirement from VDR development... first of all : RESPECT i'm respectful and thankful for the very nice stable software. but vdr has not evolved for years ! no real new features, it's still meant to be used with one ff dvb-s card. there's a plugin interface but most of the time you don't want to hear about bugs when somebody is using a plugin. what's the point then ? And, what about this blackmail thing ? Wouldn't it be simpler to say i don't have time anymore, my needs won't evolve and i don't want to code features i won't use, please carry on ! ? -- ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR Development
On 09/04/08 12:38, Morfsta wrote: Hi, Does anyone know what is happening with VDR development these days? There doesn't seem to be much activity - is Klaus taking a long holiday or very busy with work!? :-) Please don't flame me for asking - I totally understand and appreciate that Klaus does it in his spare time etc and we have no right to demand development, but just that Klaus isn't here much these days and there has not been any new version of VDR 1.7.x for quite some time now. I presume other people must be wondering too what is going on with the future development of VDR and whether there is any planned? Hope everything is okay with Klaus too and he hasn't disappeared for some reason... This summer I had quite a few other things to do, and many times the weather was just too good to sit by the PC and do programming. I do intend to continue working on VDR, and I sure hope to find more time for it when the weather isn't so fine any more ;-) Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR Development
On Thu, Sep 4, 2008 at 11:46 AM, Klaus Schmidinger [EMAIL PROTECTED] wrote: This summer I had quite a few other things to do, and many times the weather was just too good to sit by the PC and do programming. I do intend to continue working on VDR, and I sure hope to find more time for it when the weather isn't so fine any more ;-) Klaus Glad to hear you're still around and OK Klaus and that you're still interested in VDR :-) Sounds like the weather is better in Germany than it has been here in the UK - we've had no summer for the second year running! Perhaps you should move here, then we can enjoy VDR development all year round! ;-) Enjoy! ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR Development
What ever happened to the idea of setting up VDR deveopment on mercurial to allow the main contributors who want to work on it to do so without hassle/delay? I think converting to mpeg-ts instead of pes, and the hdtv support + all things related would be much farther along by now! Cheers ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR Development
Klaus Schmidinger wrote: On 09/04/08 12:38, Morfsta wrote: Does anyone know what is happening with VDR development these days? There doesn't seem to be much activity - is Klaus taking a long holiday or very busy with work!? :-) This summer I had quite a few other things to do, and many times the weather was just too good to sit by the PC and do programming. Sometimes its necessary to give things a break, and enjoy other things instead. Feeling the need to continue without having the fun with it is the first step to abandoning a project, so enjoy doing totally different things until you really like to go on! Actually, I've been doing the same most summer. ;) Cheers, Udo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
