DVB issue since LE switched to kernel 4.9.x

  • Thanks for this thread - I've been having trouble with my RPi 2 and DVBSky S960 since upgrading to LibreELEC 8.0 (green unwatchable mess on most channels, countless continuity errors in tvheadend), but smp's build without media_build seems to be working well for me (media_build was better than 4.9 kernel, but some channels were still bad or only occasionally worked).


    However, I'm not sure this problem is RPi-specific. I tried the same setup with my tuner on an x86 laptop (i5-3340M) running LibreELEC 8.0.1 (official build) and was having the exact same problem - it was essentially unusable with the constant continuity errors in TVH, as even the bouquet/mux scan was failing (UK Freesat channels). Let me know if you want me to try any further testing.

    It's not pi specific, is the Linux kernel from 4.9 and up. Hopefully is resolved or some lovely person can post an image of the latest generic release with Linux kernel 4.8 (with media) ;)

  • I tried the same setup with my tuner on an x86 laptop (i5-3340M) running LibreELEC 8.0.1

    are you able to test it with Ubuntu and kernel 4.9+ ?

    Sadly I am not even too sure if it is a Kernel or a LE problem. Like said without HW impossible to test :/

  • I guess you mean Ubuntu 17.04? I'll see what I can do, but it may mean building tvheadend from source as they don't make packages for it yet, and I'm not too experienced with that kind of stuff - unless someone can point me to an easier way of streaming from a tuner in Ubuntu?

  • I've just tried with Raspbian Pixel jessie (official image):


    [email protected]:~ $ uname -a

    Linux raspberrypi 4.9.24-v7+ #993 SMP Wed Apr 26 18:01:23 BST 2017 armv7l GNU/Linux



    [email protected]:~ $ apt-cache show kodi

    Package: kodi

    Version: 2:17.1-1~jessie


    [email protected]:~ $ apt-cache show tvheadend

    Package: tvheadend

    Version: 4.0.8~jessie


    no problem at all, DVB-S with DVB-Sky960CI running smoothly, no artefacts visible!

  • no problem at all, DVB-S with DVB-Sky960CI running smoothly, no artefacts visible!

    Try a 1080i channel, with deinterlacing method set to "MMAL - advanced".

    The problem with with kernel 4.9+ and RPi3+DVB dongle is that you can't use advanced deinterlacing on 1080i channels due to frequent artefacts.

    With kernel 4.8 (and older) there is no such issue.

    Edited 5 times, last by smp ().

  • no problem at all, DVB-S with DVB-Sky960CI running smoothly, no artefacts visible!

    tx that is very helpful, so at least for this card it is our problem :/


    btw did you use tvh 4.0 at LE too ?

    If not could you try what happens if you use Tvh 4.0 at LE ?

  • Try a 1080i channel, with deinterlacing method set to "MMAL - advanced".

    The problem with with kernel 4.9+ and RPi3+DVB dongle is that you can't use advanced deinterlacing on 1080i channels due to frequent artefacts.

    With kernel 4.8 (and older) there is no such issue.

    tried different HD Channels with MMAL-advanced, all of them worked aswell!

    Edited 2 times, last by maroi ().

  • I tried the official 8.0.2 build on my RPi2, seemed a lot better than before in that channels were actually watchable again, but still getting occasional green gunge (continuity errors in Tvheadend), and for whatever reason Channel 5 HD (UK Freesat) was a total garbled mess - so bad it would crash Tvheadend completely. Using "MMAL - advanced" deinterlacing.


    Trying smp's latest build (without media_build) now - much more stable (Channel 5 HD will play OK) but still occasional continuity errors when playing live - 8 errors in about 15 minutes from testing just now (BBC 1 HD). I tend to watch recordings more than live, which seem to have less errors (lower load I guess) - though it can choke if for example I'm playing some other video while it's recording.

    there is a official 4.2 packages from Tvheadend since ~2weeks now :)

    They need to update their website then :) : AptRepository - Tvheadend


    I'll try if I have the time.

  • but still occasional continuity errors when playing live - 8 errors in about 15 minutes

    Run "vcgencmd arbiter set arm_uc 12 0" from ssh and see if it helps (you can add it to autostart.sh to make the setting permanent).

    Also overclock the sdram to at least 550 mhz

    Code
    1. sdram_schmoo=0x02000020
    2. sdram_freq=550
  • Today i did some further testing:


    all tested with DVB-S Astra 19.2E - RTL2 Austria (SD Channel), MMAL Advanced Deinterlacer


    Raspbian jessie (official) 4.9.24-v7+ #993 Tvheadend 4.0.8 works fine
    Libreelec 8.0.2 (official) 4.9.29 #1 Tvheadend 4.0.9 continuity counter errors
    Libreelec 8.0.2 (official) 4.9.29 #1 Tvheadend 4.1.109 continuity counter errors
    libreelec 8.0.2 (smp - k48 27.5.17) 4.8.16 #1 SMP TVheadend 4.2.2-32 continuity counter errors, transport error indicator
    libreelec 8.0.2 (smp - nomb 27.5.17) 4.8.16 #1 SMP TVheadend 4.2.2-32 works fine
    Libreelec 8.0.1 (????) 4.8.13 #1 Tvheadend 4.1.2415 works fine



    i hope this helps a little bit

  • i hope this helps a little bit

    yea basically tells that it is a LE problem :(


    "We" think the problem is some setting at linux.conf that behaves >=4.9 differently to =<4.8 .

    That is the main difference between Raspbian and LE.


    Sadly I am away for a week and can not provide some builds.


    If someone is interested in the meantime and knows how to change it

    difference of the kernel conf (Raspbian vs LE8) Ubuntu Pastebin


    first thing to test

    removing CONFIG_HZ_300=y

    removing CONFIG_CPU_IDLE=y


    if this won't help there are a lot other differences in the kernel conf (see paste link) too :(

  • "We" think the problem is some setting at linux.conf that behaves >=4.9 differently to =<4.8 .

    I did a test build using kernel 4.9.29 with an older linux.arm.conf (for kernel 4.8.11). I also removed CONFIG_HZ_300=y and CONFIG_CPU_IDLE=y. This didn't make any difference, I still see an occasional video corruption.

  • I did a test build using kernel 4.9.29 with an older linux.arm.conf (for kernel 4.8.11).

    the LE 4.8 config won't help because the evil setting should be already there and the 4.9 conf was made ontop of the 4.8 conf

  • I just found this thread googling very similar symptoms I've been seeing since attempting to upgrade from a 4.6.0 based kernel to 4.9 based kernels in march this year on my RPI2 which runs gentoo as a mythtv backend (i.e. the reported artifacts in video recordings).

    I use a Geniatech T230 DVB-T2 TV Stick for recordings, two USB hard disks for the data and a USB stick for the mysql database/swap. The root partition is on an 8gb sd card.


    I am similarly convinced the problem lies in the kernel's USB subsystem. Not only do I see video artifacts in mythtv recordings, but sporadic corruption of the mythtv mysql database (hosted on USB key). Since switching back to the 4.6 kernel a couple of months ago all my problems magically vanished - video artifacts in recordings was the most visible symptom and the way I confirmed I'd found the culprit.


    I'm also a libreelec user (on my RPI-B / B+ boxes) which mount 'storage' via nfs (over ethernet) to one of the USB hard disks hosted on the PI2. When I first set this up regular upgrades of my test system always worked, but recently I see MD5 errors when libreelec unpacks the tar file on upgrade (less often now I have the RPI2 reverted to 4.6). If I use a decompressed .img file rather than a .tar which seems to stress the network less it works 1st time.


    I understand ethernet on the PI is also via USB, which is yet another finger pointing at the kernel's 'USB stack' for me.


    I've convinced myself it's a kernel thing rather than a bcm firmware thing as using exactly the same 2016 firmware switching from 4.6.0-rc5-v7+ to 4.9.10-v7+ kernel (both compiled myself using bcm2709_defconfig) the problem is either there or not.


    Given that x86 / x86_64 users with usb sticks are reporting similar things on this thread, my next step will be to try compiling the very latest 4.8 based RPi kernel to see if I get the problem or not (I'm using an rpi github kernel).


    This is my production system, compiling kernels on the RPi2 takes a while and I also have a rather busy day job, but I will report back what I find; assuming I manage to localize the 4.8 to 4.9 change which introduced this before someone else here does...

    Edited once, last by metaron ().


  • Can anyone else reproduce this? It seems a very significant result, but surprising, so more confirmation would be good.