Hello!
I would like to share some of thoughts on what I have observed over a short periode of time. I've been following the mailing list, I don't have practically any knowledge in programming so I won't even try to comment on the technical details of the vdr project itself. I would also like to point out that this is not an invitation to a discussion from my part as I wont be able to participate due to time constraint in my private life. I am also a huge fan of the vdr project and I'm in the process of building a htpc running vdr myself :) This is how I feel I am able to contribute to the project without having actual coding knowledge. Hopefully no one is offended by anything I say, as I'm not trying to point out any incompetence in anyone.
Enough jibberish, I'll get to the point at hand, now.
In my opinion the vdr project is sliding into a bad direction, not code wise. I don't know if an actual roadmap exists somewhere about the planned features for the 1.5-devel series but there should be one. The devel series looks like it's getting flooded with new features, which is great ofcourse and shows that people are contributing to the project. But this is where I see a risk and it looks something like this: The stable version of vdr (1.4.6.something at the time being afaik) get's "older" all the time and only the most vital parts from the devel-branch get backported. Now that is not a problem on it's own, stability is good, but if the 1.5 devel branch gets new features constantly with no feature freeze in site...hopefully people understand where I'm going with this.
I'll once again remind everyone reading this that I don't have all the facts concerning this project at hand and there might very well be a roadmap which is strictly followed, and if this is the case all is good and you can ignore this message =)
Last but not least, Huge Props to all the people working on this project, contributing in whatever way they can and thanks for creating something I can put on a computer, hand the remote to the mrs and tell her to record whatever she wants and not have to worry about it breaking down. This was my attempt to contribute to this project.
On 05/08/07 22:37, mikke@ihku.org wrote:
... The stable version of vdr (1.4.6.something at the time being afaik) get's "older" all the time and only the most vital parts from the devel-branch get backported.
Well, that's what a "stable" version is by definition ;-) It gets actual bugs fixed (see the latest 1.4.6-1 maintenance patch), but other than that there are no more big changes. The new stuff goes into the 1.5 developer version and will ultimately result in a stable version 1.6 one day.
Now that is not a problem on it's own, stability is good, but if the 1.5 devel branch gets new features constantly with no feature freeze in site...hopefully people understand where I'm going with this.
We're not on any kind of schedule here. Remember that VDR is being developed (at least on my end) in spare time. The stable version 1.4 is well fit for every day operation (I really use it a *lot* - watching tv without it would be totally unthinkable to me ;-), and I'm gradually implementing new things in the 1.5 developer version. Right now I'm busy with the UTF-8 stuff. I admit that there have been (sometimes long) periods of time where there hasn't been anything new from my side, but that's because I do have a live besides VDR (well, at least a little...).
I'll once again remind everyone reading this that I don't have all the facts concerning this project at hand and there might very well be a roadmap which is strictly followed, and if this is the case all is good and you can ignore this message =)
As I've stated on several occasions: I don't like official roadmaps. They tend to become sort of binding, and if - for some reason - a new release actually doesn't contain a feature that was promised on the roadmap, all sorts of complaints might emerge. I do observe the mailing list and all the suggestions and patches posted here or sent to me in private emails, but I like to be free to actually implement whatever I see fit at my own pace.
Hope that's ok with you ;-)
Klaus
I hereby take back what I said about having time to reply =)
On Tue, May 08, 2007 at 11:43:59PM +0200, Klaus Schmidinger wrote:
On 05/08/07 22:37, mikke@ihku.org wrote:
... The stable version of vdr (1.4.6.something at the time being afaik) get's "older" all the time and only the most vital parts from the devel-branch get backported.
Well, that's what a "stable" version is by definition ;-) It gets actual bugs fixed (see the latest 1.4.6-1 maintenance patch), but other than that there are no more big changes. The new stuff goes into the 1.5 developer version and will ultimately result in a stable version 1.6 one day.
Now that is not a problem on it's own, stability is good, but if the 1.5 devel branch gets new features constantly with no feature freeze in site...hopefully people understand where I'm going with this.
We're not on any kind of schedule here. Remember that VDR is being developed (at least on my end) in spare time. The stable
This here is exactly why I'm concerned about this! As you yourself said in the above/below statement, time is a limited resource for this project and you can't spend all day developing vdr (and you have a life besides vdr =). The way I see it, is a clear roadmap could make the development more effective and avoid waste of time doing wrong things. Still not saying you've done anything wrong, vdr speaks for you in a very positive way.
version 1.4 is well fit for every day operation (I really use it a *lot* - watching tv without it would be totally unthinkable to me ;-), and I'm gradually implementing new things in the 1.5 developer version. Right now I'm busy with the UTF-8 stuff. I admit that there have been (sometimes long) periods of time where there hasn't been anything new from my side, but that's because I do have a live besides VDR (well, at least a little...).
I'll once again remind everyone reading this that I don't have all the facts concerning this project at hand and there might very well be a roadmap which is strictly followed, and if this is the case all is good and you can ignore this message =)
As I've stated on several occasions: I don't like official roadmaps. They tend to become sort of binding, and if - for some reason - a new release actually doesn't contain a feature that was promised on the roadmap, all sorts of complaints might emerge. I do observe the mailing list and all the suggestions and patches posted here or sent to me in private emails, but I like to be free to actually implement whatever I see fit at my own pace.
Hope that's ok with you ;-)
Klaus
Whatever you chose to do with vdr is fine with me, it's your project. I'm not trying to tell you what to do with it either. My intentions were purely to lend you a pair of eyes and share what I've observed. I also respect whatever you do with vdr and hope vdr will continue to develop and become even greater in the future. Now I really think I've said anything I need to say and you(klaus) can forget about this or do whatever but I don't think I'll have time to reply(once or twice a day, tops!) as often as I'd like to.
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
mikke@ihku.org wrote:
As you yourself said in the above/below statement, time is a limited resource for this project and you can't spend all day developing vdr (and you have a life besides vdr =). The way I see it, is a clear roadmap could make the development more effective and avoid waste of time doing wrong things.
Just assume that Klaus has his personal roadmap he follows. There hasn't been much in 1.5 development yet, so its safe to assume that there's no stable 1.6 anywhere in sight anyway. Many feature requests from the 1.3 cycle are still postponed, and things will take some time. And since most of the code is still written by Klaus, there's no need for a strict public roadmap to coordinate development. VDR development is slow simply because There Can Be Only One Klaus. ;)
VDR development would speed up, if Klaus would delegate more work to other talented coders, and doing more review instead of coding most of it himself. But giving up control on one's favorite hobby project is hard, I know that. Even if it's just a few lines, their not 'your' lines any more.
There are may active VDR coders, but most of them just write patches for their own needs, not for general VDR enhancement. That way, many good ideas get lost over time. But writing a patch is easy, contributing to a project requires a lot more. It requires hard decisions about what and how to implement things, and a long evolution until all (means, Klaus) are satisfied with the results.
Maybe, with some bravery of both sides, VDR itself could turn more into a team project just like the whole VDR community is.
(Just my 2c, not demanding anything here.)
Cheers,
Udo
On 05/10/07 20:04, Udo Richter wrote:
... VDR development would speed up, if Klaus would delegate more work to other talented coders, and doing more review instead of coding most of it himself.
Well, right now I'm dealing with the UTF-8 stuff, which is something I myself don't need at all. But unfortunately the patch(es) for this can't just be applied as it, because from what I've seen so far there it is assumed that the whole program is totally going UTF-8 - which it is *not*. I still want to be able to run it on a pure and clean iso8859-1 system. So I have to painstakingly go through the whole thing and take care that it only does UTF-8 if so requested - and that's a lot more work than just applying a patch...
Klaus
Klaus Schmidinger wrote:
On 05/10/07 20:04, Udo Richter wrote:
... VDR development would speed up, if Klaus would delegate more work to other talented coders, and doing more review instead of coding most of it himself.
Well, right now I'm dealing with the UTF-8 stuff, which is something I myself don't need at all. But unfortunately the patch(es) for this can't just be applied as it, because from what I've seen so far there it is assumed that the whole program is totally going UTF-8 - which it is *not*. I still want to be able to run it on a pure and clean iso8859-1 system. So I have to painstakingly go through the whole thing and take care that it only does UTF-8 if so requested - and that's a lot more work than just applying a patch...
What's wrong with vdr using UTF-8 internally if it makes the code simpler? Offhand I could only imagine two places where using a different external encoding would be required and that's file names and tty i/o. Stuff like epg.data and svdrp should better use UTF-8 as you don't need to add extra meta data options to specify the encoding.
cu Ludwig
On 05/11/2007 09:25 AM, Ludwig Nussel wrote:
Klaus Schmidinger wrote:
On 05/10/07 20:04, Udo Richter wrote:
... VDR development would speed up, if Klaus would delegate more work to other talented coders, and doing more review instead of coding most of it himself.
Well, right now I'm dealing with the UTF-8 stuff, which is something I myself don't need at all. But unfortunately the patch(es) for this can't just be applied as it, because from what I've seen so far there it is assumed that the whole program is totally going UTF-8 - which it is *not*. I still want to be able to run it on a pure and clean iso8859-1 system. So I have to painstakingly go through the whole thing and take care that it only does UTF-8 if so requested - and that's a lot more work than just applying a patch...
What's wrong with vdr using UTF-8 internally if it makes the code simpler? Offhand I could only imagine two places where using a different external encoding would be required and that's file names and tty i/o. Stuff like epg.data and svdrp should better use UTF-8 as you don't need to add extra meta data options to specify the encoding.
It's very simple: I don't like it! The two languages I can handle can be perfectly well represented with iso8859-1, so I just don't want to have to go through all the hassle with UTF-8. To me, a character is a character is a byte is a byte. Period.
Now, I do see that there are people out there who can't represent their language with single byte character sets, or want to be able to handle more languages than a single character set can cope with, so I am going to make VDR able to handle UTF-8. But only in a way that allows (at least) me to completely turn this stuff off. Whenever I install a new version of SUSE Linux, the first this I always do is turn off UTF-8. I just don't want it and don't need it.
Klaus
Klaus Schmidinger wrote:
On 05/11/2007 09:25 AM, Ludwig Nussel wrote:
Klaus Schmidinger wrote:
On 05/10/07 20:04, Udo Richter wrote:
... VDR development would speed up, if Klaus would delegate more work to other talented coders, and doing more review instead of coding most of it himself.
Well, right now I'm dealing with the UTF-8 stuff, which is something I myself don't need at all. But unfortunately the patch(es) for this can't just be applied as it, because from what I've seen so far there it is assumed that the whole program is totally going UTF-8 - which it is *not*. I still want to be able to run it on a pure and clean iso8859-1 system. So I have to painstakingly go through the whole thing and take care that it only does UTF-8 if so requested - and that's a lot more work than just applying a patch...
What's wrong with vdr using UTF-8 internally if it makes the code simpler? Offhand I could only imagine two places where using a different external encoding would be required and that's file names and tty i/o. Stuff like epg.data and svdrp should better use UTF-8 as you don't need to add extra meta data options to specify the encoding.
It's very simple: I don't like it! The two languages I can handle can be perfectly well represented with iso8859-1, so I just don't want to have to go through all the hassle with UTF-8. To me, a character is a character is a byte is a byte. Period.
Now, I do see that there are people out there who can't represent their language with single byte character sets, or want to be able to handle more languages than a single character set can cope with, so I am going to make VDR able to handle UTF-8. But only in a way that allows (at least) me to completely turn this stuff off. Whenever I install a new version
Isn't that constraint going to add too much unnecessary overhead to the code? I guess you'd be then forced to take care of handling both requirements forever, with every future version. Is that really what you want, only to satisfy the "I don't like it" reason? I mean, you're already doing a compromise at least, and a lot of us salute this, I'm only wondering if it wouldn't actually make your life easier if supporting just one of 2 things you want to support anyway, the complicated one, UTF-8, and the hassle-free one, non-utf-8. Since you're willing to support UTF-8, the other one is in my opinion, just extra work from now on, slowing down development (God beware, I'm not tryin' to push you)...
of SUSE Linux, the first this I always do is turn off UTF-8. I just don't want it and don't need it.
Klaus
Klaus Schmidinger wrote:
On 05/11/2007 09:25 AM, Ludwig Nussel wrote:
What's wrong with vdr using UTF-8 internally if it makes the code simpler? Offhand I could only imagine two places where using a different external encoding would be required and that's file names and tty i/o. Stuff like epg.data and svdrp should better use UTF-8 as you don't need to add extra meta data options to specify the encoding.
It's very simple: I don't like it! The two languages I can handle can be perfectly well represented with iso8859-1, so I just don't want to have to go through all the hassle with UTF-8. To me, a character is a character is a byte is a byte. Period.
Come on, take some "Scheissegalpillen" and stop beeing stubborn ;-) I aggree that UTF-8 isn't exactly delightful but from a user's point of view the hassle with UTF-8 is less than the hassle having to deal with multiple encodings. I mean even when ignoring languages other than German you have trouble with the stupid euro sign when using iso8859-*. Look at the bright side of UTF-8, at most places you don't really have to care about the actual characters so you don't need special treatment. After all it could be worse. If the new standard would be a fixed width multibyte encoding with embedded null bytes you'd have to really rewrite all your code.
cu Ludwig
Hi Klaus, in our devices (barcode reader) we use 16 bit characters and it works out nice and easy and very similar to the old bytes. It was not easy to convince my collegues (in the USA), but I managed to do it.
IMHO this is much simpler than the UTF8, all the index into a string still works. I added overloads of the lib functions which are 16 bits wide Example: wchar_t *strcpy(wchar_t *pOut, wchar_t *pIn); So the code even looks like in the old days. If you like I can mail you some files.
This approach seams to be not used in the Linux world, I do not understand why. UTF8 is a pain! The argument about the bigger buffers do not count in todays devices and is not that much. You only have to be carefull to treat characters as such and binary bytes as such (still a byte). Many programmers mix that up.
Hi All, hi Klaus,
i would like to say also my 0,02€ to it.
My UTF-8 patch, which I wrote for 1.3 - 1.4 vdr is ugly hack. I have developed a patch from emergency !!!
I must unfortunately with 3 languages go around and could not simply not see that German words instead of üöä cyrillic characters had.
My suggestion is to be changed over vdr internally to wchar_t. Then will everything again good, everything becomes Period; -).
Please don't make same hacks such in my patch. Change a type to wchar_t.
Only a part for OSD can be taked over in 1.5
On 05/11/07 16:51, alexander-riedel@t-online.de wrote:
Hi All, hi Klaus,
i would like to say also my 0,02€ to it.
My UTF-8 patch, which I wrote for 1.3 - 1.4 vdr is ugly hack. I have developed a patch from emergency !!!
I must unfortunately with 3 languages go around and could not simply not see that German words instead of üöä cyrillic characters had.
My suggestion is to be changed over vdr internally to wchar_t. Then will everything again good, everything becomes Period; -).
Please don't make same hacks such in my patch. Change a type to wchar_t.
wchar_t is definitely *not* the way I'll go.
Klaus
It's simply short-sighted. .... The best way in Open Source is fork of project. If this happens, I will support this new project.
-- Alexander
On 11 May 2007, at 15:54, Klaus Schmidinger wrote:
Please don't make same hacks such in my patch. Change a type to wchar_t.
wchar_t is definitely *not* the way I'll go.
I feel so lucky working with Java when it comes to character encoding issues. Our webapp uses UTF-8 exclusively, but we seldom have to deal with encoding at all.
Isn't there a nice c++ string library that deals with encoding issues behind the surface automagically?
I think the best question to be asking concerning UTF-8 isn't if you personally like the idea but rather what's better in terms of design. That consideration should outweigh any other. You certainly don't want to create a situation where you're doing a lot more work then necessary in the long run, and if there's a better way to do something then why not let the software and end-users benefit by it? Even if it means more hassle now. It sounds like UTF-8 is a pain in the ass but it's also a one-time thing. Once you've got it working correctly, it shouldn't need much maintenance (if any).
Since Klaus has pointed out he has no real interest in UTF-8 himself, maybe the task of doing -proper- implementation could be assigned to other perfectly capable developers who are willing to do it. This way it can be properly implemented and Klaus wouldn't have to fuss with it at all, allowing him to focus on code he actually wants to write.
On 05/11/07 18:10, VDR User wrote:
I think the best question to be asking concerning UTF-8 isn't if you personally like the idea but rather what's better in terms of design. That consideration should outweigh any other. You certainly don't want to create a situation where you're doing a lot more work then necessary in the long run, and if there's a better way to do something then why not let the software and end-users benefit by it? Even if it means more hassle now. It sounds like UTF-8 is a pain in the ass but it's also a one-time thing. Once you've got it working correctly, it shouldn't need much maintenance (if any).
Since Klaus has pointed out he has no real interest in UTF-8 himself, maybe the task of doing -proper- implementation could be assigned to other perfectly capable developers who are willing to do it. This way it can be properly implemented and Klaus wouldn't have to fuss with it at all, allowing him to focus on code he actually wants to write.
Well, at some point I'd have to deal with it, anyway, if it's supposed to become part of the core VDR code. So I'd rather do it myself now.
Klaus
On 5/11/07, Klaus Schmidinger Klaus.Schmidinger@cadsoft.de wrote:
Well, at some point I'd have to deal with it, anyway, if it's supposed to become part of the core VDR code. So I'd rather do it myself now.
Sure, but if doing it yourself means not doing it properly, why not let someone else who's willing to do the work, do it the right way? That makes much more sense then writing some kind of hybrid method that requires more long-term maintenance. At the end of the day, not liking something just isn't a good reason to prevent making better design choices.
On 05/11/07 18:56, VDR User wrote:
On 5/11/07, Klaus Schmidinger Klaus.Schmidinger@cadsoft.de wrote:
Well, at some point I'd have to deal with it, anyway, if it's supposed to become part of the core VDR code. So I'd rather do it myself now.
Sure, but if doing it yourself means not doing it properly, why not let someone else who's willing to do the work, do it the right way? That makes much more sense then writing some kind of hybrid method that requires more long-term maintenance. At the end of the day, not liking something just isn't a good reason to prevent making better design choices.
All I want is to have a VDR that properly behaves according to the character set on the system it's running on. If that system is set to UTF-8, VDR shall use UTF-8. If it's set to iso8859-1 it shall use iso8859-1 etc. I can't see anything wrong with that.
Klaus
ONE LAST THING! =)
As I've stated on several occasions: I don't like official roadmaps. They tend to become sort of binding, and if - for some reason - a new release actually doesn't contain a feature that was promised on the roadmap, all sorts of complaints might emerge. I do observe the mailing list and all the suggestions and patches posted here or sent to me in private emails, but I like to be free to actually implement whatever I see fit at my own pace.
Ofcourse making tight deadlines for people who contribute on their spare time is crazy. On the other hand I still do think that a deadline two years away is a better thing than a new version coming out two years from now and everyone expects it to be released any day now. To really simplify it, saying people "version 1.5 will be out in 2008" is better than saying "version 1.5 will be out when it's done"(you'll easily make the deadline without sacrificing any more spare time than you do now) is better than "version 1.5 will be out in january 2008"(you'll have to sacrifice more spare time than you want and it still might not make it).
now I'm really done
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
I'll chime in... I've emailed Klaus on many occasions with what I thought were potential bugs, new feature requests, or just general inquiry. He's always replied (although sometimes not so quickly ;), and what I've come to realize... or maybe remember is a better word to use here.. What I've come to remember is that vdr is a great piece of software with a lot of author & community support. It's not important that the public be aware of the TODO list or any related time tables for the reasons Klaus has already mentioned.
I can say I have no concern about the development of vdr unless Klaus and the others tells us theres reason for it. I'm perfectly content hearing "1.6 will be out when it's ready" as long as I know it's under active development.
Also, stable versions are meant to be just that... Stable. And it takes time to make sure the stability is consistent, especially when there are many new features that have been added.
My final advice to you is, ...there's nothing to be worried about right now so don't bother yourself with it! :)
Cheers
VDR User wrote:
I can say I have no concern about the development of vdr unless Klaus and the others tells us theres reason for it. I'm perfectly content hearing "1.6 will be out when it's ready" as long as I know it's under active development.
I have been a VDR user for nearly 5 years now, but really only a user, not a developer, and was not able to contribute much to the community. Since then I have been following mostly the vdr and dvb mailing lists, but sometimes also the vdrportal.
During the development of version 1.3 I have been often a little frustrated not to have seen a final version 1.4. There were a lot of reasons that IMHO the usage of version 1.2 was quite outdated: No automatic channel scan, updated Dolby Digital output, modified recording format and finally plug-ins that only worked with the 1.3 branch.
I expect the same for vdr 1.5 concerning e.g. multiprotocol drivers, or to be more precise: Usage of DVB-S2. As soon as multiprotocol drivers and DVB-S2 are working, I think there will be once again no way back to the stable version, even if the final 1.6 might make us wait until 2009/2010. Nevertheless, it was good to see that bigger bugs in 1.3 have been reported a few days later so that I was always informed wether it was "secure" to install the latest development branch.
I hope there is much going on behind the scenes between kls and the developers. Several year ago, the main discussion was here on this list, and you could see that there was a lot going on. Now, I would have to follow vdrportal.de daily to get the latest informations which also is not easy for me (and maybe kls) are indeed a lot of other things to do in real life.
Finally, vdr is great, don´t know how I could live without it - remember VHS without timeshifting, EPG etc. :)
With kind regards
Joerg Knitter
P.S.: Great to see the UTF-8 support. I can remember some posts where kls said that he did not like it and thus did not want to implement it :)
On 9 May 2007, at 15:06, Klaus Schmidinger wrote:
On 05/09/2007 04:02 PM, Joerg Knitter wrote:
.. P.S.: Great to see the UTF-8 support. I can remember some posts where kls said that he did not like it and thus did not want to implement it :)
I still don't like it - and I won't be using it myself either ;-)
Does the UTF-8 support include the freetype font support? Antialiased fonts looks soooo much better.
Torgeir Veimo torgeir@pobox.com wrote:
Does the UTF-8 support include the freetype font support? Antialiased fonts looks soooo much better.
UTF-8 makes no sense with a 7-bit ascii character set. so i guess, yes.
clemens
On 05/09/07 16:37, Torgeir Veimo wrote:
On 9 May 2007, at 15:06, Klaus Schmidinger wrote:
On 05/09/2007 04:02 PM, Joerg Knitter wrote:
.. P.S.: Great to see the UTF-8 support. I can remember some posts where kls said that he did not like it and thus did not want to implement it :)
I still don't like it - and I won't be using it myself either ;-)
Does the UTF-8 support include the freetype font support? Antialiased fonts looks soooo much better.
As Clemens already stated, UTF-8 pretty much requires that. However, I'm not sure, yet, whether this also immediately means "font anitaliasing", because that's not necessarily something required by UTF-8.
Klaus
On 9 May 2007, at 17:10, Klaus Schmidinger wrote:
As Clemens already stated, UTF-8 pretty much requires that. However, I'm not sure, yet, whether this also immediately means "font anitaliasing", because that's not necessarily something required by UTF-8.
Well, it's prob not required, but it makes text much more readable, especially when the output device supports more than 16 colours.
On 5/9/07, Joerg Knitter joerg.knitter@gmx.de wrote:
During the development of version 1.3 I have been often a little frustrated not to have seen a final version 1.4. There were a lot of reasons that IMHO the usage of version 1.2 was quite outdated: No automatic channel scan, updated Dolby Digital output, modified recording format and finally plug-ins that only worked with the 1.3 branch.
I expect the same for vdr 1.5 concerning e.g. multiprotocol drivers, or to be more precise: Usage of DVB-S2. As soon as multiprotocol drivers and DVB-S2 are working, I think there will be once again no way back to the stable version, even if the final 1.6 might make us wait until 2009/2010. Nevertheless, it was good to see that bigger bugs in 1.3 have been reported a few days later so that I was always informed wether it was "secure" to install the latest development branch.
Some people (not saying you're one of them) automatically assume that because something is labeled as "development", that it's not stable. Not true. I've been using vdr since 1.3.x also and most of the 'development' versions up until 1.5.2 have been very stable. Something else I've noticed is people thinking vdr is faulty when it's actually a plugin they use that's causing problems.
On 05/09/07 18:37, VDR User wrote:
... I've been using vdr since 1.3.x also and most of the 'development' versions up until 1.5.2 have been very stable.
I personally always use the latest developer version in every day operation, so I have every reason to make sure it runs stable ;-)
Klaus
-
alexander-riedel＠t-online.de -
Clemens Kirchgatterer -
Dieter Fauth -
Joerg Knitter -
Klaus Schmidinger -
Lucian Muresan -
Ludwig Nussel -
mikke＠ihku.org -
Torgeir Veimo -
Udo Richter -
VDR User