What is the primary cause of blotchy rendering?

[Asher]

older hardware (AMD A6-7400K with RadeonR5)
new tuner (Hauppauge quad-HD)
recent upgrade to NPVR 5.x

I've tried a few combinations of renderers and decoders, but new recordings have really jarring screen jaggies and blotchy patches.
Is this most likely to be cause by poor signal quality, or the decoders?

I suspect it's signal, and I'll keep playing with this, but I wanted to seek some knowledge from the hive mind here.

Historically, I've fixed poor playback by replacing the HDD, but this one is pretty new too (< 12 months). 

Coincident with the v5 upgrade and the tuner change (previously using an HVR2200) is switching to LAV decoders instead of the Microsoft DTV ones.
Skipping flat out "doesn't work" with those, and we had to switch to LAV.
[Skipping forward is exponential, Skipping backwards goes forward ...exponentially]

Any tips for troubleshooting will be appreciated.

[sub]

I suspect it's signal...

It's this.

It is a sign of reception issues. Those blotches are bit of corrupt data which can't be decoded correctly.

[Asher]

I suspect it's signal...

It's this.

It is a sign of reception issues. Those blotches are bit of corrupt data which can't be decoded correctly.

Thank you sub.

I'll see what I can tweak in the signal chain.  It never used to an issue - maybe the MS DTV decoder had a different way of handling it.
I will do some reading on the LAV settings too.

Cheers,

[NumberFive]

I see you have a Hauppauge quadHD. It could very well be this card that is the problem.

I had a quadHD (model 166200) which exhibited the same issues, frequent blocking and pixelation. I never had such issues with my previous tuners (Hauppauge Nova-T, Astrometa) or any of the TVs in my house. Only the quadHD.

Long story short, I used some tools to show that my signal was basically perfect, and managed to get through the first line of Hauppauge support to their engineers. They were excellent, and they discovered there was actually a fault with packets being dropped between the tuner board and the PCI-e bus. I now have a quadHD 166100 which has worked well for a year now, no blocking or pixelation. The two PCBs are basically identical, same tuner front end and chipsets, but I think the PCI-e mux chip is slightly different.

Here's some threads on the topic here, but I can tell you that messing around with amplifiers and attenuators, changing the PC etc was a waste of time. The signal was always good. The problem was the tuner board itself.

https://forums.nextpvr.com/showthread.php?tid=62066
https://forums.nextpvr.com/showthread.ph...#pid552925

[Asher]

ah,

Thank you @NumberFive.
That's really interesting.
The quadHD was bought to replace an hvr2200 that has been awesome but is now coming up to 13 years old and many recordings were almost unplayable (unknown recording length, far too much corruption in the file even using other playback software such as Films & TV, VLC etc...)

My quadHD identifies in Device Manager as a "1661xx" :\

I need to try and measure signal quality, but it's never appeared to be a problem before and it is running through two inline amplifiers.
I will try to find and play with "MPEG-2 Transport Stream Packet Analyser" that I saw in one of your other threads.

I've swapped aerial feeds and turned off hardware acceleration in LAV settings and it might have improved things.
I'll find out next time something records and I try watching it.

Thanks again,

[Asher]

I found the MPEG-2 analyser on github.

@sub thank you
@NumberFive thank you - your post helped me investigate

Here's a quick sample from the Beijing Olympics file that the screenshots are from:

Checking D:\Recorded TV\Beijing Winter Olympics\Beijing Winter Olympics_20220217_22000000.ts
ERROR! packet: 2472 pid: 554 found: 2 expected: 1
ERROR! packet: 7275 pid: 554 found: 0 expected: 15
ERROR! packet: 17982 pid: 554 found: 7 expected: 6
ERROR! packet: 23901 pid: 554 found: 1 expected: 0
ERROR! packet: 24682 pid: 554 found: 6 expected: 5
ERROR! packet: 27416 pid: 554 found: 1 expected: 0
ERROR! packet: 29367 pid: 554 found: 8 expected: 7
ERROR! packet: 31194 pid: 554 found: 7 expected: 6
ERROR! packet: 33468 pid: 204 found: 4 expected: 3
ERROR! packet: 38521 pid: 554 found: 13 expected: 12
ERROR! packet: 43710 pid: 554 found: 3 expected: 2
ERROR! packet: 52160 pid: 604 found: 4 expected: 3
ERROR! packet: 57639 pid: 824 found: 14 expected: 13
ERROR! packet: 70288 pid: 554 found: 1 expected: 0
ERROR! packet: 81982 pid: 554 found: 6 expected: 5
ERROR! packet: 88187 pid: 554 found: 12 expected: 11
ERROR! packet: 92860 pid: 554 found: 9 expected: 8
Complete, 103560 packets checked
17 errors found
22418 elapsed ms

Here's a new recording with the swapped aerial cables -- same channel:
Checking D:\Recorded TV\Hellboy II The Golden Arm\Hellboy II The Golden Arm_20220221_20302255.ts
Complete, 70284 packets checked
0 errors found
15189 elapsed ms

Perhaps changing aerial cables was magic. I will keep an eye on it!

Thank you

[NumberFive]

Hi Asher,

Yes, that MPEG-TS analysis is consistent with the errors I was seeing when I was debugging this

In my experience the errors are random. You sometimes get several in an hour (like you have in your first recording), sometimes you get zero (like in your second recording). I started to convince myself that swapping aerial cables, amplifiers, attenuators etc was all helping. In the end, none of that mattered.

I somewhat recall at one point believing that the errors were a result of tuning requests being sent to other tuners on the board, or active recordings on more than one tuner. However, I'm not really sure if that was the root cause or just coincidence.

I had to set up an experiment where I recorded 24 hours of recordings, across all four tuners (so 96 hours of files to analyse) and the majority would have contained errors. There were hundreds across the set of recordings. Did the same with other tuners (old Hauppauges and others), and you could count the errors on one hand, usually occuring in the first couple seconds, result being in practice you'd never notice them.

I used TSduck to do the batch analysis. I could PM you the script if you'd like it.

To check your signal quality, I'd recommend using CrazyScan2. You need to extract all the .rar archives to one folder, and run CrazyScan2.exe - https://sourceforge.net/projects/crazyscan/files/

I don't think CrazyScan2 works with the quadHD, but it does work with the dualHD USB and a lot of other very cheap USB tuners. Maybe one of your other cards is supported - https://sourceforge.net/p/crazyscan/wiki/Info/

Upshot is, CrazyScan2 allowed me to verify what I knew all along, the signal is consistently perfect! For me, the problem was between tuner and PC, not between tuner and aerial.