1xx,y channels should not be in tuner lineup

[sengsational]

The new ATSC 3.0 tuner causes a data-corruption problem because it contaminates the channel list with 1xx.y channels that the ATSC 1.0 tuners cannot lock. That contamination is in any XML file that was created (either through a lineup query or a manual scan) using a unit with an ATSC 3.0 tuner. The only way that I have thought of so far to handle this issue is for CW_EPG to (1) discard any 1xx.y channel from tuner2 or tuner3 in any of the existing HDHR units (since those are always ATSC 1.0 only tuners) and (2) discard any 1xx.y channel from HDHR units with DEVID less than that of the first HDHR 4k units (i.e., <“10800000”). This would prevent scheduling an ATSC 3.0 channel to an ATSC 1.0 tuner. BUT I fear that it would not prevent CWHelper from attempting that when trying to find an unlocked tuner after discovering a realtime conflict.

[sengsational]

On the topic of inappropriate channels in the lineup, the principle we started with is that each tuner has a lineup, and it really does contain only the tunable stations for that tuner. So if, based on tuner model, we allow only a subset of channels to be added (sans 1xx.y), that might be the cleanest approach. We have a method that selectively loads channels already (here). If we can see the "1xx.y", and can know if the tuner is sour to those types, we can skip over them. Do we see the "1xx.y" in between and in the xml? If so, we could model our programming enhancement in a similar way as "tunerNeedsFullDefinition" works (right now, if we have an entry with fewer than 5 chunks of data and tunerNeedsFullDefinition, we skip it, rather than adding it to programDefinitions). So we could add something like "else if tuner can't handle 1xx.y and this program definition is of the 1xx.y type", then skip adding it.

[TPeterson94070]

Rather than "can't handle 1xx.y", we should test handling of the protocol type "atsc3" to exclude those. That eliminates the need for external knowledge of tuner model capabilities. Note that each tuner only needs to be tested on one program of any channel with multiple programs (e.g., the common "lighthouse" configuration) so that the testing doesn't bog down the list generation.

[sengsational]

The idea is to attempt to start a recording to determine if a tuner is astc3 capable?

[TPeterson94070]

Yes, that was my thought. Perhaps using http://<IP>/tunerN/vX.Y?duration=1 to minimize latency.

[sengsational]

We can save the above attempt at a lock for later, but for now, we can act upon your email suggestion:

Also, since we have to rely upon the Antenna Digital.xml for “old” tuners, unless the user has manually scanned them tuner-by- tuner with CW_EPG, I’m back to thinking that we should simply go by the GuideNumber=”1XX.YYY” flag to eliminate ATSC 3.0 channels from any HDHR with DEVID<”10800000”. Then, rather than testing newer HDHR tuners for ATSC 3.0 lockability, let’s just drop the 1XX.YYY channels from their tuners 2 and 3. That will handle all of the existing SD products and we can revisit this question if/when SD releases HDHR with more than 2 ATSC 3.0 tuners inside.

getProgramDefinitions() (here) goes through an XML file and selectively creates channels.

We probably should have an English word for whatever "DEVID<1080000" means in the real world (situatonX) at the beginning of the method, you might use the tuner object, passed in, to determine if the device ID is less than 10800000, and make a local variable.

The idea would be to prevent it hitting this line programDefinitions.add(aProgramDefinition.toString()) if it's not a channel you want to add. So to do that, you'd add an else if (situationX) then log the fact or at least count how many of that type you're skipping, and log one line at the end of the method, like "For tuner XXXXXXXX, we skipped NN situationX channels".

[TPeterson94070]

OK, I'll take a shot at it.

[TPeterson94070]

I added and tested a skipAtsc3Channel method that I just pushed to feature_s. In my edits I also added a copy of your "private" getFromHtml method. I first tried to just make your method "public" but that didn't seem to make it visible in the other file for this Java newbie.

[sengsational]

You will probably find that if you import org.cwepg.hr.ChannelDigitial, the method will be available and we won't have to duplicate the code.

[TPeterson94070]

Ah! That's what I was missing then. I'll make that change and repush. Thanks!

[TPeterson94070]

Hmm...I added the import and then changed the getFromXml declaration to "public" when the reference was still flagged as undefined. (I did save both files) What am I still missing?

EDIT: Never mind. I added the prefix ChannelDigital to the method call and Eclipse finally led me to changing the declaration to "static" from "private".

[sengsational]

Glad you got it. It does that sometimes. "Control-O" is "organize imports", that sometimes helps.

[TPeterson94070]

Does "organize imports" also remove the superfluous ones? That would be handy for excising some of those dozens of warnings. :)

[sengsational]

Yeah, it clears the ones that aren't needed any more. Because it's noisy when clean-up is done, back in the old days when I was working for the man, I'd do a check-in that had ONLY clean-ups. That way, when you look at a "diff", you could breeze through the change with only the clean-ups, and concentrate on the change that had substantive alterations.

[sengsational]

The change has been merged into master branch.