Fix: QAM channel scan is unreliable; often reports many channels as DTV-x-y

[JustFred51]

This behavior is observed when using Hauppauge HVR 1250, 1600, 1800 & 2250 tuners, although it likely occurs with any BDA (internal, non-network) tuner. A non-Sage channel scan (TV, HDHR, or Hauppauge WinTv app, or TsReader) confirms that the correct channel info is present in the data stream. The issue was introduced in Sage7 and didn't occur with Sage6. Possibly related to another old issue; see comment in ChannelScan.c re: 'QAM stream carries DVB-C PSI in Lubbock TX'.

Suddenlink cable (clear QAM, in Truckee, Calif) carries some ATSC streams with a 12:1 ratio of DVB to ATSC packets. This mixture of packets (which arrive in no particular order) caused the channel scanner to get confused. Depending upon when it started looking at the pkt stream, stream_format might get set to either DVB_STREAM or ATSC_STREAM, causing programs to be reported as "DTV-x-y" instead of e.g, "KCRA", or dropped entirely. Scan results were often inconsistent, resulting in the need to manually remap a large number of channels. Subsequent scans gave wildly different scan results. In a system with multiple tuners using the same channel lineup, it was impossible to obtain convergence.

This commit changes the algorithm for "guessing" the stream type by giving higher weight to ATSC packets, based on a ratio of 16:1. To guard against spurious ATSC detection, we still need to see >= 2 ATSC packets to decide it's an ATSC stream.

Pkt stream test case: 15 (DVB), 1 (ATSC), 15 (DVB), 1 (ATSC) : result=ATSC Stream detected

This commit also bumps the SageTv.exe version # from 9.0.0.5 to 9.0.0.6

I intend to encourage wider testing of this change by posting TSSplitter.ax (for both Sage7 & Sage9) on the forums after the code has been reviewed.

[qianzhang5]

Could you build x86 and x64 DLLs to put on forum to have users test?

[JustFred51]

I'll be posting 2 versions of TSSplitter.ax (which contains the fix). One is built for Sage7 (using the pre-vs2015 C runtime libraries). The other is for installations running the full set of Sage9 binaries, using the newer vs2015 UniversalCRT runtime libraries. Both are 32-bit. The VS Solution isn't able to build anything for 64-bit yet.

[qianzhang5]

It's better post a VS2015 redistribution installation as well or a link for
users.

On Tue, Dec 8, 2015 at 3:38 PM, Keith Fischer notifications@github.com
wrote:

I'll be posting 2 versions of TSSplitter.ax (which contains the fix). One
is built for Sage7 (using the pre-vs2015 C runtime libraries). The other is
for installations running the full set of Sage9 binaries, using the newer
vs2015 UniversalCRT runtime libraries. Both are 32-bit. The VS Solution
isn't able to build anything for 64-bit yet.

—
Reply to this email directly or view it on GitHub
#62 (comment).

[JustFred51]

The .ax files have been posted to the forums here: http://forums.sagetv.com/forums/showthread.php?p=581552#post581552
It's anybody's guess how long before there's feedback. In the meantime, unless there's a known reason it's a bad fix, I'd like to get the change pulled into the repo. We can easily back it out later if there are reports of regression.

[Narflex]

Do you know what the signs would be if there were problems so we'd be able
to identify this commit as the bad one? If that's somewhat solid; then I'd
be fine with committing it...I know how that helps if you're working on
this area of the code. :)

On Tue, Dec 8, 2015 at 11:36 PM, Keith Fischer notifications@github.com
wrote:

The .ax files have been posted to the forums here:
http://forums.sagetv.com/forums/showthread.php?p=581552#post581552
It's anybody's guess how long before there's feedback. In the meantime,
unless there's a known reason it's a bad fix, I'd like to get the change
pulled into the repo. We can easily back it out later if there are reports
of regression.

—
Reply to this email directly or view it on GitHub
#62 (comment).

Jeffrey Kardatzke
jkardatzke@google.com
Google, Inc.

[qianzhang5]

I think after 10 users in different area testing without problem, we may
check in. since we probably can't get 100% QAM working correctly, keep
updating new DLLs on forum to improve after releasing.

On Tue, Dec 8, 2015 at 8:53 PM Jeffrey Kardatzke notifications@github.com
wrote:

Do you know what the signs would be if there were problems so we'd be able
to identify this commit as the bad one? If that's somewhat solid; then I'd
be fine with committing it...I know how that helps if you're working on
this area of the code. :)

On Tue, Dec 8, 2015 at 11:36 PM, Keith Fischer notifications@github.com
wrote:

The .ax files have been posted to the forums here:
http://forums.sagetv.com/forums/showthread.php?p=581552#post581552
It's anybody's guess how long before there's feedback. In the meantime,
unless there's a known reason it's a bad fix, I'd like to get the change
pulled into the repo. We can easily back it out later if there are
reports
of regression.

—
Reply to this email directly or view it on GitHub
#62 (comment).

Jeffrey Kardatzke
jkardatzke@google.com
Google, Inc.

—
Reply to this email directly or view it on GitHub
#62 (comment).

[JustFred51]

@Narflex: Should be fairly easy to identify. My change only affects channel scan. Symptoms of a bad fix will be identical to what's in the title of this pull request, seen on systems that previously didn't have that problem.

[Narflex]

Now that you already made that post...let's give it a few days and see if
some responses are made with confirmation it works OK. I'd at least like to
get a couple other confirmations of it working fine...but if no one
provides assistance by the beginning of next week, then we can go ahead and
commit it.

On Wed, Dec 9, 2015 at 10:51 AM, Keith Fischer notifications@github.com
wrote:

@Narflex https://github.com/Narflex: Should be fairly easy to identify.
My change only affects channel scan. Symptoms of a bad fix will be
identical to what's in the title of this pull request, seen on systems that
previously didn't have that problem.

—
Reply to this email directly or view it on GitHub
#62 (comment).

Jeffrey Kardatzke
jkardatzke@google.com
Google, Inc.

[JustFred51]

Sounds reasonable to me. Normally, I get a bit concerned about delayed pulls and subsequent issues with merge-in. But with the low volume of changes to the native code, there's little likelihood of bit-rot setting in.

[JustFred51]

It's been over a month since the binaries were posted on the forum. No feedback that the change has broken anything. Time to pull it into the repo?

[Narflex]

I agree...it is now merged. :)