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
