DVB-T2 corruption with Intel drivers installed

[SniperAsh6]

Hi, I'm at my wits' end with this feeling like I've tried everything so I'm hoping someone may be able to help please.

I've recently bought a mini PC with an Intel N100 which I'm hoping to use for NextPVR and Jellyfin with a Hauppauge WinTV DualHD. Initially I started off using Debian but have swapped to Ubuntu 22.04 LTS trying to see if it might help with my issue (below).

Where I've got to is that the official NextPVR docker container is fine with the default kernel (5.15) of Ubuntu 22.04. The quality is decent and everything in NextPVR seems to work but I've obviously got no QuickSync for either NextPVR or Jellyfin to use. My problem seems to come about when I upgrade my kernel to one which will play nice with the N100 for Quicksync. As soon as I start watching DVB-T2 channels through NextPVR they're unwatchable due to corruption (see attached image).


I've tried a few different kernels (5.17, 5.19, 6.5 to name a few) and this happens straight away with them because they have support for the N100. 5.15 is the only one I've had fine initially until I add the Intel drivers into the mix. I've tried the docker container from Ranbato which uses ffmpeg 5 as well as bulding my own with ffmpeg 6 and the Intel drivers (which is the only way I ccould get vainfo in the NextPVR container to work) but no luck for this issue, which I should add is only an issue for DVB-T2.

Most strangely recordings seem to come out ok and watching another channel while that recording is going on seems to be better but not perfect still.

None of this seems to change whether I'm using CPU or VAAPI transcoding though the VAAPI output is a lot lower quality with horrible interlacing (seemingly at least on live tv, I think recordings are ok or aren't as bad).

I can see these errors in the logs which seem to be showing the corruption but I'm completely at a loss as to how to solve this.

[10] [FFMPEG]: [mpegts @ 0x55de9dcfae00] PES packet size mismatch
[10] [FFMPEG]: [mpegts @ 0x55de9dcfae00] Packet corrupt (stream = 0, dts = 6765301040).

and

[28] [FFMPEG]: [h264 @ 0x55de9dfd0140] concealing 3074 DC, 3074 AC, 3074 MV errors in B frame
[36] [FFMPEG]: [h264 @ 0x55de9e086e40] cabac decode of qscale diff failed at 92 37
[36] [FFMPEG]: [h264 @ 0x55de9e086e40] error while decoding MB 92 36, bytestream 1185
[36] [FFMPEG]: [h264 @ 0x55de9e086e40] concealing 3797 DC, 3797 AC, 3797 MV errors in B frame

I've attached logs with a brand new container where I've used just one of the tuners to scan for channels and started watching BBC 1 HD which then presents the issue.

Thanks

[sub]

Have you tried running it outside of docker on the native machine?

Alternatively, if you stick to clients that are able to play native streams, does it work better? ie, not the web client that requires transcoding.

[SniperAsh6]

I have, yes, and native also showed the same problem

Same problem direct to jellyfin (through the plugin) or direct to VLC which seems to be the worst I've seen it

[sub]

If VLC is showing the problem, then it's sounding like it's not related to ffmpeg, and VAAPI etc wont help you. (since VLC is watching the original stream, with no transcoding)

It's sounding like corruption to the signal like you have marginal reception.

[SniperAsh6]

It seems to be software somewhere given it's ok without the Intel drivers and recordings seeming to be ok too.

I have checked the signal with a freeview set top box to make sure it's not that and that was fine, as are other uses of the aeriel

EDIT: To add as well I used the stick on another computer in the same place before buying the mini PC and that was fine except the CPU in it wasn't good enough for the transcoding

[sub]

It seems to be software somewhere given it's ok without the Intel drivers and recordings seeming to be ok too.

Hmm, not sure that is really the case, because we've not seen any other reports of this, outside the reasons I mentioned.

Typically what you're seeing in that screenshot is caused by signal issues. You can get something like this when in the web app if it's CPU starved (while trying to transcode). Given you said you saw it in VLC, where the stream is not transcoded, I'm leaning towards signal.

I'd delete the channels from one of your two tuners, so that you know you're always testing on the same single tuner (in case one of your two tuners is bad), then try doing a recording of one of these DVB-T2 channels. If you try playing that recording in VLC, and see the issue, then I'll get you to put the recording somewhere like onedrive or googledrive, and let me know the download link, and I'll take a look at the file.

[sub]

Set top boxes or TVs typically have better tuners than small USB sticks, so often work better with weaker signals.

As I said, it could also be a case that one of your two tuners has a fault. I delete the channels off one, so that you're only testing with a single tuner for now, to help you establish what is going on.

[SniperAsh6]

When I tried adapter0 only earlier on it exhibited the issue but then having since tried adapter1 for a few hours it has been fine. It has been playing three HD channels from the same mux and from what I've seen they've been spot on so that does lend some credit to the sticky being faulty as going back to 0 again shows the issue straight away.

Thank you for the second opinion and suggestions, I'll see if I can get the stick replaced and report back

[sub]

ok cool.

I mentioned it because recordings and live tv typically choose different tuners in a dual tuner system, to minimize clashes. By deleting the channel from one, you then at least know you're looking at the same one each time.

[SniperAsh6]

Got the new stick and straight away that does it too