Re: [vdr] sequence of messages in xgettext/msgmerge
On 05/15/11 19:36, Dominic Evans wrote: On 15 May 2011 13:58, Klaus Schmidingerklaus.schmidin...@tvdr.de wrote: I'm just trying to build VDR on openSUSE 11.4, which comes with xgettext/msgmerge version 0.18.1. For some odd reason, when doing make i18n the sequence of the messages in the *.po files is completely different than before, which would cause a huge and unnecessary diff in the next developer version of VDR. Does anybody know if the gettext-tools have been broken at some point? Is there a way to get the previous sequence of messages back? FYI Ubuntu natty similar has 0.18.1 but doesn't change the order of messages in the .po files when doing make i18n (at least not on the 1.7.18 snapshot). Strange... I can't seem to make this beast generate the same *.po files as before the switch to openSUSE 11.4 :-( I guess I need to add the '-s' option to the xgettext call to make sure the sequence of texts doesn't depend on the sequence of the input files. Maybe should have done this from the very beginning... Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] sequence of messages in xgettext/msgmerge
On 05/21/11 13:45, Klaus Schmidinger wrote: On 05/15/11 19:36, Dominic Evans wrote: On 15 May 2011 13:58, Klaus Schmidingerklaus.schmidin...@tvdr.de wrote: I'm just trying to build VDR on openSUSE 11.4, which comes with xgettext/msgmerge version 0.18.1. For some odd reason, when doing make i18n the sequence of the messages in the *.po files is completely different than before, which would cause a huge and unnecessary diff in the next developer version of VDR. Does anybody know if the gettext-tools have been broken at some point? Is there a way to get the previous sequence of messages back? FYI Ubuntu natty similar has 0.18.1 but doesn't change the order of messages in the .po files when doing make i18n (at least not on the 1.7.18 snapshot). Strange... I can't seem to make this beast generate the same *.po files as before the switch to openSUSE 11.4 :-( I guess I need to add the '-s' option to the xgettext call to make sure the sequence of texts doesn't depend on the sequence of the input files. Maybe should have done this from the very beginning... Well, that was not such a good idea, because it sorts all texts and doesn't keep them together locally as before. Turned out using --- Makefile2011/04/17 13:35:53 2.17 +++ Makefile2011/05/21 12:21:40 @@ -115,7 +115,7 @@ msgfmt -c -o $@ $ $(I18Npot): $(wildcard *.c) - xgettext -C -cTRANSLATORS --no-wrap --no-location -k -ktr -ktrNOOP --package-name=VDR --package-version=$(VDRVERSION) --msgid-bugs-address='vdr-b...@tvdr.de' -o $@ $^ + xgettext -C -cTRANSLATORS --no-wrap --no-location -k -ktr -ktrNOOP --package-name=VDR --package-version=$(VDRVERSION) --msgid-bugs-address='vdr-b...@tvdr.de' -o $@ `ls $^` %.po: $(I18Npot) msgmerge -U --no-wrap --no-location --backup=none -q $@ $ (i.e. sorting the source file names with 'ls') did the trick. Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] wrong index/info in HD 1080i recordings since with 1.7.18
hi Klaus i have the following problem, i've updated my vdr server from 1.7.16 to the new version 1.7.18. If i record Sky Cinema or any other Sky HD channel the information for frames per second in info file is different to 1.7.16 (ok you changed this behavior in 1.7.17) Sky HD recording (1080i) - original index and info with F 50 line. Cutting marks can be moved, but output isn't refreshed. Fast forward/backward works without artifacts. - recreate index (1.7.18) with F 25/F 50 in info and without info, works same index file as with 1.7.16. cutting marks can be moved. Fast forward/backward works without artifacts. Generated index has half of size then orginal one. HD with 720p like Das Erste HD or ZDF HD is ok. With old recordings from 1.7.16 i have to regenerate index file as you described in HISTORY file. cu Gerald ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] wrong index/info in HD 1080i recordings since with 1.7.18
hi Klaus i have the following problem, i've updated my vdr server from 1.7.16 to the new version 1.7.18. If i record Sky Cinema or any other Sky HD channel the information for frames per second in info file is different to 1.7.16 (ok you changed this behavior in 1.7.17) Sky HD recording (1080i) - original index and info with F 50 line. Cutting marks can be moved, but output isn't refreshed. Fast forward/backward works without artifacts. - recreate index (1.7.18) with F 25/F 50 in info and without info, works same index file as with 1.7.16. cutting marks can be moved. Fast forward/backward works without artifacts. Generated index has half of size then orginal one. HD with 720p like Das Erste HD or ZDF HD is ok. With old recordings from 1.7.16 i have to regenerate index file as you described in HISTORY file. cu Gerald ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] dvb-s(2) NumProvidedSystems() vs reelchannelscan
On 05/07/11 20:11, Juergen Lock wrote:
Hi!
There seems to be a change in recent vdr versions regarding
NumProvidedSystems() which at least the reelchannelscan plugin
uses to tell apart a dvb-s2 tuner from a dvb-s one in a few places,
apparently it used to return 2 for a dvb-s2 tuner and now returns 3.
Is this intentional?
Yes, it is.
2010-06-06: Version 1.7.15
...
- The various modulation types are now taken into account when selecting a
device for
a recording or live viewing, so that devices that provide more capabilities
are
spared.
This was done by incrementing numProvidedSystems in cDvbDevice::cDvbDevice()
for every additional modulation type it provides.
I'm afraid the result from NumProvidedSystems() is in no way suitable
for determining whether the device is DVB-S or DVB-S2.
Klaus
I patched reelchannelscan like below: (would need to check the
vdr version to be general of course, this was for 1.7.18; symptom
was a manual scan wrote out qam32 modulation into the channels.conf
instead of qpsk and of course vdr couldn't tune the new channel(s).)
Thanx!
Juergen
--- a/csmenu.c
+++ b/csmenu.c
@@ -243,7 +243,7 @@ void cMenuChannelscan::TunerDetection()
txtstream tr(DVB-C - Cable) ( tr(Tuner) ' '
tuner + 1 ')';
stp = CABLE;
} else if (device-ProvidesSource(cSource::stSat)) {
-if (device-NumProvidedSystems() == 2) {
+if (device-NumProvidedSystems() == 3) {
//if(TunerIsRotor(tuner))
// txtstream tr(DVB-S2 - Rotor) ( tr(Tuner) '
' tuner + 1 ')';
//else
--- a/scan.c
+++ b/scan.c
@@ -421,7 +421,7 @@ void cScan::ScanNitServices()
void cScan::ScanDVB_S(cTransponder * tp, cChannel * c)
{
//const time_t tt = time(NULL);
- int maxmods = device-NumProvidedSystems() == 2? 4 : 2;
+ int maxmods = device-NumProvidedSystems() == 3? 4 : 2;
// esyslog(%s cTransponder* tp = %x cChannel *c = %x,
__PRETTY_FUNCTION__);
esyslog(maxmods = %d,maxmods);
@@ -431,7 +431,7 @@ void cScan::ScanDVB_S(cTransponder * tp,
;
// skip HD Transonders on SD Tuner
-if ( !device-NumProvidedSystems() == 2 static_cast cSatTransponder
*(tp)-System() == 1)
+if ( !device-NumProvidedSystems() == 3 static_cast cSatTransponder
*(tp)-System() == 1)
return;
unsigned int nRadio = radioChannelNames.size();
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] wrong index/info in HD 1080i recordings since with 1.7.18
On 05/21/11 16:01, Gerald Raaf wrote: hi Klaus i have the following problem, i've updated my vdr server from 1.7.16 to the new version 1.7.18. If i record Sky Cinema or any other Sky HD channel the information for frames per second in info file is different to 1.7.16 (ok you changed this behavior in 1.7.17) Sky HD recording (1080i) - original index and info with F 50 line. Cutting marks can be moved, but output isn't refreshed. Fast forward/backward works without artifacts. - recreate index (1.7.18) with F 25/F 50 in info and without info, works same index file as with 1.7.16. cutting marks can be moved. Fast forward/backward works without artifacts. Generated index has half of size then orginal one. HD with 720p like Das Erste HD or ZDF HD is ok. With old recordings from 1.7.16 i have to regenerate index file as you described in HISTORY file. Hello Gerald, I'm afraid I don't see where exactly your problem is... Can you be more specific? Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] diseqc errors
On 04/25/11 23:37, Marco Göbenich wrote: Hi! Forgot to say that I'm using vdr-1.6 with TechniSat Gigaswitch 9/20. Regards Marco Am 25.04.2011 23:25, schrieb Marco Göbenich: Hi! I get the following errors: Apr 25 22:22:56 vdr10 vdr: [7893] ERROR: too many codes in code sequence '[E0 10 38 F0] W15 A W15 t' Apr 25 22:25:44 vdr10 vdr: [7890] ERROR: too many codes in code sequence '[E0 10 38 F6] W15 B W15 t' Apr 25 22:25:44 vdr10 vdr: [7893] ERROR: too many codes in code sequence '[E0 10 38 F6] W15 B W15 t' Apr 25 22:40:36 vdr10 vdr: [7896] ERROR: too many codes in code sequence '[E0 10 38 F5] W15 B W15 T' Apr 25 22:46:45 vdr10 vdr: [7890] ERROR: too many codes in code sequence '[E0 10 38 F6] W15 B W15 t' Apr 25 22:52:21 vdr10 vdr: [7893] ERROR: too many codes in code sequence '[E0 10 38 F3] W15 A W15 T' Apr 25 23:19:42 vdr10 vdr: [7893] ERROR: too many codes in code sequence '[E0 10 38 F7] W15 B W15 T' No Problems with recordings so far, but my diseqc.conf is from the wiki and I don't know how to solve this.. my diseqc.conf: S19.2E 11700 V 9750 t v W15 [E0 10 38 F0] W15 A W15 t S19.2E 9 V 10600 t v W15 [E0 10 38 F1] W15 A W15 T S19.2E 11700 H 9750 t V W15 [E0 10 38 F2] W15 A W15 t S19.2E 9 H 10600 t V W15 [E0 10 38 F3] W15 A W15 T S13.0E 11700 V 9750 t v W15 [E0 10 38 F4] W15 B W15 t S13.0E 9 V 10600 t v W15 [E0 10 38 F5] W15 B W15 T S13.0E 11700 H 9750 t V W15 [E0 10 38 F6] W15 B W15 t S13.0E 9 H 10600 t V W15 [E0 10 38 F7] W15 B W15 T I can't see why this error would occur, your diseqc.conf looks fine. Is your diseqc.h or diseqc.c source file patched in any way? KlAUS ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] wrong index/info in HD 1080i recordings since with 1.7.18
On 05/21/11 16:23, Gerald Raaf wrote: Am Samstag, den 21.05.2011, 16:08 +0200 schrieb Klaus Schmidinger: On 05/21/11 16:01, Gerald Raaf wrote: hi Klaus i have the following problem, i've updated my vdr server from 1.7.16 to the new version 1.7.18. If i record Sky Cinema or any other Sky HD channel the information for frames per second in info file is different to 1.7.16 (ok you changed this behavior in 1.7.17) Sky HD recording (1080i) - original index and info with F 50 line. Cutting marks can be moved, but output isn't refreshed. Fast forward/backward works without artifacts. - recreate index (1.7.18) with F 25/F 50 in info and without info, works same index file as with 1.7.16. cutting marks can be moved. Fast forward/backward works without artifacts. Generated index has half of size then orginal one. HD with 720p like Das Erste HD or ZDF HD is ok. With old recordings from 1.7.16 i have to regenerate index file as you described in HISTORY file. Hello Gerald, I'm afraid I don't see where exactly your problem is... Can you be more specific? Klaus Hi Klaus, i set a cutting mark, it isn't exactly where it should be so i want to move it with key 4 or 6, i can see that the mark move but output on TV isn't updated you always have the picture where i've set the first mark. after recreating the index file everthing works as expected. The recreated index file has only half of size from orignal created. I thought Sky broadcasts 1080i with 25fps and not 50fps. So the generated index/info files from this recordings are wrong. Regenerating the index file doesn't modifiy the 'info' file of the recording. Maybe that's the problem here. Is it ok for completely new recordings? Does it work if you manually change the F record in the info file to 25? Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] wrong index/info in HD 1080i recordings since with 1.7.18
Am Samstag, den 21.05.2011, 16:29 +0200 schrieb Klaus Schmidinger: On 05/21/11 16:23, Gerald Raaf wrote: Am Samstag, den 21.05.2011, 16:08 +0200 schrieb Klaus Schmidinger: On 05/21/11 16:01, Gerald Raaf wrote: hi Klaus i have the following problem, i've updated my vdr server from 1.7.16 to the new version 1.7.18. If i record Sky Cinema or any other Sky HD channel the information for frames per second in info file is different to 1.7.16 (ok you changed this behavior in 1.7.17) Sky HD recording (1080i) - original index and info with F 50 line. Cutting marks can be moved, but output isn't refreshed. Fast forward/backward works without artifacts. - recreate index (1.7.18) with F 25/F 50 in info and without info, works same index file as with 1.7.16. cutting marks can be moved. Fast forward/backward works without artifacts. Generated index has half of size then orginal one. HD with 720p like Das Erste HD or ZDF HD is ok. With old recordings from 1.7.16 i have to regenerate index file as you described in HISTORY file. Hello Gerald, I'm afraid I don't see where exactly your problem is... Can you be more specific? Klaus Hi Klaus, i set a cutting mark, it isn't exactly where it should be so i want to move it with key 4 or 6, i can see that the mark move but output on TV isn't updated you always have the picture where i've set the first mark. after recreating the index file everthing works as expected. The recreated index file has only half of size from orignal created. I thought Sky broadcasts 1080i with 25fps and not 50fps. So the generated index/info files from this recordings are wrong. Regenerating the index file doesn't modifiy the 'info' file of the recording. Maybe that's the problem here. no only regenerate and change F record those solve the problem, forget to tell this. Is it ok for completely new recordings? no this are new recordings with 1.7.18 Does it work if you manually change the F record in the info file to 25? same behaviour but movie length is not 2h but 1h Klaus ___ 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] wrong index/info in HD 1080i recordings since with 1.7.18
On 05/21/11 16:38, Gerald Raaf wrote: Am Samstag, den 21.05.2011, 16:29 +0200 schrieb Klaus Schmidinger: On 05/21/11 16:23, Gerald Raaf wrote: Am Samstag, den 21.05.2011, 16:08 +0200 schrieb Klaus Schmidinger: On 05/21/11 16:01, Gerald Raaf wrote: hi Klaus i have the following problem, i've updated my vdr server from 1.7.16 to the new version 1.7.18. If i record Sky Cinema or any other Sky HD channel the information for frames per second in info file is different to 1.7.16 (ok you changed this behavior in 1.7.17) Sky HD recording (1080i) - original index and info with F 50 line. Cutting marks can be moved, but output isn't refreshed. Fast forward/backward works without artifacts. - recreate index (1.7.18) with F 25/F 50 in info and without info, works same index file as with 1.7.16. cutting marks can be moved. Fast forward/backward works without artifacts. Generated index has half of size then orginal one. HD with 720p like Das Erste HD or ZDF HD is ok. With old recordings from 1.7.16 i have to regenerate index file as you described in HISTORY file. Hello Gerald, I'm afraid I don't see where exactly your problem is... Can you be more specific? Klaus Hi Klaus, i set a cutting mark, it isn't exactly where it should be so i want to move it with key 4 or 6, i can see that the mark move but output on TV isn't updated you always have the picture where i've set the first mark. after recreating the index file everthing works as expected. The recreated index file has only half of size from orignal created. I thought Sky broadcasts 1080i with 25fps and not 50fps. So the generated index/info files from this recordings are wrong. Regenerating the index file doesn't modifiy the 'info' file of the recording. Maybe that's the problem here. no only regenerate and change F record those solve the problem, forget to tell this. Is it ok for completely new recordings? no this are new recordings with 1.7.18 Does it work if you manually change the F record in the info file to 25? same behaviour but movie length is not 2h but 1h Maybe you should contact me via PM, so we could further discuss this... Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] dvb-s(2) NumProvidedSystems() vs reelchannelscan
In article 4dd7c61e.8060...@tvdr.de you write: On 05/07/11 20:11, Juergen Lock wrote: Hi! There seems to be a change in recent vdr versions regarding NumProvidedSystems() which at least the reelchannelscan plugin uses to tell apart a dvb-s2 tuner from a dvb-s one in a few places, apparently it used to return 2 for a dvb-s2 tuner and now returns 3. Is this intentional? Yes, it is. 2010-06-06: Version 1.7.15 ... - The various modulation types are now taken into account when selecting a device for a recording or live viewing, so that devices that provide more capabilities are spared. This was done by incrementing numProvidedSystems in cDvbDevice::cDvbDevice() for every additional modulation type it provides. Ah I see. Curious, what is the third modulation used on dvb-s(2) in addition to qpsk and 8psk? I'm afraid the result from NumProvidedSystems() is in no way suitable for determining whether the device is DVB-S or DVB-S2. Ok so what would then be the recommended way? Wondering... :) Juergen ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] dvb-s(2) NumProvidedSystems() vs reelchannelscan
On 05/21/11 16:55, Juergen Lock wrote: In article4dd7c61e.8060...@tvdr.de you write: On 05/07/11 20:11, Juergen Lock wrote: Hi! There seems to be a change in recent vdr versions regarding NumProvidedSystems() which at least the reelchannelscan plugin uses to tell apart a dvb-s2 tuner from a dvb-s one in a few places, apparently it used to return 2 for a dvb-s2 tuner and now returns 3. Is this intentional? Yes, it is. 2010-06-06: Version 1.7.15 ... - The various modulation types are now taken into account when selecting a device for a recording or live viewing, so that devices that provide more capabilities are spared. This was done by incrementing numProvidedSystems in cDvbDevice::cDvbDevice() for every additional modulation type it provides. Ah I see. Curious, what is the third modulation used on dvb-s(2) in addition to qpsk and 8psk? Originally it was just 2 for DVB-S and DVB-S2. Then somebody came up with the request that the various FE_CAN_... flags should also be taken into account when trying to spare devices with more capabilities than others. The whole idea behind NumProvidedSystems() is just to have a way of deciding which device to use for recording if they are otherwise equivalent. One with more capabilities should be preserved in case an other channel requires those. The actual value of NumProvidedSystems() has no real meaning. It's just more or less. I'm afraid the result from NumProvidedSystems() is in no way suitable for determining whether the device is DVB-S or DVB-S2. Ok so what would then be the recommended way? I'm afraid there is none - at least at the moment. I'm thinking about giving cDevice a function that returns a bit masked value, identifying the delivery systems it provides. Probably using the fe_delivery_system_t constants from the LinuxDVB API. Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] wrong index/info in HD 1080i recordings since with 1.7.18
Am Samstag, den 21.05.2011, 16:43 +0200 schrieb Klaus Schmidinger: On 05/21/11 16:38, Gerald Raaf wrote: Am Samstag, den 21.05.2011, 16:29 +0200 schrieb Klaus Schmidinger: On 05/21/11 16:23, Gerald Raaf wrote: Am Samstag, den 21.05.2011, 16:08 +0200 schrieb Klaus Schmidinger: On 05/21/11 16:01, Gerald Raaf wrote: hi Klaus i have the following problem, i've updated my vdr server from 1.7.16 to the new version 1.7.18. If i record Sky Cinema or any other Sky HD channel the information for frames per second in info file is different to 1.7.16 (ok you changed this behavior in 1.7.17) Sky HD recording (1080i) - original index and info with F 50 line. Cutting marks can be moved, but output isn't refreshed. Fast forward/backward works without artifacts. - recreate index (1.7.18) with F 25/F 50 in info and without info, works same index file as with 1.7.16. cutting marks can be moved. Fast forward/backward works without artifacts. Generated index has half of size then orginal one. HD with 720p like Das Erste HD or ZDF HD is ok. With old recordings from 1.7.16 i have to regenerate index file as you described in HISTORY file. Hello Gerald, I'm afraid I don't see where exactly your problem is... Can you be more specific? Klaus Hi Klaus, i set a cutting mark, it isn't exactly where it should be so i want to move it with key 4 or 6, i can see that the mark move but output on TV isn't updated you always have the picture where i've set the first mark. after recreating the index file everthing works as expected. The recreated index file has only half of size from orignal created. I thought Sky broadcasts 1080i with 25fps and not 50fps. So the generated index/info files from this recordings are wrong. Regenerating the index file doesn't modifiy the 'info' file of the recording. Maybe that's the problem here. no only regenerate and change F record those solve the problem, forget to tell this. Is it ok for completely new recordings? no this are new recordings with 1.7.18 Does it work if you manually change the F record in the info file to 25? same behaviour but movie length is not 2h but 1h Maybe you should contact me via PM, so we could further discuss this... Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr pm send ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] diseqc errors
Hi! No, checked against vanilla vdr-1.6-0, diseq.c and diseq.h are not modified. I looked again in the logs and it seems that this happens when a epg scan is triggered, all entries seem to occur on times when there are free devices. Regards Marco Am 21.05.2011 16:26, schrieb Klaus Schmidinger: On 04/25/11 23:37, Marco Göbenich wrote: Hi! Forgot to say that I'm using vdr-1.6 with TechniSat Gigaswitch 9/20. Regards Marco Am 25.04.2011 23:25, schrieb Marco Göbenich: Hi! I get the following errors: Apr 25 22:22:56 vdr10 vdr: [7893] ERROR: too many codes in code sequence '[E0 10 38 F0] W15 A W15 t' Apr 25 22:25:44 vdr10 vdr: [7890] ERROR: too many codes in code sequence '[E0 10 38 F6] W15 B W15 t' Apr 25 22:25:44 vdr10 vdr: [7893] ERROR: too many codes in code sequence '[E0 10 38 F6] W15 B W15 t' Apr 25 22:40:36 vdr10 vdr: [7896] ERROR: too many codes in code sequence '[E0 10 38 F5] W15 B W15 T' Apr 25 22:46:45 vdr10 vdr: [7890] ERROR: too many codes in code sequence '[E0 10 38 F6] W15 B W15 t' Apr 25 22:52:21 vdr10 vdr: [7893] ERROR: too many codes in code sequence '[E0 10 38 F3] W15 A W15 T' Apr 25 23:19:42 vdr10 vdr: [7893] ERROR: too many codes in code sequence '[E0 10 38 F7] W15 B W15 T' No Problems with recordings so far, but my diseqc.conf is from the wiki and I don't know how to solve this.. my diseqc.conf: S19.2E 11700 V 9750 t v W15 [E0 10 38 F0] W15 A W15 t S19.2E 9 V 10600 t v W15 [E0 10 38 F1] W15 A W15 T S19.2E 11700 H 9750 t V W15 [E0 10 38 F2] W15 A W15 t S19.2E 9 H 10600 t V W15 [E0 10 38 F3] W15 A W15 T S13.0E 11700 V 9750 t v W15 [E0 10 38 F4] W15 B W15 t S13.0E 9 V 10600 t v W15 [E0 10 38 F5] W15 B W15 T S13.0E 11700 H 9750 t V W15 [E0 10 38 F6] W15 B W15 t S13.0E 9 H 10600 t V W15 [E0 10 38 F7] W15 B W15 T I can't see why this error would occur, your diseqc.conf looks fine. Is your diseqc.h or diseqc.c source file patched in any way? KlAUS ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr -- Needful GbR Rheinstraße 60a Telefon +49 (0) 26 24 / 95 29 301 56203 Höhr-Grenzhausen Telefax +49 (0) 26 24 / 95 29 303 http://www.needful.deE-Mail m...@needful.de ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] diseqc errors
On 21.05.2011 23:51, Marco Göbenich wrote:
Hi!
No, checked against vanilla vdr-1.6-0, diseq.c and diseq.h are not modified.
I looked again in the logs and it seems that this happens when a epg scan is
triggered, all entries seem to occur on times when there are free devices.
Sounds like two threads are accessing a cDiseqc object at the same time.
For a quick test, can you please try adding the following two lines:
char *cDiseqc::Codes(char *s)
{
static cMutex Mutex; //ADD
cMutexLock MutexLock(Mutex); //ADD
char *e = strchr(s, ']');
Klaus
Am 21.05.2011 16:26, schrieb Klaus Schmidinger:
On 04/25/11 23:37, Marco Göbenich wrote:
Hi!
Forgot to say that I'm using vdr-1.6 with TechniSat Gigaswitch 9/20.
Regards
Marco
Am 25.04.2011 23:25, schrieb Marco Göbenich:
Hi!
I get the following errors:
Apr 25 22:22:56 vdr10 vdr: [7893] ERROR: too many codes in code sequence '[E0
10 38 F0] W15 A W15 t'
Apr 25 22:25:44 vdr10 vdr: [7890] ERROR: too many codes in code sequence '[E0
10 38 F6] W15 B W15 t'
Apr 25 22:25:44 vdr10 vdr: [7893] ERROR: too many codes in code sequence '[E0
10 38 F6] W15 B W15 t'
Apr 25 22:40:36 vdr10 vdr: [7896] ERROR: too many codes in code sequence '[E0
10 38 F5] W15 B W15 T'
Apr 25 22:46:45 vdr10 vdr: [7890] ERROR: too many codes in code sequence '[E0
10 38 F6] W15 B W15 t'
Apr 25 22:52:21 vdr10 vdr: [7893] ERROR: too many codes in code sequence '[E0
10 38 F3] W15 A W15 T'
Apr 25 23:19:42 vdr10 vdr: [7893] ERROR: too many codes in code sequence '[E0
10 38 F7] W15 B W15 T'
No Problems with recordings so far, but my diseqc.conf is from the wiki
and I don't know how to solve this..
my diseqc.conf:
S19.2E 11700 V 9750 t v W15 [E0 10 38 F0] W15 A W15 t
S19.2E 9 V 10600 t v W15 [E0 10 38 F1] W15 A W15 T
S19.2E 11700 H 9750 t V W15 [E0 10 38 F2] W15 A W15 t
S19.2E 9 H 10600 t V W15 [E0 10 38 F3] W15 A W15 T
S13.0E 11700 V 9750 t v W15 [E0 10 38 F4] W15 B W15 t
S13.0E 9 V 10600 t v W15 [E0 10 38 F5] W15 B W15 T
S13.0E 11700 H 9750 t V W15 [E0 10 38 F6] W15 B W15 t
S13.0E 9 H 10600 t V W15 [E0 10 38 F7] W15 B W15 T
I can't see why this error would occur, your diseqc.conf looks fine.
Is your diseqc.h or diseqc.c source file patched in any way?
KlAUS
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
