DVB issue since LE switched to kernel 4.9.x

  • there has been a further regression in later kernels 4.14/4.15?

    I'm afraid so. But unlike the softirq problem this does not affect the recorded stream, this is a playback-only issue. Also, I don't know when this started - I did not test kernels 4.10/4.11/4.12/4.13.

  • I'm afraid so. But unlike the softirq problem this does not affect the recorded stream, this is a playback-only issue. Also, I don't know when this started - I did not test kernels 4.10/4.11/4.12/4.13.

    As mentioned in my previous post, I'm currently running 4.11.12 (kernel shipped with 8.2.2 official generic build) with 4cd13c2 reverted. I've been running this build for the past week or so without any breakups, and have been testing today to double-check I can both record and watch at the same time. I had 3 programs recording and watching a fourth, without any breakups. So I would suggest this further regression has occurred since 4.11.12.

  • So I would suggest this further regression has occurred since 4.11.12.

    I will compile and test a couple of RPi2 builds with kernels 4.12 and 4.13. Thankfully the issue is very easy to reproduce.

  • I enabled CONFIG_SCHED_DEBUG=y and rebuilt with kernel 4.14.10 and Linus Torvalds patch:

    Code
    1. rpi22:~ # grep -H . /proc/sys/kernel/sched_*_granularity_ns
    2. /proc/sys/kernel/sched_min_granularity_ns:2250000
    3. /proc/sys/kernel/sched_wakeup_granularity_ns:3000000

    If you wish to test this build I can upload it.

    I would actually need a kernel without Linus Torvalds patch and CONFIG_SCHED_DEBUG=y to perform the test I want.

    Can you create+upload that for me?

  • But unlike the softirq problem this does not affect the recorded stream, this is a playback-only issue.

    The problem i experienced on my Acer revo with the millhouse builds may therefore be different to those you're seeing on the rpi3, as the issue did effect the recorded stream:

    SHAS


    did you see continuity errors such as these in your tvheadend log?

  • I would actually need a kernel without Linus Torvalds patch and CONFIG_SCHED_DEBUG=y to perform the test I want.

    Can you create+upload that for me?

    Here's a link to #0109e: RPi2


    #0109e is based on 4.14.10 (nothing reverted, no extra buffers commit, no Linus commit) with CONFIG_SCHED_DEBUG=y. This build also includes /usr/bin/perf in case that is useful.

  • did you see continuity errors such as these in your tvheadend log?

    I don't use tvheadend, I use VDR. There are audio dropouts and tons of ActiveAE errors in kodi.log when there is any network activity or during recording to an RPi's sdcard. I just tested a build with kernel 4.13.16 and the issue is there too. Will test 4.12 now.

  • Tested kernels 4.11.9 and 4.10.14. With both I had audio dropouts / ActiveAE errors in kodi.log when recording to an sdcard.

    Absolutely no issues with kernel 4.9.75 + Linus softirq patch. Not a single audio dropout, no ActiveAE errors in log.

  • smp have you tested if you get the same results if recording to a USB HDD instead of sdcard?


    I also noticed that for some unknown reason the LE RPi kernels use the NOOP IO scheduler by default, x86 LE kernel and RPi foundation kernels use the CFQ scheduler.


    You could also try changing the IO scheduler, this can be configured per device. eg:

    Code
    1. echo cfq > /sys/block/sda/queue/scheduler


    so long,


    Hias

  • have you tested if you get the same results if recording to a USB HDD instead of sdcard?

    I actually get the same results even if there is no recording going on (~1 or 2 ActiveAE errors per hour in kodi.log and rare short audio dropouts). Recording just makes the issue far more obvious and easy to reproduce.

  • I have now also tested using:

    8.2.2 official (i.e. kernel 4.11.12) with the Linus Torvalds patch installed, rather than reverting 4cd13c2: BEDD

    This also works perfectly - same results as per reverting 4cd13c2. I can watch live tv and record a further 3 programs at the same time without any breakups or continuity counter errors in tvheadend.


    Further proof that both reverting 4cd13c2 and using the Linus Torvalds patch appear to have the same positive effect.

  • I now tested the patch from Linus Torvalds with kernel 4.9.75 and 4.14.10 and it works great, no issues whatsoever. I can only test on RPi3.

    Hi SMP


    Are you able to use adv (x2) on HD channels now with this patch or is it best to stick with Bob?

  • ... Millhouse build #0108b:

    SHAS

    With this build I can get a stable stream when watching live tv. However, if I watch and record at the same time then I get breakups.


    Millhouse build #0101z: JYUK

    Same as above - I get a stable stream when watching live tv. However, if I watch and record at the same time then I get breakups.

    ...

    I've just been revisiting the issues I was seeing with the Millhouse Builds. I actually get breakups on those builds when simply viewing live TV using the MyGica T230 DVB-T2 Freeview tuner.


    My Machine has 2x DVBSky S960 DVB-S2 (Freesat) tuners and 2x MyGica T230 DVB-T2 (Freeview) tuners. In TVHeadend I have it configured to use the DVBSky S960's in preference to the MyGica cards for those channels where the stream is available on both networks. This is why I was only spotting the issue when both watching and recording - as that was forcing it to use the MyGica T230 card.


    So this looks like it is most likely a problem with the MyGica T230 drivers supplied in those builds so is unrelated to this issue - sorry for the noise.

    Edited once, last by jahutchi ().

  • I maintain the media subsystem at the Linux Kernel. I'm trying to debug this issue with an upstream Kernel and see if it is just softirq or if are there any other adjustments to be made at the media drivers. I just setup libreElec here with a serial console, but I'm not sure what parameters should be passed to Kernel's command line, as the ones that boot with Raspbian don't work on LibreElec. I'm getting this here:



    I'm basically adding those to config.txt:

    kernel=upstream/vmlinuz-4.14.11-mcc+

    device_tree=upstream/bcm2837-rpi-3-b.dtb


    (The Kernel/DT files I'm using were stored at /dev/mmcblk0p6 under /upstream dir)


    That's the content of cmdline.txt file:

    boot=UUID=39F7-FE9B disk=UUID=6ccbd2e9-3b41-4fbd-9af6-f520be468511 root=/dev/ram0 rdinit=/init usbcore.autosuspend=-1 pi3-disable-bt console=ttyS1,115200


    Commenting the kernel/DT lines at config.txt makes it boot RPi's Kernel fork, as usual. So, boot arguments at cmdline.txt should be ok.


    I suspect some sort of initramfs is needed, but I'm not sure how to generate it for libreELEC.