Green Artifacts on HD Channels Tvheadend


Getting lot of green artifacts similar to pic below on hd channels using tvheadend on Tevii S660 device.

Heres Debug log:


Can you watch them correctly on another device connected to that tvheadend server?

I’ll hook it up to my laptop to check

HD work fine when connected to PC. Is there any advanced settings that might help increase buffer or something. Do logs provide any clue to the issue?


If the streams are MPEG2 you might want to try to buy the license

You should try a different HDMI cable or possibly increasing config_hdmi_boost to 7, up to 11 if you see no improvment.

If it’s only one channel or stream, unlikely to be this.

Seems to be multiple @sam_nazarko.


Try recording one of the channels and see if playback causes problems.
If it does, upload a small sample which produces the problem.

Hi Sam

Recordings play back fine. Any other things to try?


Is the tvheadend backend running on the same pi you are playing back on?
Can you try disabling deinterlace (bring up OSD and video settings when playing video).

Hi Popcorn

Yes Tvheadend backend is on same pi.

Thanks Disabling deinterlacing seems to solve problem. Havent seen any green artifacts so far.

Channels look very fuzzy without deinterlacing though. Is there any cpu or ram settings that might help with improving deinterlacing performance?

How come recordings can use deinerlacing without any problems?

Thanks again

1 Like

Okay, you can probably enable deinterlace and change deinterlace mode to bob (2x) which will look better.

Could you read this post:
and try the suggested v3d_limiter setting in config,txt.

1 Like

Thanks Popcorn :grin:

Bob (2x) no issues so far awesome. Maybe bob should be default for pi instead of advanced.

Anyways thanks a million

Advanced is higher quality (although the difference is small).
Could you try switching to Auto (which will give Advanced by default) and try adding to config.txt:

Still green artifacts using v3d_limiter=0x1080f1, although they appear less often than without it.

Will increasing the sdram help?

Can you try increasing a little more. e.g. v3d_limiter=0x1880f1 ?
Yes, increasing sdram overclock will also help.

Yes much better with v3d_limiter=0x1880f1 very few glitches.

What exactly does v3d_limiter=0x1880f1 do to make it better?

Also the audio is out of sync sometimes after glitch is this because of omxplayer?

Will try increasing sdram to 500 to see

Edit: Just noticed GUI slowdown lag when browsing tv guide with tv playing in background using v3d_limiter=0x1880f1.

Edit: It seems v3d_limiter=0x1080f1 and sdram 500 is very gud. Very few glitches some slowdown when browsing gui.

v3d_limiter=0x1880f1 seems to put lot of strain as there is a slight lag between buttons presses and action on screen. Browsing tv guide with programme in background is unusable very slow.

So overall bob (x2) is best for me in terms of performance, although if people dont use the gui when channel playing in background v3d_limiter=0x1080f1 and sdram 500 is good option.

Whats is safe overclock for sdram. Is 500 ok?

If theres anything else to test let me know



Advanced deinterlace is motion adaptive and uses 3 reference frames. At 1080p that is a heavy user of sdram bandwidth.
No problem when you are just playing video but some (not all) dvb cards will drop data when the arm is slower to respond to the interrupt (due to the conflicting sdram accesses). Running the dvb card on a different Pi on the network would likely avoid this issue.

v3d_limiter is a debug feature that allows the advanced deinterlace (which uses the v3d hardware) to periodically hold off the sdram bus allowing other users (i.e. dvb driver) to get in.

Increasing the first two hex digits of v3d_limiter will hold off the bus for longer and should result in fewer glitches. But increase it too far and deinterlace will take longer until we start to drop frames (resulting in stuttery video).

The more sdram bandwidth the better. It’s hard to predict what is safe (apart from the default setting) - it is an overclock, so no guarantees.

Some Pi’s will run at 600MHz reliably. Some won’t. I use:


But that doesn’t work reliably on all Pi’s I’ve tested.

I notice you are using audio_pwm_mode=2 which is an experimental setting (which does increase GPU load). I’d suggest removing that for now while we are focusing on other issues.

Turn off audio_pwm_mode=2. Tried the following.


Works good. Only odd green glitch. Although GUI suffers.

I have another tuner lying around. Its a Geniatech HDstar v3. Last time i tried it, It wouldn’t scan it seems v3 of the device isnt supported by linux kernel only v2 and v1.5 work. Not sure if it got supported since.