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.
I've now had time to debug this bug more, too.
Klaus Schmidinger wrote:
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.
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.
Klaus Schmidinger wrote:
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:
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:
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:
Okay, I'll be able to test in few hours.
But I can see few issues in the patch:
This can be moved above the loop, as the descriptor has a common coding_type.
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.
On 5/27/06, Klaus Schmidinger Klaus.Schmidinger@cadsoft.de wrote:
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 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.
-
Anssi Hannula -
Klaus Schmidinger