Closed eblanca closed 4 years ago
I think it comes from upstream, since I see this section in the w_scan-20170107 diff:
@@ -1198,6 +1223,12 @@ void parse_T2_delivery_system_descriptor(const unsigned char *buf,
t->source = 0x04;
t->delsys = SYS_DVBT2;
t->modulation = QAM_AUTO;
+ t->hierarchy = HIERARCHY_NONE;
+ t->coderate = FEC_AUTO;
+ t->coderate_LP = FEC_NONE;
+ t->SISO_MISO = 0; // NOTE: DTV_BANDWIDTH == '0' is BANDWIDTH_AUTO
+ t->guard = GUARD_INTERVAL_AUTO;
+ t->transmission = TRANSMISSION_MODE_AUTO;
t->inversion = inversion;
// descriptor_tag 8 uimsbf
descriptor_length = buf[1]; // descriptor_length 8 uimsbf
It should make no difference in practice. I'm also in Italy and I have never lost channels when comparing my fork to the original. On the contrary, I get more and better channels since it no longer discards duplicate transponders.
I just discovered this project and first of all Well Done!! I used to do my DVB scan with the old w_scan and I know its flaws, including its (recent) bug in detecting channels by RAI broadcaster. Having said this, I looked side by side a scan performed by w_scan with a scan performed by w_scan2 just after the first one. For both runs I used the mplayer output format. Well at first I can say they differ in the options, and this is weird. As you can see, the options for the common channels detected are well defined by "old" w_scan but set as "auto" by w_scan2. [FEC_3_4 vs FEC_AUTO, QAM_64 vs QAM_AUTO, HIERARCHY_NONE vs HIERARCHY_AUTO and so on] Is this an issue? Is this expected? And if so, are they not-so-relevant?
channels.conf.generated_with_w_scan2.txt channels.conf.generated_with_w_scan_shipped_with_lmde3.txt