DVB issue since LE switched to kernel 4.9.x

  • Anymore hints? Otherwise I'll try to reinstall everything... And maybe switch to LE9


    In that case I would test whether the situation is improved in the LE9 millhouse builds.


    I have two MyGica T230 sticks too which work just fine for me under LE 8.2.3 on my Generic machine, though I use DVB-T2 rather than DVB-C which could be the difference.


    Presumably, you've only enabled DVB-C in the TVHeadend adapter settings and have not enabled DVB-T?

  • In that case I would test whether the situation is improved in the LE9 millhouse builds.


    I have two MyGica T230 sticks too which work just fine for me under LE 8.2.3 on my Generic machine, though I use DVB-T2 rather than DVB-C which could be the difference.


    Presumably, you've only enabled DVB-C in the TVHeadend adapter settings and have not enabled DVB-T?

    Yes - I only use the DVB-C tuner in TVHeadend. I lightly overclocked the RPi3 now and seem to get less freezes - but still once in 10-20 minutes, where picture and video freezes for a few seconds.


    Which logfile could I post here to possible get some hints in the right direction here? Maybe the service.log from the tvheadend-folder?


    Thanks!

  • I'm on 8.2.5 here and still have problems, although it's different now - either the channels will play fine with no issues (no green gunge like before), or not at all and throw constant "Continuity counter" errors. It appears to be channels on certain muxes that are less reliable than others, e.g. 10847V on 28.2 °E - but for some reason if I tune to some other mux (e.g. 10773H) then back to the unreliable one it is much more likely to work. It seems somewhat consistent with changing between polarisation, but I'm not sure if that's just coincidental.


    I'm on an RPi3 with a DVBSky S960 (reported as Montage Technology M88DS3103 in tvheadend).

  • I still have continuity errors on Rpi2 and DVBSky S960, on 8.2.5 or latest 9 build.

    What would you recommend?

  • Kernel issue that was causing DVB stream corruption was fixed months ago.

    DVBsky devices do have an unresolved issue with new kernels as described in this thread but this has nothing to do with continuity errors in tvh.


    What would you recommend?

    Did it ever work without errors? Check if you have a good signal. Try a clean LE installation without any unnecessary addons. Make sure that there are no background processes that could interfere with the DVB stream.

  • Thanks. I thought so that continuity errors were resolved. Still, I get them. Will try a clean install, maybe that can be the problem.

    I did see the new issue on another device when scanning sat, time out on no signal lock. :(

  • Hi community,

    Have a problem (since when exactly, I really don‘t know).

    I‘m using TV Moscai as PVR backend. The TV Mosaic server runs on a Windows Server machine

    LibreElec run‘s on a small Intel Unit

    I‘m using the milhouse-builds and doing updates quite regular (current running the build 1102)

    I‘ve the artefacts on some TV channels, on some not (eg ORF1 has no problems, PRO 7 shows the artefacts)

    When showing live tv on an ipad with the tv mosaic app, the colors look regular and there are no artefacts


    Since I found no other thread, i posted my question here. Maybe someon could lead me to a solution, that would be great!


    Thx, —muehlberger

  • I still suffer from this when I enable both my USB tuners on a non-overclocked rapsberry pi2b.


    Details;


    Code
    1. 2020-05-02 21:40:41.354 TS: DVB-C Network/386MHz/NPO 3 HD: MPEG2AUDIO @ #3211 Continuity counter error (total 68)
    2. 2020-05-02 21:40:45.031 tbl-eit: eit: 386MHz in DVB-C Network: invalid checksum (len 288, errors 65)
    3. 2020-05-02 21:40:45.031 tbl-pass: pass-eit: -: invalid checksum (len 288, errors 65)
    4. 2020-05-02 21:40:45.451 tbl-base: nit: 386MHz in DVB-C Network: invalid checksum (len 997, errors 6)
    5. 2020-05-02 21:40:46.489 tbl-base: sdt: 386MHz in DVB-C Network: invalid checksum (len 430, errors 6)
    6. 2020-05-02 21:40:46.494 tbl-pass: pass-sdt: -: invalid checksum (len 430, errors 6)
    Code
    1. LibreELEC:~ # uname -a
    2. Linux LibreELEC 4.19.36 #1 SMP Sat May 4 17:23:44 CEST 2019 armv7l GNU/Linux


    Code
    1. LibreELEC:~ # lsusb
    2. Bus 001 Device 007: ID 2040:8268 Hauppauge
    3. Bus 001 Device 006: ID 0781:5583 SanDisk Corp. Ultra Fit
    4. Bus 001 Device 005: ID 0b48:3014 TechnoTrend AG TT-TVStick CT2-4400
    5. Bus 001 Device 004: ID 0403:6001 Future Technology Devices International, Ltd FT232 Serial (UART) IC
    6. Bus 001 Device 003: ID 0424:ec00 Standard Microsystems Corp. SMSC9512/9514 Fast Ethernet Adapter
    7. Bus 001 Device 002: ID 0424:9514 Standard Microsystems Corp. SMC9514 Hub
    8. Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub


    Dmesg;


    Running only one of either USB tuners gives zero continuity errors. What should I do?

  • I havent tested that, I always had this running with just one usb tuner with the above tuner. (technotrend) than added the WinTV last week and started testing running them at the same time.

    Since this thread mainly focusses on older kernels I thought it was already out of the window @4.19.36.

    If not Ill be happy to rollback to an older version mentioned here.


    It seems clear to me that the timing on the shared USB bus throws the raspberry pi off and all these timing issues start to emerge.

    I was running 9.0.2 and remotely updated now remotely which made it hang.


    Can you recommend a specific older version for me to try?

  • Since this thread mainly focusses on older kernels I thought it was already out of the window @4.19.36.

    Yes, that issue that was introduced in kernel 4.9 was fixed a long time ago.

    In my experience Pi3 can barely handle 1 USB tuner, so I'm not surprised that Pi2 can't handle 2. I'm not sure this is fixable by software.

  • Later on I'll try the old kernel, but it remains insteresting this because CPU load is only 60% (of 400) and there's 1gb of ram etc.

    If the Pi2 isnt capable it seems it's due to its USB irq management, or lack of it. 480mbit should be enough to receive 2x 10mbit HD stream and than send it over its ethernet port.