Re: [vdr] VDR Development

2008-09-08 Thread Udo Richter
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

2008-09-07 Thread Clemens Kirchgatterer
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

2008-09-07 Thread Clemens Kirchgatterer
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)

2008-09-07 Thread Helmut Auer
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)

2008-09-07 Thread Hans Werner

 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)

2008-09-07 Thread Helmut Auer
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

2008-09-07 Thread VDR User
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

2008-09-07 Thread Oliver Endriss
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


Re: [vdr] VDR Development

2008-09-07 Thread Halim Sahin
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

2008-09-07 Thread Bruno

 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

2008-09-07 Thread Clemens Kirchgatterer
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

2008-09-07 Thread Georg Acher
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

2008-09-07 Thread VDR User
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

2008-09-07 Thread Halim Sahin
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

2008-09-07 Thread Clemens Kirchgatterer
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

2008-09-07 Thread Goga777
  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

2008-09-07 Thread VDR User
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

2008-09-07 Thread Georg Acher
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

2008-09-07 Thread Oliver Endriss
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

2008-09-07 Thread Halim Sahin
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

2008-09-07 Thread Klaus Schmidinger
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

2008-09-07 Thread Clemens Kirchgatterer
Klaus Schmidinger [EMAIL PROTECTED] 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.

sure. but as soon as you introduced the plugin concept i, for one,
would have moved the dvb code into plugins. they give perfect testcases
for source and sink plugins. and why should i have dvb headers
installed to compile vdr, if i don't have a dvb card? i think vdrs
design is too thighly modeled after your personal usage cenario - it
could be a lot more generic. the main problem with vdr is maybe that
it works damn well within its limited scope. we live with its
shortcomings waiting for it to become whatever ones actual need is. if
it was more buggy or long winded to use, most have moved on already.
but it isn't.

best regards ...
clemens

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


Re: [vdr] VDR Development

2008-09-06 Thread Davide Cavalca
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

2008-09-06 Thread Carsten Koch
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

2008-09-06 Thread Ales Jurik
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

2008-09-06 Thread Klaus Schmidinger
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

2008-09-06 Thread Halim Sahin
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

2008-09-06 Thread Magnus Hörlin
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

2008-09-06 Thread Udo Richter
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

2008-09-06 Thread Laz
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

2008-09-06 Thread Lars Bläser
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

2008-09-06 Thread Lars Bläser
[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

2008-09-06 Thread Hans Werner
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

2008-09-06 Thread Klaus Schmidinger
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

2008-09-06 Thread Hans Werner
 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

2008-09-06 Thread Udo Richter
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

2008-09-06 Thread Morfsta
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

2008-09-06 Thread Klaus Schmidinger
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

2008-09-06 Thread Udo Richter
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

2008-09-06 Thread Hans Werner

 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

2008-09-06 Thread Halim Sahin
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

2008-09-06 Thread Luca Olivetti
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

2008-09-06 Thread syrius . ml
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

2008-09-06 Thread syrius . ml
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

2008-09-05 Thread Klaus Schmidinger
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

2008-09-05 Thread VDR User
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

2008-09-05 Thread Vladimir Kangin
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

2008-09-05 Thread Volker Schierz
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

2008-09-05 Thread Andrey Kuzmin
 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

2008-09-05 Thread VDR User
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

2008-09-05 Thread Klaus Schmidinger
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

2008-09-05 Thread VDR User
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

2008-09-05 Thread Gregoire Favre
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

2008-09-05 Thread syrius . ml
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

2008-09-05 Thread Jelle De Loecker
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

2008-09-05 Thread syrius . ml
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

2008-09-04 Thread Klaus Schmidinger
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

2008-09-04 Thread Morfsta
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

2008-09-04 Thread VDR User
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

2008-09-04 Thread Udo Richter
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