Posts by Zameero

    That's for Apple devices? But I have (had) a different problem.

    Anyway, I think I found the problem and a solution.:)

    The IR-receiver is correctly detected:

    [2.277718] hid-generic 0003:16C0:05DF.0003: hiddev96,hidraw2: USB HID v1.01 Device [www.dvbviewer.info USB IR Remote Receiver] on usb-0000:00:14.0-2.4/input0

    And in the past I used this command in the autostart.sh:

    Code
    hid_mapper64 --manufacturer 'www.dvbviewer.info' --product 'USB IR Remote Receiver' --map 'remote.map' --disable-repetition

    Unfortunately the hid_mapper tool doesn't work anymore, but by activating the "Enable HID remote" in the libreELEC settings, this command is automatically launched:

    Code
    /usr/bin/hid-remote --lookup-id --manufacturer 16c0 --product 05df --map /storage/.config/hid_remote/remote.map

    Note the missing "--disable-repetition". Without that option I get ghost button presses and erratical behavior.

    I've disabled the "Enable HID remote" setting and put the command below in the autostart.sh and now it works correctly.

    Code
    /usr/bin/hid-remote --lookup-id --manufacturer 16c0 --product 05df --map /storage/.config/hid_remote/remote.map --disable-repetition &


    A couple more questions:

    How do I disable eventlircd?
    How can I change the "Enable Hid remote" so that the disable repetition flag is set?

    Hello,

    I used an USB IR to HID receiver based on IRMP for years, initially on X86 machines and then on ARM based devices. It used the "hid_mapper" tool to test, map and decode the IR stream.

    Now I have a new machine with the latest LibreELEC, but the remote doesn't work anymore: The device is recognized, but hid_mapper can't seem to find it.

    After a few searches, I discovered that newer LibreELEC handle the decoding internally; I've been able to set up a (partially) working remote, however I have a lot of problems:

    I'm getting a lot of ghost presses, sometimes the remote is stuck (LE receives the same key continuously) and generally it doesn't work as good as it used to be with "hid_mapper".


    So, I have a few requests:

    Is there an help page on how to set-up an HID based remote?

    Is it possible to make "hid_mapper" work again? Failing that, can someone tell me how to fix the ghost presses/stuck inputs?

    Thanks

    Hi,
    I'm using an S912 box with this build, and I found that some H265/1080p files (can't put the link because ©) can't be played with the hardware decoder.

    I get a few frames, then the image freezes while audio keeps going, and then after a few seconds the cycle repeats (few frames, then freeze with audio). If I remove the audio track, and make a new .mkv file with only the video, I get a still frame that stays locked until I press the arrows on the remote.

    These files play OK with HW decoding disabled, or with HD decoding on the newest (LE13) builds.

    I can't seem to see any meaningful message in the log, is there something that can be done for this problem?


    Found a short sample with the problem, get it here: https://we.tl/t-HbwWX3Ad3d

    Thanks! Remote configuration works!

    IIRC the 10-bit H264 format is not supported in Amlogic silicon so software fallback is the only option (and hence the legacy images do that)

    Yes, the cpu is powerful enough for that, or at least it was in the legacy images.

    However I tried a few H264-10bit files and these don't work at all: With the HW decoding enabled it gives garbled results; With it disabled it's not decoded at all (black screen - audio only).

    Does the PI have a working software decoder?

    Thanks!
    I've tested it a bit on a 's912 tv box and seems to work Ok, but I have a couple of questions:

    Is it possible to use remotes (meson-ir NEC/RC6) other than the default?

    I found that H264-10bit (Anime) is not recognized, and the board always uses HW decompression (with bad results). The legacy builds do switch to SW decompression in those cases.
    Is it possible to solve the problem, or at least to add a switch/setting to always use SW decode for H264?

    There are no open source for rk3528, as I understand. Please anybody correct me if I'm wrong!

    There are unofficial Armbian ports; Almost everything works except the usual quirky stuff that TV boxes have.

    It's the first time I hear of RK3528

    Has been out for a while; Android 13 TV boxes that use it are super cheap: 15~20€ (during promo sales) for 4GB/32GB.

    Good enough for Klipper or similar stuff.

    I've read through the linked thread, but to me it seems to be a different problem: Those devices can't be turned on with the remote, while mine won't stay powered down.

    But I guess the problem is also caused by a faulty u-boot, so I'd like to test the one created by Portish:

    But it has been deleted from github :(

    Where can I find a copy of: u-boot_q201_v2.2_green_pcb.tar.gz?

    Thanks for the explanation.

    I have another question: I have a S912 box (Generic H96Pro 2GB/16GB) that has a problem with the shutdown process: Basically it doesn't work as the machine simply restarts instead of powering off. In Android there's no such problem.

    I've read the "Fix the "power-on bug" in uboot for Meson8* boxes" on the first page, and while testing the AMLGX image I noticed that "suspend" is enabled... And working on my machine: By using suspend (instead of poweroff) the machine powers-off.

    So, I'd like to know if there is any way to invoke a suspend in the legacy build... Maybe there's some hidden setting?

    for v1.3.0 a lot of things would have to be modified. Since Leia's ffmpeg is an old version, even if I wouldn't call it an impossible task, it's not worth spending so much time, because I don't think the situation would improve much.

    However, dav1d v1.3.0 is already present in the LE12 AMLGX image, so if you want to give it a try, I recommend you try that.

    I have an S912 box, and found out it isn't usable with AV1 files :(
    I've tried the suggested AMLGX image and surprisingly the CPU is (barely) capable enough to play it: CPU usage on a few 1080p files I've tried is ~400% on average, roughly the same as H264 10bit software decode. (Although some files are more taxing on the CPU and will lose frames)
    Is there really no hope for the newer dav1d on this legacy build?

    Sorry for the thread hijacking...

    I am testing V11.0 on the same device (generic S912 with 2Gb) and have problems with the shutdown, as it executes a reboot instead.

    Is there a fix for this?

    Moreover, is there a list for the codecs supported by the Hardware decoder?

    I've been testing a few files (H264/10bit ) and have strange results: blockiness, freezes, but sometimes seems to work for a while.

    balbes150 I've tried latest aarch: LibreELEC-ARM-ALL.aarch64-9.80-devel-20200430125433-b18883b-amlgx.img.gz

    Using meson-gxm-khadas-vim2.dtb on a S912 starting from SD (USB doesn't work, gives an error "Could not mount LABEL=LIBREELEC")

    All I get is the logo and then:

    Code
    [   97.908314] kernel-overlays-setup: setup base modules
    [   98.053646] kernel-overlays-setup: added modules from /usr/lib/kernel-overlays/base/lib/modules/5.7.0-rc3
    [   98.115976] kernel-overlays-setup: added firmware from /usr/lib/kernel-overlays/base/lib/firmware
    [   98.131722] kernel-overlays-setup: adding overlays from /storage/.cache/kernel-overlays
    [   98.146622] kernel-overlays-setup: done
    [  102.173839] kernel-overlays-setup: setup base modules
    [  102.310614] kernel-overlays-setup: added modules from /usr/lib/kernel-overlays/base/lib/modules/5.7.0-rc3
    [  102.365419] kernel-overlays-setup: added firmware from /usr/lib/kernel-overlays/base/lib/firmware
    [  102.381177] kernel-overlays-setup: adding overlays from /storage/.cache/kernel-overlays
    [  102.396125] kernel-overlays-setup: done

    which repeats over and over.

    Edit: version 0200410154217-92efcc1 seems to work.