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: > > 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. Well, I guess it would be best if you give it a shot, since you have the data stream necessary for testing this. Klaus
