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
