[solved] RPI3 OpenElec + tvheadend + tvheadend client

[thecyclist]

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

[Sundtek]

Use a longer USB cable (maybe your AC adapter is extremely noisy or something like that), that fixes such a problem for 99% of our customers

Let us know if it also works for you

[thecyclist]

Use a longer USB cable (maybe your AC adapter is extremely noisy or something like that), that fixes such a problem for 99% of our customers

Let us know if it also works for you

Thanks - I am giving it a try now. This is a little embarrassing as I found that, when I moved the receiver, the Sundtek power supply was turned off at the wall. This means that the receiver was being powered by the RPi, probably not good.  I'll post back here after the weekend with what I find.

JT

[thecyclist]

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?

[Sundtek]

Hi,

I will split this topic within the next hours because it's mixing up 2 different use cases.

FOLLOWING ONLY APPLIES TO OPENELEC / LIBREELEC:

Connect to the Raspberry PI and enable logging

mediaclient --loglevel=min

this should start to create a logfile in /var/log/mediasrv.log

Upload the logfile here and I can help you to go through it.

Check the signal statistic:
mediaclient --readsignal=0 -d /dev/dvb/adapter0/frontend0 --band universal

check which driver version you are using

mediaclient --build

When did you buy your device? If it's after July 2016 the driver should also be newer than July 2016 (latest one is 22 or 23rd August 2016).

Also check "dmesg" when the pixelation happens, I think there's a possibility to happen if the system runs out of memory.

You can also ask in the chat http://chat.sundtek.de in order to get some live help.

[thecyclist]

The log file:

Code: [Auswählen]

2016-08-23 20:55:14 [2816] Setting Frequency: 1594500
2016-08-23 20:55:14 [2816] Frequency: 1594
2016-08-23 20:55:14 [2816] Symbolrate: 27500
2016-08-23 20:55:15 [2816] Set Voltage Vertical (13V)
2016-08-23 20:55:15 [2816] Disabling High Tone (22khz)
2016-08-23 20:55:15 [2816] Setting Frequency: 1594500
2016-08-23 20:55:15 [2816] Frequency: 1594
2016-08-23 20:55:15 [2816] Symbolrate: 27500

The output from mediaclient --readsignal=0 -d /dev/dvb/adapter0/frontend0 --band universal

Code: [Auswählen]

SIGNAL: [.............................    ] ( 89%) SATQUALITY:  76%  SNR:  13  BER:      0 FREQ: 11344500   Hz LOCKED: YES SYS: DVB-S SYM: 27500000 FEC: FEC_5_6 MOD: QPSK VOLTAGE: V(13V) TONE: OFF
SIGNAL: [.............................    ] ( 89%) SATQUALITY:  74%  SNR:  13  BER:      0 FREQ: 11344500   Hz LOCKED: YES SYS: DVB-S SYM: 27500000 FEC: FEC_5_6 MOD: QPSK VOLTAGE: V(13V) TONE: OFF
SIGNAL: [.............................    ] ( 89%) SATQUALITY:  72%  SNR:  13  BER:      0 FREQ: 11344500   Hz LOCKED: YES SYS: DVB-S SYM: 27500000 FEC: FEC_5_6 MOD: QPSK VOLTAGE: V(13V) TONE: OFF
SIGNAL: [.............................    ] ( 89%) SATQUALITY:  77%  SNR:  13  BER:      0 FREQ: 11344500   Hz LOCKED: YES SYS: DVB-S SYM: 27500000 FEC: FEC_5_6 MOD: QPSK VOLTAGE: V(13V) TONE: OFF
SIGNAL: [.............................    ] ( 89%) SATQUALITY:  74%  SNR:  13  BER:      0 FREQ: 11344500   Hz LOCKED: YES SYS: DVB-S SYM: 27500000 FEC: FEC_5_6 MOD: QPSK VOLTAGE: V(13V) TONE: OFF
SIGNAL: [.............................    ] ( 89%) SATQUALITY:  74%  SNR:  12  BER:      0 FREQ: 11344500   Hz LOCKED: YES SYS: DVB-S SYM: 27500000 FEC: FEC_5_6 MOD: QPSK VOLTAGE: V(13V) TONE: OFF
SIGNAL: [.............................    ] ( 89%) SATQUALITY:  75%  SNR:  13  BER:      0 FREQ: 11344500   Hz LOCKED: YES SYS: DVB-S SYM: 27500000 FEC: FEC_5_6 MOD: QPSK VOLTAGE: V(13V) TONE: OFF
SIGNAL: [.............................    ] ( 89%) SATQUALITY:  77%  SNR:  13  BER:      0 FREQ: 11344500   Hz LOCKED: YES SYS: DVB-S SYM: 27500000 FEC: FEC_5_6 MOD: QPSK VOLTAGE: V(13V) TONE: OFF
SIGNAL: [.............................    ] ( 89%) SATQUALITY:  73%  SNR:  13  BER:      0 FREQ: 11344500   Hz LOCKED: YES SYS: DVB-S SYM: 27500000 FEC: FEC_5_6 MOD: QPSK VOLTAGE: V(13V) TONE: OFF
SIGNAL: [.............................    ] ( 89%) SATQUALITY:  78%  SNR:  13  BER:      0 FREQ: 11344500   Hz LOCKED: YES SYS: DVB-S SYM: 27500000 FEC: FEC_5_6 MOD: QPSK VOLTAGE: V(13V) TONE: OFF
SIGNAL: [.............................    ] ( 89%) SATQUALITY:  74%  SNR:  13  BER:      0 FREQ: 11344500   Hz LOCKED: YES SYS: DVB-S SYM: 27500000 FEC: FEC_5_6 MOD: QPSK VOLTAGE: V(13V) TONE: OFF
SIGNAL: [.............................    ] ( 89%) SATQUALITY:  77%  SNR:  12  BER:      0 FREQ: 11344500   Hz LOCKED: YES SYS: DVB-S SYM: 27500000 FEC: FEC_5_6 MOD: QPSK VOLTAGE: V(13V) TONE: OFF
SIGNAL: [.............................    ] ( 89%) SATQUALITY:  77%  SNR:  13  BER:      0 FREQ: 11344500   Hz LOCKED: YES SYS: DVB-S SYM: 27500000 FEC: FEC_5_6 MOD: QPSK VOLTAGE: V(13V) TONE: OFF
SIGNAL: [.............................    ] ( 89%) SATQUALITY:  77%  SNR:  13  BER:      0 FREQ: 11344500   Hz LOCKED: YES SYS: DVB-S SYM: 27500000 FEC: FEC_5_6 MOD: QPSK VOLTAGE: V(13V) TONE: OFF
SIGNAL: [.............................    ] ( 89%) SATQUALITY:  82%  SNR:  13  BER:      0 FREQ: 11344500   Hz LOCKED: YES SYS: DVB-S SYM: 27500000 FEC: FEC_5_6 MOD: QPSK VOLTAGE: V(13V) TONE: OFF
SIGNAL: [.............................    ] ( 89%) SATQUALITY:  77%  SNR:  13  BER:      0 FREQ: 11344500   Hz LOCKED: YES SYS: DVB-S SYM: 27500000 FEC: FEC_5_6 MOD: QPSK VOLTAGE: V(13V) TONE: OFF

I am not sure, but is SATQUALITY 74% good or bad? No errors though [BER=0].

The build version:

Code: [Auswählen]

OpenELEC:~ # mediaclient --build
Build date: 2016-08-17 16:37:13
OpenELEC:~ #

I bought the receiver on the 1st July.

The end of the dmesg output looks like this:

Code: [Auswählen]

[354871.448173] systemd-journald[178]: Retention time reached.
[356919.977114] systemd-journald[178]: Retention time reached.
[374443.019686] input: Sundtek Remote Control as /devices/virtual/input/input4
[374464.285790] input: Sundtek Remote Control as /devices/virtual/input/input5
[374478.200119] usb 1-1.2: usbfs: process 2828 (mediasrv) did not claim interface 2 before use
[396016.304685] systemd-journald[178]: Retention time reached.
[409356.536639] systemd-journald[178]: Retention time reached.
[411386.766556] systemd-journald[178]: Retention time reached.
[432974.734052] systemd-journald[178]: Retention time reached.
[440282.176331] systemd-journald[178]: Retention time reached.
[441365.731253] systemd-journald[178]: Retention time reached.
[443415.729710] systemd-journald[178]: Retention time reached.
[460850.473715] systemd-journald[178]: Retention time reached.

I just did a quick google to find out what Retention time reached means but did not find anything significant.

Thanks for you help. I am a linux application developer so am more than happy doing this.

John T

[Sundtek]

You need to follow the logfile and check if there's something weird when the problems occur.

You can also upload them here so we can help you to check.

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

[thecyclist]

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

[thecyclist]

Here is the mediasrv.log file [I hope the file attachment works].

There was pixilation while the file was being created so hopefully there is something of use. I have not changed the power supply yet.

JT

[Sundtek]

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

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

Does it permanently happen on certain channels or just from time to time?
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.

[thecyclist]

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

[Sundtek]

Did you buy the MPEG2 codec?

http://www.raspberrypi.com/mpeg-2-license-key/

[thecyclist]

Did you buy the MPEG2 codec?

http://www.raspberrypi.com/mpeg-2-license-key/

Yes and I have checked that it is enabled. Of course I don't know it is actually enabled just that the RPi tells me it is enabled.

JT

[Sundtek]

Try to record the video and play it back on a PC to ensure that the video data is correct.

You're using tvheadend? What does the tvheadend log say?

It seems to me that the codec is not enabled. It was a bit confusing at the beginning because you joined the other discussion which seems to be unrelated to your problem.

[thecyclist]

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:

Code: [Auswählen]

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:

Code: [Auswählen]

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.