TV adapter drivers missing from 11.0.4?

    Hi. I'm running a Pi4, with 11.0.3. I have an Anysee DVB tuner connected, which feeds TVHeadend also running on the same PI. When I update to 11.0.4, no DVR drivers seem to be present for the Anysee. TVHeadend runs just fine, but it sees no attached TV adapters.

    I've searched the forum but couldn't find anything specific, and looked at the release notes, which states

    DVB ADD-ONS

    DVB Add-Ons are currently deactivated. Digital Devices and TBS have currently no support for recent kernels so we are out of options. If you require support for those devices please stay at LE10.


    I', actually not sure what that means. I run TVHeadend client and server, both of which are installed from Kodi itself. So I guess that's not related. Also it shows the same message for previous releases, but still up to 11.0.3 my DVB adapter works fine, in 11.0.4 it does not. The Anysee E30 consists of two USB tuners:

    Zarlink ZL10353 DVB-T
    Philips TDA10023 DVB-C


    Both are not working. Is this to be expected in 11.0.4? When typing this post I see 11.0.5 is just released, would that include the drivers again?

    Quote from CvH

    there are no drivers for TBS and "Digital Devices (that is the actual name)" devices
    everything else is still there

    Then I assume those are brands of TV adapters or something? I am not familiar with those. Anyway, I'm using DVB-C, which means I am using a Philips TDA10023, and using 11.0.3 it identifies as such too (at least in TVHeadend). Is that related to this TBS and "Digital Devices"?

    Please provide a full debug log.

    How to post a log (wiki)

    1. Enable debugging in Settings>System Settings>Logging
    2. Restart Kodi
    3. Replicate the problem
    4. Generate a log URL (do not post/upload logs to the forum)

    use "Settings > LibreELEC > System > Paste system logs" or run "pastekodi" over SSH, then post the URL link

    I was trying to, but it seems https://ix.io/ is 'taking a break'. Seems that service is down. 11.0.3 uses that, so can't paste that log (or can I upload it somewhere, you are very clear I shouldn't upload it here). For now, because of that I'll allow myself to paste a few lines that I think matter. By the way, I tried with 11.0.5 but also no TV adapter available anymore it seems.


    11.0.3:

    LibreELEC:~ # lsusb
    Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
    Bus 001 Device 004: ID 1c73:861f AMT Anysee E30 USB 2.0 DVB-T Receiver
    Bus 001 Device 003: ID 1915:1028 Nordic Semiconductor ASA Smart Control
    Bus 001 Device 002: ID 2109:3431 VIA Labs, Inc. Hub
    Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub


    dmesg output:


    [ 2.598648] usb 1-1.2: New USB device found, idVendor=1c73, idProduct=861f, bcdDevice= 1.00
    [ 2.598661] usb 1-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
    [ 2.598672] usb 1-1.2: Product: anysee-FA(LP)
    [ 2.598681] usb 1-1.2: Manufacturer: AMT.CO.KR
    [ 5.468386] usb 1-1.2: dvb_usb_v2: found a 'Anysee' in warm state
    [ 5.471744] usb 1-1.2: dvb_usb_anysee: firmware version 1.2 hardware id 15
    [ 5.472160] usb 1-1.2: dvb_usb_v2: will pass the complete MPEG2 transport stream to the software demuxer
    [ 5.472281] dvbdev: DVB: registering new adapter (Anysee)
    [ 5.472295] usb 1-1.2: media controller created

    in 11.0.5 pastekodi DOES work: https://paste.libreelec.tv/enabling-vervet.log

    As far as lsusb and dmesg go, they show the same. So I guess the driver is still there. However, TVHeadend Server (which seems to run fine on 11.0.4 / 11.0.5) show no adapters in the config-screen, and obviously when I switch to a TV channel, Kodi says something like 'no free adapter'.

    Looking at the kernel error messages in code; the "Unsupported Anysee version" is caused by a lack of front-end, so the actual error is from the tda10023_readreg function (the line above). However diffing between Linux 6.1.38 (11.0.3) and Linux 6.1.55 (from the kernel bug report) doesn't show changes to that driver other than https://patchwork.kernel.org/project/linux-…foundation.org/ which looks to be a legit bugfix. Perhaps revert that and https://lore.kernel.org/lkml/202307310…[email protected]/ and see if the original behaviour is restored. If yes, the fix isn't complete and something more is needed.

    Quote from Rataplan626

    Is that something I can do or help with?

    Given your IT background, you can probably help :)

    We (meaning you, as we don't have the hardware) need to bisect the kernel changes to find the breaking commit.

    This explains bisecting: https://opensource.com/article/22/11/git-bisect

    Clone the Linux kernel in a Linux VM and start bisecting; the known-good commit is "61fd484b2cf6bc8022e8e5ea6f693a9991740ac2" (Linux 6.1.38) and the known-bad commit is "d23900f974e0fb995b36ef47283a5aa74ca25f51" (Linux 6.1.55). Once started, the bisect process will then suggest a commit (githash) to test. You then mark this good/bad and it suggests another to test, and this process repeats until you find the breaking commit. The bisect process assumes you will build your own kernels. You will, but you need to do this within the LE build-system.

    https://wiki.libreelec.tv/development/build-basics explains how to build an LE image; so create an Ubuntu 22.04 VM to build in and then checkout and build libreelec-11.0 branch (not the master branch) as this is more aligned to the Linux 6.1 kernel. The bisect workflow needs you to modify packages/linux/package.mk and change PKG_VERSION to use the githash that the bisect process suggested. Set PGK_SHA256 to nulll (PKG_SHA256S="") to skip checksum checks then re-run the LE image build command again. The buildsystem will detect that (only) the kernel package has changed and rebuild an LE image with the updated kernel package. Then transfer (scp is easiest) the latest .tar file from the target/ folder over to /storage/.update on your device and reboot to update and test that image.

    If the card is detected correctly go back to the Linux kernel directory and mark that bisect point as good, and then it will suggest a new githash to test with. Repeat the edit/rebuild/test/mark process until bisecting identifies the breaking commit. Then tell us what that githash is, so we can email the kernel maintainers with information.

    And here is question number one. I cloned the linux kernel (git clone https://git.kernel.org/pub/scm/linux/…valds/linux.git) which worked fine on it's own. However when I go into that dir, and do

    rataplan_@ubuntu01:~/linux$ git bisect start
    rataplan_@ubuntu01:~/linux$ git bisect bad d23900f974e0fb995b36ef47283a5aa74ca25f51
    fatal: Bad rev input (not a commit): d23900f974e0fb995b36ef47283a5aa74ca25f51

    Same for the good 61fd484b2cf6bc8022e8e5ea6f693a9991740ac2. So that leads me to think I cloned from the wrong repository? Anyway, a push in the right direction is needed :) By the way, the initial LE build I did to test works fine (apart from the tuner of course) so that's a win already :)

    *sigh* these are the moments I was afraid of, feeling like a total noob. I checked out 11.0.6 which was the most recent at the time. First build an image, went fine. Then I modified package.mk to reflect the bisect suggested commit. Build again and then:


    [QA CHECK] [linux] [safe_remove]:
    path does not exist: /home/rataplan_/http://LibreELEC.tv/build.LibreELEC-RPi4.arm-11.0-devel/install_pkg/linux-2368afd60f647889d90fa4a42c7b27548f77dbd9/usr/share/bootloader/overlay_map.dtb
    cp: cannot stat 'arch/arm64/boot/dts/overlays/README': No such file or directory
    FAILURE: scripts/build linux:target during makeinstall_target (package.mk)
    *********** FAILED COMMAND ***********
    cp -p arch/${TARGET_KERNEL_ARCH}/boot/dts/overlays/README ${INSTALL}/usr/share/bootloader/overlays
    **************************************
    *********** FAILED COMMAND ***********
    ${SCRIPTS}/build "${1}" "${PARENT_PKG}"
    **************************************
    FAILURE: scripts/install linux:target has failed!

    The following log for this failure is available:
    /home/rataplan_/http://LibreELEC.tv/build.LibreELEC-RPi4.arm-11.0-devel/.threads/logs/142.log

    >>> linux:target seq 142 >>>
    [273/280] [FAIL] install linux:target

    The following log for this failure is available:
    /home/rataplan_/http://LibreELEC.tv/build.LibreELEC-RPi4.arm-11.0-devel/.threads/logs/142.log


    Log attached. I've been looking for a bit to get that fixed. I checked https://github.com/raspberrypi/linux/issues/5272 but so far no sigar.

    Had some time to fiddle with it again, but I can't get it to work. In my last try I checked out 11.0.3, build that, which builds and works fine (as expected). When I change packages/linux/package.mk to reflect the suggested commit, it fails again with the same overlay_map.dtb error.

    If anyone has a clue hoe to get the kernel to build properly, that's be awesome.