live tv green artefacts in LE11 nightly builds (RPi4)

nvdias · February 28, 2022 at 11:18 AM

I've been using the latest nightly builds on a RPi4.

Since the introduction of deinterlace for RPi4, it was a big evolution for live tv watching (RE: LE10 & deinterlacing in RPi4)

I've installed tvheadend server in LE11 and using the tvheadened pvr add-on to watch live tv on my RPi4.

All ok except ... some green artefacts that appear from time to time in almost every channel.

I'm using:

TB5520SE receiver (with pre compiled modules as described here LE10 & TBS 5520SE on RPi4 // updated drivers [SOLVED]);
tvheadend server;
tvheadend pvr add-on;
DVB-C unscrambled (free) signals;
using the same cable as the one connected to the TV provider set-top box.

Watching tv in KODI running on libreelec gives the green artefacts.

As my tv is a SONY Android tv, i've installed KODI 19 in it and connected to the tvheadend server on my RPi with LibreELEC- in this case the image is stable without any artefacts.

The same goes to the tv provider set-top which also plays flawlessly.

So, the difference here is KODI20 in LE11 on RPi4 - any suggestions on how to fiddle with LE11 KODI20 to handle those green artefacts ?

thanks

**popcornmix** · February 28, 2022 at 2:52 PM

Do you see the artifacts in recordings? If so, can you provide a short sample file that shows the issue?

**smp** · February 28, 2022 at 7:38 PM

I had the same issue on a pi3. The issue was that when running both tvh client and server on the same pi AND using advanced deinterlacing method - green artefacts would appear from time to time, also continuity counter errors in tvh log.

The solution was to use BOB deinterlacing instead of "advanced". However, BOB looks much worse than advanced.

Another solution was to increase the arm_uc value, e.g.:

Code

# vcgencmd arbiter set arm_uc 12 0

I don't have pi4 so no idea if this would work.

nvdias · March 4, 2022 at 2:16 PM

Quote from popcornmix

Do you see the artifacts in recordings? If so, can you provide a short sample file that shows the issue?

hi, in recordings they do not appear as green artifacts. anyway I will try to get a sample - more thinking where to share it.

Quote from smp
I had the same issue on a pi3. The issue was that when running both tvh client and server on the same pi AND using advanced deinterlacing method - green artefacts would appear from time to time, also continuity counter errors in tvh log.
The solution was to use BOB deinterlacing instead of "advanced". However, BOB looks much worse than advanced.
Another solution was to increase the arm_uc value, e.g.:
Code
# vcgencmd arbiter set arm_uc 12 0
I don't have pi4 so no idea if this would work.

pi4 using prime for deinterlacing. No options.

changing arm_uc not producing any changes.

But thanks for the suggestions.

**popcornmix** · March 4, 2022 at 4:43 PM

> hi, in recordings they do not appear as green artifacts. anyway I will try to get a sample - more thinking where to share it.

google drive and dropbox are good options for sharing sample files (but there are many other options).

nvdias · March 9, 2022 at 10:19 PM

Some more tests and a sample:

- Green Artefacts just appearing if using kodi pvr.hts addon viewer and tvheadend server in the same machine (libreELEC 11 in RPi4).

- Artefacts appearing only after a Continuity Counter Error in tvheadend log;

- Green Artefacts and Continuity Counter Error DO NOT APPEAR if the viewer is running in another machine (example: VLC in WINDOWS or KODI running from Android tv !

The link bellow is for a sample file recorded in LibreELEC -> the green artefacts are displayed if played in LibreELEC 11 RPi4, but almost unnoticeable if playing in VLC player in windows:

https://mega.nz/file/Ebp2kLJB#08TEUe5pt2IMeLN8D0Gfg5wTjbeN1EsaTZGGQ_ykKVI

Thanks

nvdias · March 12, 2022 at 1:39 PM

Some additional information:

A)

When watching tv with addon pvr.hts running in the same machine as tvheadend service:

- LE 11 nightly build - green artefacts; (*)

- LE 10.0.2 - green artefacts; (*)

- LE 9.2.8 - ALL OK (no issues).

(*) If I turn off "Allow Hardware acceleration with DRM PRIME" the artefacts disappear. But image loosed smoothness ...

B)

When watching tv by remotely connecting from another machine (windows pc with kodi, or vlc, or android tv with kodi)

to libreelec tvheadend service:

- ALL OK !

So, the issue is common to LE10 and LE11 and ONLY when running pvr.hts in the same machine as tvheadend ...

and with "Allow Hardware acceleration with DRM PRIME" activated.

chewitt, popcornmix should I report this somewhere else ?

thanks

**popcornmix** · March 12, 2022 at 4:44 PM

The sample file is corrupt (you can see complaints from VLC here).

Now how decoders cope with corrupt data is variable. In general software decoders have more ability to minimise visible artifacts (i.e. replace missing data with nearby data).

There is nothing that can be done about this, apart from not using the hardware decoder (which may have performance issues).

I don't believe LE 9.2.8 will play that sample file flawlessly.

**smp** · March 12, 2022 at 5:25 PM

Quote from popcornmix

The sample file is corrupt

The issue is that the stream gets corrupt when using a tv server and client on the same Pi + deinterlacing. This is totally RPi-specific.

nvdias · March 13, 2022 at 5:52 PM

Quote from popcornmix

The sample file is corrupt (you can see complaints from VLC here).
Now how decoders cope with corrupt data is variable. In general software decoders have more ability to minimise visible artifacts (i.e. replace missing data with nearby data).
There is nothing that can be done about this, apart from not using the hardware decoder (which may have performance issues).
I don't believe LE 9.2.8 will play that sample file flawlessly.

Quote from smp

The issue is that the stream gets corrupt when using a tv server and client on the same Pi + deinterlacing. This is totally RPi-specific.

Thank you both for your comments.

The strange thing here is that using the exact same hw configuration with le 9.2.8, plays flawlessly.

What have changed in le 10 that makes impossible to use tv server + client in the same machine ?

**smp** · March 13, 2022 at 6:50 PM

9.2.8 use mmal. 10 use drmprime. I suppose drmprime implementation on RPi is somehow more taxing than mmal.

**popcornmix** · March 13, 2022 at 7:11 PM

Quote from nvdias

The strange thing here is that using the exact same hw configuration with le 9.2.8, plays flawlessly.
What have changed in le 10 that makes impossible to use tv server + client in the same machine ?

I suspect the issue is at the tvheadend end, rather than the decoder end.

I don't know if you've tried using LE 10 on the Pi4 as the client, with the tvheadend server on a different device (either another Pi, or a different device).

If LE10 works when used as both client and server on separate Pi's, that would suggest there is a problem with the load when used on a single Pi, causing lost data.

If it still fails, then it would suggest something is worse on the server end - either tvheadend or the kernel driver for the tv device.

nvdias · March 15, 2022 at 10:30 AM

Made new tests with 2 Raspberry Pi 4.

Both in the same lan network:

RPi4 #1 -> LibreELEC 9.2.8, dvb-C dvb-S receiver + tvheadend server + tvheadend player addon

OK

RPi4 #2 -> LibreELEC 11 nightly build, tvheadend player addon, connected to RPi4 #1 (tvheadend server)

All goes OK !

Notes:

Using LE10 or LE11 in the server also works ok in this "distributed architecture".
tvheadend server is the same binary across every test. (4.3 nigthly build 2009).

Result:

The green screens artefacts are only appearing if using both tvheadend server + player in the same Rpi4 when running LE10/LE11.

Hope this helps somehow in solving the problem.

nvdias · March 25, 2022 at 8:14 PM

I've just compiled and installed the current master branch from github.

I've been watching TV for the entire afternoon without any visible artefacts or any reported error in tvheadend.log

I'm not proficient enough to understand if there were changes in the code that may have produced this new behaviour (apart some changes in ffmpeg that were merged yesterday in the branch) or if it is just some weird coincidence.

I will keep in tests during the weekend and will mark the thread as solved next monday if that is the case.

thanks

**popcornmix** · March 26, 2022 at 12:36 PM

Interesting. Nightly/master has moved to 5.15 kernel (compared to 5.10 kernel for Matrix) which is one possible explanation.

dobo · June 7, 2022 at 7:00 PM

Hi there.

I have observed the same behavior on Raspberry Pi 4 with MyGica T230C2 (0572:c68a). I don't think it's a receiver specific issue. It seems that deinterlacing is consuming some CPU time and DVB worker isn't given enough time slice by the kernel scheduler. But after increasing buffer size in the kernel it's working fine for me. I've used following patch:

Diff

diff --git a/drivers/media/usb/dvb-usb-v2/dvbsky.c b/drivers/media/usb/dvb-usb-v2/dvbsky.c
index 1221c92..e09e16e 100644
--- a/drivers/media/usb/dvb-usb-v2/dvbsky.c
+++ b/drivers/media/usb/dvb-usb-v2/dvbsky.c
@@ -751,7 +751,7 @@ static struct dvb_usb_device_properties mygica_t230c_props = {
        .num_adapters = 1,
        .adapter = {
                {
-                       .stream = DVB_USB_STREAM_BULK(0x82, 8, 4096),
+                       .stream = DVB_USB_STREAM_BULK(0x82, MAX_NO_URBS_FOR_DATA_STREAM, 16 * 4096),
                }
        }
 };

Display More

If someone steps into the same issue, increasing buffer size for the DVB receiver will probably help in deinterlacing.