DVB issue since LE switched to kernel 4.9.x

    Quote from nkb88

    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?

    Quote from jahutchi

    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).

    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.

    Quote from gurabli

    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
    2020-05-02 21:40:41.354 TS: DVB-C Network/386MHz/NPO 3 HD: MPEG2AUDIO @ #3211 Continuity counter error (total 68)
2020-05-02 21:40:45.031 tbl-eit: eit: 386MHz in DVB-C Network: invalid checksum (len 288, errors 65)
2020-05-02 21:40:45.031 tbl-pass: pass-eit: -: invalid checksum (len 288, errors 65)
2020-05-02 21:40:45.451 tbl-base: nit: 386MHz in DVB-C Network: invalid checksum (len 997, errors 6)
2020-05-02 21:40:46.489 tbl-base: sdt: 386MHz in DVB-C Network: invalid checksum (len 430, errors 6)
2020-05-02 21:40:46.494 tbl-pass: pass-sdt: -: invalid checksum (len 430, errors 6)
    Code
    LibreELEC:~ # uname -a
Linux LibreELEC 4.19.36 #1 SMP Sat May 4 17:23:44 CEST 2019 armv7l GNU/Linux
    Code
    LibreELEC:~ # lsusb
Bus 001 Device 007: ID 2040:8268 Hauppauge
Bus 001 Device 006: ID 0781:5583 SanDisk Corp. Ultra Fit
Bus 001 Device 005: ID 0b48:3014 TechnoTrend AG TT-TVStick CT2-4400
Bus 001 Device 004: ID 0403:6001 Future Technology Devices International, Ltd FT232 Serial (UART) IC
Bus 001 Device 003: ID 0424:ec00 Standard Microsystems Corp. SMSC9512/9514 Fast Ethernet Adapter
Bus 001 Device 002: ID 0424:9514 Standard Microsystems Corp. SMC9514 Hub
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?

    Quote from menn0

    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.