Green Artifacts on HD Channels Tvheadend

the_bo · 12 February 2017 21:28

Hi

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

Heres Debug log: http://paste.osmc.io/oqinunivap

Thanks

https://i.ytimg.com/vi/QkD6YN1ddlg/maxresdefault.jpg

fzinken · 12 February 2017 23:19

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

the_bo · 12 February 2017 23:30

I’ll hook it up to my laptop to check

the_bo · 13 February 2017 00:39

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?

Thanks

fzinken · 13 February 2017 01:07

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

ActionA · 13 February 2017 01:16

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

sam_nazarko · 13 February 2017 01:21

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

ActionA · 13 February 2017 01:24

Seems to be multiple @sam_nazarko.

sam_nazarko · 13 February 2017 01:32

@the_bo

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

the_bo · 13 February 2017 10:44

Hi Sam

Recordings play back fine. Any other things to try?

Thanks

popcornmix · 13 February 2017 13:25

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).

the_bo · 13 February 2017 14:13

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

popcornmix · 13 February 2017 14:40

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

Could you read this post: LibreELEC Testbuilds for RaspberryPi (Kodi 17.0)
and try the suggested v3d_limiter setting in config,txt.

the_bo · 13 February 2017 15:04

Thanks Popcorn

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

Anyways thanks a million

popcornmix · 13 February 2017 15:19

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:
v3d_limiter=0x1080f1

the_bo · 13 February 2017 16:45

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

Will increasing the sdram help?

popcornmix · 13 February 2017 17:21

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

the_bo · 13 February 2017 18:47

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

Thanks

popcornmix · 13 February 2017 19:35

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:

sdram_freq=600
over_voltage_sdram=5
sdram_schmoo=0x02000020

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.

the_bo · 13 February 2017 21:13

Turn off audio_pwm_mode=2. Tried the following.

sdram_freq=500
over_voltage_sdram=5
sdram_schmoo=0x02000020
v3d_limiter=0x1880f1

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.