Hi!
VDR constantly changes the frequency of one multiplex in DVB-T.
Here's an example: Correct: Urheilukanava;Suomen Urheilutelevisio Oy:770000000:C23D23M64B8T8G8Y0:T:27500:417+130:673=fin:929:0:113:8438:12289:0
But then VDR decides to change it:
Dec 29 18:32:48 delta vdr[18069]: changing transponder data of channel 22 from T:770000000:0:3:0:2:2:2:1 to T:674000000:0:3:0:2:2:2:1
And then of course the channels stop being watchable.
I took a dvbsnoop on PID 16 to grab the NIT tables (or whatever they're called). The two SECT-packets which are looped in the PID 16 are both in: http://anssi.hopto.org/dvbsnoop-MUX3-pid16
BTW, I put a debug output entry in nit.c line 173 to grab the frequency returned by getFrequency(), and I get these kind of results: FREQUENCY, 562000000 FREQUENCY, 658000000 FREQUENCY, 674000000
However the correct frequencies of the muxes are 490000, 578000, and 770000. However I've no idea why mux3 is the only one of which frequency VDR tries to change.
Anssi Hannula wrote:
Hi!
VDR constantly changes the frequency of one multiplex in DVB-T.
Here's an example: Correct: Urheilukanava;Suomen Urheilutelevisio Oy:770000000:C23D23M64B8T8G8Y0:T:27500:417+130:673=fin:929:0:113:8438:12289:0
But then VDR decides to change it:
Dec 29 18:32:48 delta vdr[18069]: changing transponder data of channel 22 from T:770000000:0:3:0:2:2:2:1 to T:674000000:0:3:0:2:2:2:1
And then of course the channels stop being watchable.
I took a dvbsnoop on PID 16 to grab the NIT tables (or whatever they're called). The two SECT-packets which are looped in the PID 16 are both in: http://anssi.hopto.org/dvbsnoop-MUX3-pid16
BTW, I put a debug output entry in nit.c line 173 to grab the frequency returned by getFrequency(), and I get these kind of results: FREQUENCY, 562000000 FREQUENCY, 658000000 FREQUENCY, 674000000
However the correct frequencies of the muxes are 490000, 578000, and 770000. However I've no idea why mux3 is the only one of which frequency VDR tries to change.
@Klaus, are you going to investigate this?
Anssi Hannula wrote:
Anssi Hannula wrote:
Hi!
VDR constantly changes the frequency of one multiplex in DVB-T.
Here's an example: Correct: Urheilukanava;Suomen Urheilutelevisio Oy:770000000:C23D23M64B8T8G8Y0:T:27500:417+130:673=fin:929:0:113:8438:12289:0
But then VDR decides to change it:
Dec 29 18:32:48 delta vdr[18069]: changing transponder data of channel 22 from T:770000000:0:3:0:2:2:2:1 to T:674000000:0:3:0:2:2:2:1
And then of course the channels stop being watchable.
I took a dvbsnoop on PID 16 to grab the NIT tables (or whatever they're called). The two SECT-packets which are looped in the PID 16 are both in: http://anssi.hopto.org/dvbsnoop-MUX3-pid16
BTW, I put a debug output entry in nit.c line 173 to grab the frequency returned by getFrequency(), and I get these kind of results: FREQUENCY, 562000000 FREQUENCY, 658000000 FREQUENCY, 674000000
However the correct frequencies of the muxes are 490000, 578000, and 770000. However I've no idea why mux3 is the only one of which frequency VDR tries to change.
@Klaus, are you going to investigate this?
Well, it's certainly easier to debug if one can actually receive these channels and run tests with live data. Since I don't have DVB-T (and certainly can't receive these channels) I'd appreciate if somebody else could look into this.
Klaus
I've now had time to debug this bug more, too.
Klaus Schmidinger wrote:
Anssi Hannula wrote:
Anssi Hannula wrote:
Hi!
VDR constantly changes the frequency of one multiplex in DVB-T.
Here's an example: Correct: Urheilukanava;Suomen Urheilutelevisio Oy:770000000:C23D23M64B8T8G8Y0:T:27500:417+130:673=fin:929:0:113:8438:12289:0
But then VDR decides to change it:
Dec 29 18:32:48 delta vdr[18069]: changing transponder data of channel 22 from T:770000000:0:3:0:2:2:2:1 to T:674000000:0:3:0:2:2:2:1
And then of course the channels stop being watchable.
I took a dvbsnoop on PID 16 to grab the NIT tables (or whatever they're called). The two SECT-packets which are looped in the PID 16 are both in: http://anssi.hopto.org/dvbsnoop-MUX3-pid16
BTW, I put a debug output entry in nit.c line 173 to grab the frequency returned by getFrequency(), and I get these kind of results: FREQUENCY, 562000000 FREQUENCY, 658000000 FREQUENCY, 674000000
However the correct frequencies of the muxes are 490000, 578000, and 770000. However I've no idea why mux3 is the only one of which frequency VDR tries to change.
The NIT data (pid 16) of Finnish DVB-T operated by Digita apparently confuses VDR:
The center frequency advertised in the terrestrial_delivery_system_descriptor is not necessarily the real frequency, but other_frequency_flag is set to "1" and there is provided a frequency_list_descriptor which contains all the possible frequencies of this mux (probably nation-wide), and the correct frequency is one of those.
Digita also sends NITs of all muxes in all muxes, and as VDR relies on frequencies to detect which on of those is the correct one, the detection fails and VDR always selects the NIT of mux 3, explaining why it that mux is the only one affected by the frequency-changing.
For the NIT selection problem I can think of these possible fixes:
1. Fix the NIT selection in cNitFilter::Process() so that it would search the frequency_list_descriptor too.
2. Change the NIT selection in cNitFilter::Process() to use TID instead of frequency to select the correct NIT.
And for the channel frequency update:
1. When considering frequency update for a channel, check first if the previous frequency is one of the frequencies in frequency_list_descriptor.
2. Ignore frequency when updating channels if other_frequency_flag is set to "1" in terrestrial_delivery_system_descriptor.
After a quick look it seems that libsi has support for frequency_list_descriptor.
If you want to see the actual NIT data, it's there: http://stuff.onse.fi/digita-nit/
Note that the other_frequency_flag is DVB-T-specific.
@Klaus, are you going to investigate this?
Well, it's certainly easier to debug if one can actually receive these channels and run tests with live data. Since I don't have DVB-T (and certainly can't receive these channels) I'd appreciate if somebody else could look into this.
It would be nice if you had time to implement fixes for the above problems. If you don't, please indicate what kind of fixes would you prefer, maybe I'll find time to implement them someday.
Anssi Hannula wrote:
I've now had time to debug this bug more, too.
Klaus Schmidinger wrote:
Anssi Hannula wrote:
Anssi Hannula wrote:
Hi!
VDR constantly changes the frequency of one multiplex in DVB-T.
Here's an example: Correct: Urheilukanava;Suomen Urheilutelevisio Oy:770000000:C23D23M64B8T8G8Y0:T:27500:417+130:673=fin:929:0:113:8438:12289:0
But then VDR decides to change it:
Dec 29 18:32:48 delta vdr[18069]: changing transponder data of channel 22 from T:770000000:0:3:0:2:2:2:1 to T:674000000:0:3:0:2:2:2:1
And then of course the channels stop being watchable.
I took a dvbsnoop on PID 16 to grab the NIT tables (or whatever they're called). The two SECT-packets which are looped in the PID 16 are both in: http://anssi.hopto.org/dvbsnoop-MUX3-pid16
BTW, I put a debug output entry in nit.c line 173 to grab the frequency returned by getFrequency(), and I get these kind of results: FREQUENCY, 562000000 FREQUENCY, 658000000 FREQUENCY, 674000000
However the correct frequencies of the muxes are 490000, 578000, and 770000. However I've no idea why mux3 is the only one of which frequency VDR tries to change.
The NIT data (pid 16) of Finnish DVB-T operated by Digita apparently confuses VDR:
The center frequency advertised in the terrestrial_delivery_system_descriptor is not necessarily the real frequency, but other_frequency_flag is set to "1" and there is provided a frequency_list_descriptor which contains all the possible frequencies of this mux (probably nation-wide), and the correct frequency is one of those.
Digita also sends NITs of all muxes in all muxes, and as VDR relies on frequencies to detect which on of those is the correct one, the detection fails and VDR always selects the NIT of mux 3, explaining why it that mux is the only one affected by the frequency-changing.
For the NIT selection problem I can think of these possible fixes:
- Fix the NIT selection in cNitFilter::Process() so that it would
search the frequency_list_descriptor too.
- Change the NIT selection in cNitFilter::Process() to use TID instead
of frequency to select the correct NIT.
And for the channel frequency update:
- When considering frequency update for a channel, check first if the
previous frequency is one of the frequencies in frequency_list_descriptor.
- Ignore frequency when updating channels if other_frequency_flag is
set to "1" in terrestrial_delivery_system_descriptor.
After a quick look it seems that libsi has support for frequency_list_descriptor.
If you want to see the actual NIT data, it's there: http://stuff.onse.fi/digita-nit/
Note that the other_frequency_flag is DVB-T-specific.
@Klaus, are you going to investigate this?
Well, it's certainly easier to debug if one can actually receive these channels and run tests with live data. Since I don't have DVB-T (and certainly can't receive these channels) I'd appreciate if somebody else could look into this.
It would be nice if you had time to implement fixes for the above problems. If you don't, please indicate what kind of fixes would you prefer, maybe I'll find time to implement them someday.
Well, I guess it would be best if you give it a shot, since you have the data stream necessary for testing this.
Klaus
Klaus Schmidinger wrote:
Anssi Hannula wrote:
I've now had time to debug this bug more, too.
Anssi Hannula wrote:
Hi!
VDR constantly changes the frequency of one multiplex in DVB-T.
Here's an example: Correct: Urheilukanava;Suomen Urheilutelevisio Oy:770000000:C23D23M64B8T8G8Y0:T:27500:417+130:673=fin:929:0:113:8438:12289:0
But then VDR decides to change it:
Dec 29 18:32:48 delta vdr[18069]: changing transponder data of channel 22 from T:770000000:0:3:0:2:2:2:1 to T:674000000:0:3:0:2:2:2:1
And then of course the channels stop being watchable.
The NIT data (pid 16) of Finnish DVB-T operated by Digita apparently confuses VDR:
The center frequency advertised in the terrestrial_delivery_system_descriptor is not necessarily the real frequency, but other_frequency_flag is set to "1" and there is provided a frequency_list_descriptor which contains all the possible frequencies of this mux (probably nation-wide), and the correct frequency is one of those.
Digita also sends NITs of all muxes in all muxes, and as VDR relies on frequencies to detect which on of those is the correct one, the detection fails and VDR always selects the NIT of mux 3, explaining why it that mux is the only one affected by the frequency-changing.
After a quick look it seems that libsi has support for frequency_list_descriptor.
If you want to see the actual NIT data, it's there: http://stuff.onse.fi/digita-nit/
Note that the other_frequency_flag is DVB-T-specific.
Well, I guess it would be best if you give it a shot, since you have the data stream necessary for testing this.
Okay, attached is a patch for nit.c that checks for all the frequencies in frequency_list_descriptor for the channel's frequency and if found, use it so that channel's frequency is not changed.
Also in the detection of new transponders all frequencies are added for the EITscanner.
I tested it by removing a transponder from channels.conf, and VDR found it again (though it took a while, as there are *many* frequencies in the frequency_list_descriptor). This too hasn't been working before on the DVB-T network of Finland.
Note that the patch uses list from C++ STL. If you wish to implement the list with something else, it should be trivial to modify.
Anssi Hannula wrote:
... Okay, attached is a patch for nit.c that checks for all the frequencies in frequency_list_descriptor for the channel's frequency and if found, use it so that channel's frequency is not changed.
Also in the detection of new transponders all frequencies are added for the EITscanner.
I tested it by removing a transponder from channels.conf, and VDR found it again (though it took a while, as there are *many* frequencies in the frequency_list_descriptor). This too hasn't been working before on the DVB-T network of Finland.
Note that the patch uses list from C++ STL. If you wish to implement the list with something else, it should be trivial to modify.
--- vdr-vanilla/nit.c 2006-04-15 17:10:42.000000000 +0300 +++ vdr-vanilla/nit.c.new 2006-05-27 00:14:16.000000000 +0300 @@ -7,6 +7,7 @@
- $Id: nit.c 1.11 2006/04/15 14:10:42 kls Exp $
*/
+#include <list> #include "nit.h" #include <linux/dvb/frontend.h> #include "channels.h" @@ -95,39 +96,75 @@ void cNitFilter::Process(u_short Pid, u_ SI::NIT::TransportStream ts; for (SI::Loop::Iterator it; nit.transportStreamLoop.getNext(ts, it); ) { SI::Descriptor *d;
std::list<int> Frequencies;std::list<int>::iterator frequency;for (SI::Loop::Iterator it2; (d = ts.transportStreamDescriptors.getNext(it2, SI::FrequencyListDescriptorTag)); ) {SI::FrequencyListDescriptor *fld = (SI::FrequencyListDescriptor *)d;int coding_type = fld->getCodingType();switch (coding_type) {case 1: // Satellitefor (SI::Loop::Iterator it3; fld->frequencies.hasNext(it3); )Frequencies.push_back(BCD2INT(fld->frequencies.getNext(it3)) / 100);break;case 2: // Cablefor (SI::Loop::Iterator it3; fld->frequencies.hasNext(it3); )Frequencies.push_back(BCD2INT(fld->frequencies.getNext(it3)) / 10);break;case 3: // Terrestrialfor (SI::Loop::Iterator it3; fld->frequencies.hasNext(it3); )Frequencies.push_back(fld->frequencies.getNext(it3) * 10);break;default: ;}
I believe there is a 'delete d' missing here.
}
I guess it's fair to assume that each TransportStream can contain at most one FrequencyListDescriptor, right? Otherwise the above loop could mix frequencies from different coding types, which would lead to confusion later on.
Klaus
Klaus Schmidinger wrote:
Anssi Hannula wrote:
... Okay, attached is a patch for nit.c that checks for all the frequencies in frequency_list_descriptor for the channel's frequency and if found, use it so that channel's frequency is not changed.
Also in the detection of new transponders all frequencies are added for the EITscanner.
I tested it by removing a transponder from channels.conf, and VDR found it again (though it took a while, as there are *many* frequencies in the frequency_list_descriptor). This too hasn't been working before on the DVB-T network of Finland. ...
Please test whether the attached version of the patch still works. Since none of the satellites I can receive uses the FrequencyListDescriptor, and I don't have cable or terrestrial signals, I can't test it myself.
If it's ok like this for you, I would include it in tomorrow's maintenance patch.
Note that I had to make a small change to libsi/si.h in order to avoid a compiler warning.
Klaus
On 5/27/06, Klaus Schmidinger Klaus.Schmidinger@cadsoft.de wrote:
Klaus Schmidinger wrote:
Anssi Hannula wrote:
... Okay, attached is a patch for nit.c that checks for all the frequencies in frequency_list_descriptor for the channel's frequency and if found, use it so that channel's frequency is not changed.
Also in the detection of new transponders all frequencies are added for the EITscanner.
I tested it by removing a transponder from channels.conf, and VDR found it again (though it took a while, as there are *many* frequencies in the frequency_list_descriptor). This too hasn't been working before on the DVB-T network of Finland. ...
Please test whether the attached version of the patch still works. Since none of the satellites I can receive uses the FrequencyListDescriptor, and I don't have cable or terrestrial signals, I can't test it myself.
If it's ok like this for you, I would include it in tomorrow's maintenance patch.
Note that I had to make a small change to libsi/si.h in order to avoid a compiler warning.
Okay, I'll be able to test in few hours.
But I can see few issues in the patch:
if (fld) {int n = 1;for (SI::Loop::Iterator it3; fld->frequencies.hasNext(it3); ) {int f = fld->frequencies.getNext(it3);int ct = fld->getCodingType();
This can be moved above the loop, as the descriptor has a common coding_type.
if (ct < 3)f = BCD2INT(f) / (ct == 1 ? 100 : 10);Frequencies[n++] = f;
You miss two ct cases: - when ct == 3, frequency should be multiplied with 10. - when ct == 0, coding_type is undefined, so I guess we should disregard the frequency_list_descriptor then.
}}
Anssi Hannula wrote:
On 5/27/06, Klaus Schmidinger Klaus.Schmidinger@cadsoft.de wrote:
Klaus Schmidinger wrote:
Anssi Hannula wrote:
... Okay, attached is a patch for nit.c that checks for all the
frequencies
in frequency_list_descriptor for the channel's frequency and if found, use it so that channel's frequency is not changed.
Also in the detection of new transponders all frequencies are added
for
the EITscanner.
I tested it by removing a transponder from channels.conf, and VDR
found
it again (though it took a while, as there are *many* frequencies
in the
frequency_list_descriptor). This too hasn't been working before on the DVB-T network of Finland. ...
Please test whether the attached version of the patch still works. Since none of the satellites I can receive uses the FrequencyListDescriptor, and I don't have cable or terrestrial signals, I can't test it myself.
If it's ok like this for you, I would include it in tomorrow's maintenance patch.
Note that I had to make a small change to libsi/si.h in order to avoid a compiler warning.
Okay, I'll be able to test in few hours.
But I can see few issues in the patch:
if (fld) {int n = 1;for (SI::Loop::Iterator it3; fld->frequencies.hasNext(it3); ) {int f = fld->frequencies.getNext(it3);int ct = fld->getCodingType();This can be moved above the loop, as the descriptor has a common coding_type.
if (ct < 3)f = BCD2INT(f) / (ct == 1 ? 100 : 10);Frequencies[n++] = f;You miss two ct cases:
- when ct == 3, frequency should be multiplied with 10.
- when ct == 0, coding_type is undefined, so I guess we should
disregard the frequency_list_descriptor then.
Ah, you're right. Attached is a new version.
Klaus
On 5/27/06, Klaus Schmidinger Klaus.Schmidinger@cadsoft.de wrote:
Anssi Hannula wrote:
... Okay, attached is a patch for nit.c that checks for all the frequencies in frequency_list_descriptor for the channel's frequency and if found, use it so that channel's frequency is not changed.
Also in the detection of new transponders all frequencies are added for the EITscanner.
I tested it by removing a transponder from channels.conf, and VDR found it again (though it took a while, as there are *many* frequencies in the frequency_list_descriptor). This too hasn't been working before on the DVB-T network of Finland.
Just to be clear, of course it worked before in the Digita's (operator of the Finnish DVB-T) network too if you happened to be one of lucky ones whose center_frequency in delivery_descriptor happens to be the correct one.
I guess it's fair to assume that each TransportStream can contain at most one FrequencyListDescriptor, right? Otherwise the above loop could mix frequencies from different coding types, which would lead to confusion later on.
I guess it is.
I can think of only one possible usage case when there could be multiple FrequencyLists: If the same multiplex is transmitted in multiple mediums in multiple frequencies, e.g. DVB-T and DVB-C, multiple lists could be used. But yes, that wouldn't make much sense as the bandwidth of DVB-T and DVB-C differs.
Klaus Schmidinger wrote:
Anssi Hannula wrote:
On 5/27/06, Klaus Schmidinger Klaus.Schmidinger@cadsoft.de wrote:
Klaus Schmidinger wrote:
Anssi Hannula wrote:
... Okay, attached is a patch for nit.c that checks for all the
frequencies
in frequency_list_descriptor for the channel's frequency and if
found,
use it so that channel's frequency is not changed.
Also in the detection of new transponders all frequencies are
added for
the EITscanner.
I tested it by removing a transponder from channels.conf, and VDR
found
it again (though it took a while, as there are *many* frequencies
in the
frequency_list_descriptor). This too hasn't been working before on
the
DVB-T network of Finland. ...
Please test whether the attached version of the patch still works. Since none of the satellites I can receive uses the FrequencyListDescriptor, and I don't have cable or terrestrial signals, I can't test it myself.
If it's ok like this for you, I would include it in tomorrow's maintenance patch.
Attached is a new version.
It works fine :)
-
Anssi Hannula -
Klaus Schmidinger