[vdr] Betr: Standardized DVB signal info up for review!
As many know, getting standardized dvb signal info in linux has been a want for a very long time for a lot of users (and developers). There has been several talks/threads about it but nothing was ever merged. The subject has come up once again and Mauro has posted a patch for review. I know that there are at least a handful of coders here who have interest in this, including Klaus. I strongly urge anyone who would like to see this finally happen to take a few minutes and read the links below. Further, it would be great if people actively participated in the discussion so please post anything you may like to contribute to the discussion! I have read the discussion. The kernel to userspace interface is not allowed to change, as this would brake userspace programs, so any fix would have to come from a new kernel side interface. Therefore at the VDR side we have two options: 1)Wait for the new kernel interface to happen with a standard way to report quality and strength. 2)Implement work arounds for each receiver. In my opinion this has to be done anyway, in order to let VDR run on old kernel versions. Best regards, Cedric ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] Betr: Re: adjust range of snr bar at bottom of vdr screen?
Please send me a proper patch if you have any success with this.
Klaus
Hi Klaus,
I have not yet tested this, but the below code should work. I assume the
receiver has a snr of 0x to 0x00ff based on the following datapoints:
0x0080 almost never lock, unwatchable
0x0090 almost always lock, lots of disturbances
0x00A0 always lock, almost never disturbances
0x00D0 best signal ever received.
$ lsusb
Bus 001 Device 004: ID 2013:0245 PCTV Systems PCTV 73ESE
uint16_t MaxSnr = 0x; // Let's assume the default is using the entire
range.
// Use the subsystemId to identify individual devices in case they need
// special treatment to map their Snr value into the range 0...0x.
switch (subsystemId) {
case 0x13C21019: MaxSnr = 200; break; // TT-budget S2-3200
(DVB-S/DVB-S2)
case 0x20130245: MaxSnr = 0x00ff; break; //PCTV Systems PCTV 73ESE
}
int a = int(Snr) * 100 / MaxSnr;
int b = 100 - (Unc * 10 + (Ber / 256) * 5);
Sorry for not sending a proper patch as requested, I have not yet found the
time to test it properly.
Best regards,
Cedric
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] adjust range of snr bar at bottom of vdr screen?
On 30.12.2012 10:15, cedric.dew...@telfort.nl wrote:
Please send me a proper patch if you have any success with this.
Klaus
Hi Klaus,
I have not yet tested this, but the below code should work. I assume the
receiver has a snr of 0x to 0x00ff based on the following datapoints:
0x0080 almost never lock, unwatchable
0x0090 almost always lock, lots of disturbances
0x00A0 always lock, almost never disturbances
0x00D0 best signal ever received.
$ lsusb
Bus 001 Device 004: ID 2013:0245 PCTV Systems PCTV 73ESE
uint16_t MaxSnr = 0x; // Let's assume the default is using the entire
range.
// Use the subsystemId to identify individual devices in case they need
// special treatment to map their Snr value into the range 0...0x.
switch (subsystemId) {
case 0x13C21019: MaxSnr = 200; break; // TT-budget S2-3200
(DVB-S/DVB-S2)
case 0x20130245: MaxSnr = 0x00ff; break; //PCTV Systems PCTV 73ESE
}
int a = int(Snr) * 100 / MaxSnr;
int b = 100 - (Unc * 10 + (Ber / 256) * 5);
Sorry for not sending a proper patch as requested, I have not yet found the
time to test it properly.
No problem, I can easily insert this one-liner ;-).
Are you sure about the subsystemId? IIRC somebody claimed that these don't
apply to USB devices (which yours apparently is, since you did an lsusb).
Just wondering...
Klaus
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [DISCUSSION REQUEST] reintroduce a common make configuration file in VDR-1.7.35
2012/12/30 fnu v...@auktion.hostingkunde.de: And as far as I remember nobody did complain about the old Makefile structur, and yes I mean nobody, because the two now known just changed it w/o warning. Do what ever you need to do, I appriciate it, but remind always some continuity for all others in the VDR universe. Ohh come on. There were warnings. VDR-Portal: http://www.vdr-portal.de/board17-developer/board25-patches/115856-redundanz-in-der-make-config-und-make-global/ Mailinglist: http://linuxtv.org/pipermail/vdr/2012-November/026813.html Everyone who complains now was just too proud or to ignorant to answer on one of these threads. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [DISCUSSION REQUEST] reintroduce a common make configuration file in VDR-1.7.35
Am 30.12.2012 01:08, schrieb Christopher Reimer: I don't consider the mailinglist as central spot of developement. Here I'm forced to speak English. Almost all VDR Users are German. And in VDR-Portal I reach the critical mass. With the addition that I am allowed to speak my native language. What makes you believe that? Do you have any numbers? I don't have user counts either. I know that visitors of yavdr.org are not the same as vdr users, but they might be somehow related. Our statistics shows that the german group is with %67 of course the biggest, but far away from almost all. Gerald !DSPAM:50e02a13296741317615234! ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] [ANNOUNCE] VDR developer version 1.7.35
VDR developer version 1.7.35 is now available at ftp://ftp.tvdr.de/vdr/Developer/vdr-1.7.35.tar.bz2 A 'diff' against the previous version is available at ftp://ftp.tvdr.de/vdr/Developer/vdr-1.7.34-1.7.35.diff MD5 checksums: 3b9d0376325370afb464b6c5843591c7 vdr-1.7.35.tar.bz2 4b6fb681359325ad33a466503503e772 vdr-1.7.34-1.7.35.diff WARNING: This is a *developer* version. Even though *I* use it in my productive environment. I strongly recommend that you only use it under controlled conditions and for testing and debugging. The changes since version 1.7.34: - Making sure that plugins include the VDR header files from the actual VDR source directory when doing make plugins (suggested by Christoper Reimer). - Increased the version numbers of all plugins to reflect the recent Makefile changes. - Removed the lines ifdef DVBDIR INCLUDES += -I$(DVBDIR)/include endif from the file Make.config.template. If set, DVBDIR is now conveyed to plugins via the CFLAGS. - Removed some redundancy from Make.config.template. - Changed == to = in the Makefile to make it POSIX style. - Added MANDIR to the vdr.pc file, so that plugins that need it can retrieve it via MANDIR = $(DESTDIR)$(call PKGCFG,mandir). - Using relative paths again when building plugins locally (by request of Udo Richter). - Plugin Makefiles can now include a configuration file for compile time parameters (requested by Reinhard Nissl). The actual name of this file can be defined in Make.config (see PLGCFG in Make.config.template), and existing plugin Makefiles that have compile time parameters should add the lines PLGCFG = $(call PKGCFG,plgcfg) -include $(PLGCFG) accordingly (see the newplugin script for details). - Re-enabled building plugins that still use pre-version-1.7.34 Makefiles. The file Make.global is present again to satisfy the include these Makefiles do, but the file itself contains no settings. The VDR Makefile's plugins target determines whether a particular plugin uses an old style Makefile and calls it accordingly. Note that this only works when building plugins from within the VDR source tree, using make plugins in the VDR source directory. - Removed include from the DVBDIR setting in the VDR Makefile (reported by Oliver Endriss). You may need to adjust your DVBDIR setting in Make.config, in case you use it. - Added maximum SNR value for PCTV Systems PCTV 73ESE (thanks to Cedric Dewijs). Have fun! Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [DISCUSSION REQUEST] reintroduce a common make configuration file in VDR-1.7.35
Nice 33%!! Then tell me why was there no answer on the mailinglist thread. No answer = everything is ok -- send patch to Klaus 2012/12/30 Gerald Dachs v...@dachsweb.de: Am 30.12.2012 01:08, schrieb Christopher Reimer: I don't consider the mailinglist as central spot of developement. Here I'm forced to speak English. Almost all VDR Users are German. And in VDR-Portal I reach the critical mass. With the addition that I am allowed to speak my native language. What makes you believe that? Do you have any numbers? I don't have user counts either. I know that visitors of yavdr.org are not the same as vdr users, but they might be somehow related. Our statistics shows that the german group is with %67 of course the biggest, but far away from almost all. Gerald !DSPAM:50e02a13296741317615234! ___ 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] [DISCUSSION REQUEST] reintroduce a common make configuration file in VDR-1.7.35
von Vidar Tyldum vi...@tyldum.com Why are the majority of the users German - and why does it stay that way? Is it for the greater benefit of VDR? This is not the fault of the german users, VDR is historically a german speaking project, initiated by a german guy, used by the biggest VDR community, german, austrian and swiss people. I guess most of them don't feel save enough to write in english, they don't want to be blamed for not being nativ speaker and vdr-portal.de is far the better way to find information and solution. You should rather ask why the rest does not join this biggest VDR forum? There are a lot of people answering in english ... von Christopher Reimer c.reimer1...@gmail.com Then tell me why was there no answer on the mailinglist thread. Nobody did oversea the consquences and all are surprised due to this eat and die change, obviously initiated bottomline by one person. Again it is absolutely not against the change, it might be necessary, but not now and not in this way. I'm not anymore sure that VDR is a kind of community project, where here and there are thoughts about all participants. This number here reminds me more on George Orwells Animal Farm. Let 1.7.3x become a stable branch and postpone this change to the next development cycle. So, everybody does get time to get saddled for this change but with an HDTV capable fallback. === Kind regards fnu ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] adjust range of snr bar at bottom of vdr screen?
On Sun, Dec 30, 2012 at 10:41:48AM +0100, Klaus Schmidinger wrote:
On 30.12.2012 10:15, cedric.dew...@telfort.nl wrote:
Please send me a proper patch if you have any success with this.
Klaus
Hi Klaus,
I have not yet tested this, but the below code should work. I assume the
receiver has a snr of 0x to 0x00ff based on the following datapoints:
0x0080 almost never lock, unwatchable
0x0090 almost always lock, lots of disturbances
0x00A0 always lock, almost never disturbances
0x00D0 best signal ever received.
$ lsusb
Bus 001 Device 004: ID 2013:0245 PCTV Systems PCTV 73ESE
uint16_t MaxSnr = 0x; // Let's assume the default is using the entire
range.
// Use the subsystemId to identify individual devices in case they need
// special treatment to map their Snr value into the range 0...0x.
switch (subsystemId) {
case 0x13C21019: MaxSnr = 200; break; // TT-budget S2-3200
(DVB-S/DVB-S2)
case 0x20130245: MaxSnr = 0x00ff; break; //PCTV Systems PCTV 73ESE
}
int a = int(Snr) * 100 / MaxSnr;
int b = 100 - (Unc * 10 + (Ber / 256) * 5);
Sorry for not sending a proper patch as requested, I have not yet found the
time to test it properly.
No problem, I can easily insert this one-liner ;-).
Are you sure about the subsystemId? IIRC somebody claimed that these don't
apply to USB devices (which yours apparently is, since you did an lsusb).
Just wondering...
Klaus
Same maximum seems to be valid also for ID 2013:024f (PCTV Systems nanoStick T2
290e) also. Atleast I've never seen anything higher than 0x00F0. It is also USB
device though.
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] Betr: Re: adjust range of snr bar at bottom of vdr screen?
Are you sure about the subsystemId? IIRC somebody claimed that these don't apply to USB devices (which yours apparently is, since you did an lsusb). Just wondering... Klaus I am not sure. When I have time I'll build vdr with a strategic placed printf :-) Regards, Cedric ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [DISCUSSION REQUEST] reintroduce a common make configuration file in VDR-1.7.35
Am 30.12.2012 01:08, schrieb Christopher Reimer: 2012/12/29 Udo Richter udo_rich...@gmx.de: Even if there was an thread in vdr-portal, I did miss it, and there was no word of it in the mailing list, which I always considered to be the central spot of development. Really? http://linuxtv.org/pipermail/vdr/2012-November/026813.html There was NO answer at all. That was about a redundancy in Make.config and Make.global, and concludes to swap the include order of them. There's no word in it on dropping Make.config completely, and no word on introducing new mandatory make install targets or redefining the existing make all. I wonder why I didn't see that coming. ;) Cheers, Udo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Betr: Standardized DVB signal info up for review!
On Sun, Dec 30, 2012 at 12:27 AM, cedric.dew...@telfort.nl wrote: As many know, getting standardized dvb signal info in linux has been a want for a very long time for a lot of users (and developers). There has been several talks/threads about it but nothing was ever merged. The subject has come up once again and Mauro has posted a patch for review. I know that there are at least a handful of coders here who have interest in this, including Klaus. I strongly urge anyone who would like to see this finally happen to take a few minutes and read the links below. Further, it would be great if people actively participated in the discussion so please post anything you may like to contribute to the discussion! I have read the discussion. The kernel to userspace interface is not allowed to change, as this would brake userspace programs, so any fix would have to come from a new kernel side interface. Therefore at the VDR side we have two options: 1)Wait for the new kernel interface to happen with a standard way to report quality and strength. That's what this is about! 2)Implement work arounds for each receiver. In my opinion this has to be done anyway, in order to let VDR run on old kernel versions. You have to consider the benefit of this. Just because you technically _could_ make it work on ancient kernels, doesn't mean it's worth the time effort to do so. IMO, maintaining a bunch of workarounds is a total waste of time because there aren't enough users running ancient kernels to justify the work it takes to do this. I'm not scared of progress either. If using a newer version of VDR means using a newer kernel, so be it -- that's nothing to be scared of. Devs, users, or both are likely to experience growing pains for things to advance. The bar can't be so low that it doesn't exist. Minimum requirements aren't evil, sometimes they're necessary. Also, users have the option of using media_build for their drivers. Then they can use however old of a kernel media_build is backported to. That's more than reasonable if you ask me. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] [DISCUSSION REQUEST] reintroduce a common make configuration file in VDR-1.7.35
+1 ML is the most usable for French users, even if I understand a little bit German for my part, technical discussion is difficult to understand and google translator is funny sometimes applied to vdr portal. Regarding French forum having vdr section, regarding their technical skills, user build sources and plugins, most use pre builded yavdr packages and few needed but never discussed here plugins For my part, I will stay under 1.7.22 that works perfectly in HD with extended patch giving extension necessary in common use like cutterqueue, freesat epg, extended records menu etc etc .. and wait 2.0 to upgrade This is an advice of small French user Klaus, thanks for this nice piece of software, Keep the good job, I am very happy with my mediacenter based on vdr Thanks Le dimanche 30 décembre 2012 18:27:02, VDR User a écrit : On Sun, Dec 30, 2012 at 4:26 AM, fnu v...@auktion.hostingkunde.de wrote: Why are the majority of the users German - and why does it stay that way? Is it for the greater benefit of VDR? This is not the fault of the german users, VDR is historically a german speaking project, initiated by a german guy, used by the biggest VDR community, german, austrian and swiss people. I guess most of them don't feel save enough to write in english, they don't want to be blamed for not being nativ speaker and vdr-portal.de is far the better way to find information and solution. You should rather ask why the rest does not join this biggest VDR forum? There are a lot of people answering in english ... That's no mystery at all. When you go to vdrportal, easily the vast majority of posts are in german. That doesn't make it appear as an english-friendly forum and is an immediate turn-off. How are users supposed to search for what they're looking for? Maybe they should just ask the same questions over and over again, probably getting bashed for doing so and not searching the forum for previous answers to the same questions. Next, NA users tend to have questions regarding NA-specific issues, which german users tend to not have answers to since its not something they have to deal with. That's just two of the most common issues, but certainly not all of them. I know TONS of english-speaking users who have visited vdrportal and most of them haven't returned because the little sprinkles of english posts aren't enough to make them feel comfortable asking questions, getting answers, or feeling like a welcome visitor/member. And honestly, do germans want to have to keep translating everything for non-german users when they're asked? I doubt it. As good as vdrportal is as a VDR resource, the language barrier _is_ a problem for english speakers. As far as the mailing list, many users seem to think its for devs only and/or they don't have anything to contribute being users with nothing but questions. There are also many users who simply don't use mailing lists (or forums for that matter) either because they don't want to or because they think others will ask and they can just search for answers. I think it's unfortunate because if they did, people would have a better idea of the types of VDR users that exist, and further they would have some clue about how big non-german/non-european VDR communities exist. Everything above is all common and has been at least as long as my own VDR history started about 10 years ago. Keep in mind, even VDR itself wasn't even NA friendly for most of its existence. ___ 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] [DISCUSSION REQUEST] reintroduce a common make configuration file in VDR-1.7.35
As good as vdrportal is as a VDR resource, the language barrier _is_ a problem for english speakers. Same with this mailing list for german speakers ... and now? or feeling like a welcome visitor/member A little tale, if I'm in the US, I have to speak english all time. If my US friends do visit me or colleagues are staying in Germany, I also have to speak english all the time. They don't even try to speak my/our language while staying in Germany. And hey, don't think they ever welcomed me in german language ... ^^ This is just a chicken-and-egg problem, you all don't try to use it, so no information is collected or any kind of community will be set up. There is an rarly used international part, but if somebody does ask in english, she/he gets an answer in english, wherever postet. Time and patience could solve a lot, even losing shyness of nativ german speakers to answer in english, but this up to you all ... Unfortunately the search function of vdr-portal sucks IMHO, so in all languages, better use google w/ site:vdr-portal.de what-you-search-for. === Kind regards fnu ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [DISCUSSION REQUEST] reintroduce a common make configuration file in VDR-1.7.35
On Sun, Dec 30, 2012 at 3:54 PM, fnu v...@auktion.hostingkunde.de wrote: As good as vdrportal is as a VDR resource, the language barrier _is_ a problem for english speakers. Same with this mailing list for german speakers ... and now? I don't recall any german speakers ever expressing a problem that this mailing list is primarily english. Regardless of whether germans have a problem with this mailing list or not, I think it's certainly appropriate that it is primarily english for the simple fact english is a common language spoken by many non-english native speakers. There are many users and devs here from many different countries and thankfully they have english as a common means to communicate. My understanding is that english is taught as a multi-year requirement in many foreign countries. There are school districts here that require 2 years of foreign language, while most it's optional. Of the people who take foreign language, spanish is easily the first choice considering we have such a large hispanic population. Behind that is probably french, then japanese. German isn't very popular here I assume because we don't have many large german communities. or feeling like a welcome visitor/member A little tale, if I'm in the US, I have to speak english all time. If my US friends do visit me or colleagues are staying in Germany, I also have to speak english all the time. They don't even try to speak my/our language while staying in Germany. And hey, don't think they ever welcomed me in german language ... ^^ Personally I don't think it's much to ask to learn to greet a foreign friend in their native language but I guess your friends disagree. This is just a chicken-and-egg problem, you all don't try to use it, so no information is collected or any kind of community will be set up. There is an rarly used international part, but if somebody does ask in english, she/he gets an answer in english, wherever postet. Time and patience could solve a lot, even losing shyness of nativ german speakers to answer in english, but this up to you all ... I hope you don't misunderstand, I wasn't complaining that vdrportal isn't english-friendly. I was simply giving a few quick reasons why it _appears_ to be unfriendly for english speakers and why (we) don't use the site. It's the same reason why english speakers don't use the russian vdr forums, the french forums, the spanish forums, etc. Unfortunately vdrportal will never be a good home for english users in the same way those russian, french, spanish, etc. forums won't either. Look at how many of the actual english posts don't even have replies, or what little replies there are that don't actually help. It shouldn't be a wonder why you see tumbleweeds in the `international` section of vdrportal. That being said, (we) still manage to get VDR running thanks to the english-friendly forums that exist. Unfortunately the search function of vdr-portal sucks IMHO, so in all languages, better use google w/ site:vdr-portal.de what-you-search-for. If you speak german, I agree. If you speak english then this mailing list or one of the english forums are probably a better choice. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
