Sundtek Support Forum

With the hardware PID filters turned off things are looking good: no pixelation [blocking artefacts] and the system has been stable for a couple of days. Understandably I did have to disable and then re-enable the sundtek-driver add-on in openelec before the change to the PID filter setting took effect

From your other post you say the hardware pmeg2 decode was not enabled, is this from the mediasvr.log file? I has been getting the impression that the codec was not working as well, but from the command line:

OpenELEC:~ # vcgencmd codec_enabled MPG2
MPG2=enabled
OpenELEC:~ #

Of course I have my doubts if this is true.

Thanks again for your help.

Quick Edit: I forgot to add:
OpenELEC (official) Version: 6.0.3
OpenELEC:~ # uname -a
Linux OpenELEC 4.1.18 #1 SMP Mon Feb 29 20:48:22 CET 2016 armv7l GNU/Linux
OpenELEC:~ #

John T.

Try to turn off the PID filters, does that make any change?

OK I will do that and report back.

The tuner/driver doesn't complain about a garbled signal it seems like a problem on another end somewhere.

This is good news - I don't want to climb up to re-align my antenna.

Does it permanently happen on certain channels or just from time to time?

Some channels are worse than others; its strange but HD channels are less of an issue than standard definition.

It has been known if no DMA memory is available the videodata will be interrupted for a short moment (which is a linux limitation with older Linux Kernels).
Newer Linux Kernels support memory mapped transfers (but that needs a linux Kernel from beginning of 2016).

You might also try another system to doublecheck if your problem only occures on that particular system.

Check the logs when the problem is happening (not when it is not happening).

Generally said there's no known problem with those tuners.

I am not sure what age the kernel is on OpenElec 6.0.3 - its a version 4 I am sure - I am not near the system at the moment but will do a 'uname -a' as soon as poss.

Thanks for the re-assurance - just to be clear that log file I posted was taken while a number of pixilation [blocking artefacts] events were happening.

Thanks

JT

It's also possible that your AC Adapter for the Raspberry PI is not suitable.

/opt/bin/mediaclient --loglevel=max
will enable full logging and show if there are any packet corruptions in /var/log/mediasrv.log

Ok I will switch the logging mode.

The power supply is rated at 2A, but I do have another one [also 2A] that I can swap out. I will try to do the science properly and increase the loglevel before changing the power supply and report back.

Thanks again

JT

I have moved the sundtek receiver to approx. 0.5m from the RPi and its power supply but I am still getting the same pixilation [blocking]. I still find that going into the add-on settings page in OpenElec to disable and then enable the Sundtek driver clears the pixilation from a while. Is there anything further I can change or check?

I think I am seeing the same symptoms: blocking when the picture changes rapidly on both SD and HD transmissions.

I am using an RPi 3 running Openelec+tvheadend+tvheadend client.  My signal strength looks good 90+% and the BER is zero.  

However: If I go into the add-on configuration for the sundtek driver disable and then re-enable it all is good for a period of time; the picture could then be clear of blocking for anything from a couple of hours to a week. I think my driver is upto date: OpenElec tells me it is version 6.0.1. When the blocking re-appears I simply disable and re-enable to driver

Thanks

JT