Posts by beredim

    I have a couple of Wetek Play (Openelec edition) boxes I just pulled from storage, and apparently they are still working (minus one of the two remotes which is missing, who knows maybe it'll turn up). Both of the Wetek Plays I have are currently on LibreELEC 8.2.5.

    I have some questions and this may not be the best forum to answer them, but if you have any pointers on which forums/communities I can try please do throw them around.

    1. I was thinking of using one of them as a proper linux box. Maybe some version of Debian or something. This would be mainly to have an always-on machine on my home to run some lightweight docker containers (e.g. a Twingate connector), maybe as a print server and generally lightweight things of this nature. I remember that at a time there was even a full desktop Ubuntu 14 image floating around on the now dead Wetek forums. Sure I could do these things with a Raspberry Pi, but why go to the trouble of buying yet more hardware. Does anyone know of what I could install? I know there is Armbian but I don't know if it's compatible.

    2. I distinctly remember having trouble (on occasion) in the past with the SIM card inside the Wetek Play. Sometimes it would lose contact, and the machine wouldn't boot. Then you have to disassemble the box & reseat the SIM to fix the problem. Does anyone actually know the purpose of that sim card? Is it some kind of hardware lock? And can we cancel it? Whatever its purpose I would guess it no longer serves that effectively, so if it can be removed/cancelled as a feature that's one less thing to worry about.

    3. How about the second Wetek Play? I noticed that there are still community builds supporting it. Since I already have a more modern machine (ASUS PN50) running LibreELEC for video, and I don't really need the TV tuner:

    - I was thinking maybe using it as a LibreELEC headless/music-only player. Then I would need advice on which addons I could try for that (thinking of features such as Internet Radio, remote library and playback control from phone, playback over network etc)

    - Another option is if netflix is available with the latest community build, I could use it as a netflix machine at another location where a new smart tv is not yet a priority.

    4. How about that serial cable that came bundled with the Wetek Play? is it just for debugging? Any other 'crazy'/interesting usages it could have?

    4. Please give any other suggestions you see fit, maybe there's a use case for these machines that would serve a need that is not a top priority right now and has skipped my mind.

    See also: RE: Asus PN50 challenge

    There was an issue with the IR module not working on the ASUS PN50. A kernel patch was developed and in newer kernel versions (i.e. LE 11 nightlies) it now works.

    Patchwork link: https://patchwork.kernel.org/project/linux-…[email protected]/


    I need a bit of help doing a PR on the 10.0 branch to backport this (I have already tested it).

    1. Should there be a relevant issue opened before the PR ?
    2. How are patch files in "packages/linux/patches/default" named? How should my patch file be named?

    Hey mccrae

    Thanks for your input.
    Unfortunately I haven't had the time to look further into my PN50. It's been sitting off for a few months now and I don't think I'll be able to test anything until the end of summer.

    1. Regarding the linux-media link you have posted, it's the one that led me to a temporary solution for the PN50. I revived that discussion in that mailing list & posted a first version for a patch. I didn't have the time to follow it up, but I think one of the maintainers there did and added a final version of the patch patch to the kernel modules.

    2. I also shortly fell into the 'rabbit hole' of trying to edit/recompile my BIOS DSDT tables for the PN50 when researching this. I didn't spend a lot of time though, as I couldn't recompile without errors/warnings and didn't know enough to overcome these.

    Yes, I see what you mean.

    According to that email thread it's the motherboard that is reporting the wrong register length of 16 in the ACPI tables

    (while the device is still supposed to have an register length of 8 )
    So by changing the register length to 16 in the driver, I am borking every other motherboard with correct ACPI tables, and possibly the PN50 in case a BIOS update fixes the value in the future.

    I'll try your approach.

    * It's a mystery to me how this ended up being an issue. It seems ASUS has been using the same ITE8708 since ages ago.

    I was thinking of a double approach:

    1. Do a pull request on the LibreELEC github, with the above patch, so that it hopefuly becomes a part of the future stable LE 10.0

    That way I can soon go back to using nightlies to further test the PN50 (at least until the next beta), instead of having to compile my own builds.

    2. In addition, try to push this upstream to the appropriate linux mailing list, so that it becomes a part of the kernel drivers at some point, and possibly also backported (if that's an option). I'm not really sure how long that's going to take.

    So for 1 I guess I'll do a PR on github. Does that sound good?

    And for 2 I'll start by dropping an email on the linux-media list

    Success

    Code
    [    4.677490] ite_cir: Auto-detected model: ITE8708 CIR transceiver
    [    4.677492] ite_cir: Using model: ITE8708 CIR transceiver
    [    4.677492] ite_cir: TX-capable: 1
    [    4.677493] ite_cir: Sample period (ns): 8680
    [    4.677493] ite_cir: TX carrier frequency (Hz): 38000
    [    4.677494] ite_cir: TX duty cycle (%): 33
    [    4.677494] ite_cir: RX low carrier frequency (Hz): 0
    [    4.677494] ite_cir: RX high carrier frequency (Hz): 0
    [    4.758949] rc rc0: lirc_dev: driver ite-cir registered at minor = 0, raw IR receiver, raw IR transmitter
    [    4.759098] ite_cir: driver has been successfully loaded

    I am attaching the kernel patch I made
    linux-9999-pn50.patch.txt

    It was that email thread I posted earlier
    ITE8708 on ASUS PN50 uses a 16 byte io region — Linux media
    where the answer was hiding, but it took a lot of effort from my part.
    First time building LibreELEC, first time writing a patch and so on.

    ir-keytable now works correctly :D

    I'll need some help pushing this, at least as a patch to libreelec project, and possibly to the linux drivers. Can anyone help with this? pinging chewitt

    As far as I can tell after digging through dozens of forums/posts/reddits this is the first publicly documented instance of the IR module in the PN50 actually working

    I have also tried following the same methodology described in
    📡 Getting the Fintek IR receiver to work with Linux | @GregNau – Apps and Blog

    &

    Getting the IR receiver to work with Haswell NUCs - The NUC Blog

    So for the PN50 I figure the commands should be:

    Code
    modprobe -r ite-cir
    echo "auto" > "/sys/bus/acpi/devices/ITE8708:00/physical_node/resources"
    modprobe ite-cir

    After this, dmesg output remains the same:

    Code
    [  997.359200] ite_cir: Auto-detected model: ITE8708 CIR transceiver
    [  997.359203] ite_cir: Using model: ITE8708 CIR transceiver
    [  997.359207] ite-cir 00:02: IR PNP Port not valid!

    and ir-keytable still returns No devices found.

    1. There is one more direction to look at, that is this mail thread I found, regarding the PN50 specifically:

    ITE8708 on ASUS PN50 uses a 16 byte io region — Linux media
    Sadly, this mail thread never resolved to something, as far as I can tell. I am not sure, but I think it indicates the cir module in the PN50 is somewhat different than what the driver expects.

    2. The /sys/bus/acpi/devices/ITE8708:00/physical_node/resources has the following contents:

    Code
    state = active
    io 0x280-0x28f
    irq 10
    dma disabled

    However, /proc/interrupts doesn't show IRQ 10 as being used:

    Code
    pn50:~ # cat /proc/interrupts
                CPU0       CPU1       CPU2       CPU3
       0:         38          0          0          0  IR-IO-APIC    2-edge      timer
       8:          0          0          1          0  IR-IO-APIC    8-edge      rtc0
       9:          0          1          0          0  IR-IO-APIC    9-fasteoi   acpi
      11:          0          0          0          0  IR-IO-APIC   11-edge      AMDI0010:01
      25:          0          0          0          0   PCI-MSI 4096-edge      AMD-Vi
      26:          0          0          0          0  IR-PCI-MSI 20480-edge      PCIe PME
      27:          0          0          0          0  IR-PCI-MSI 34816-edge      PCIe PME
      28:          0          0          0          0  IR-PCI-MSI 36864-edge      PCIe PME

    Well I had some time to work on the PN50 today.
    I got stuck trying to setup my ir remote.

    ir-keytable returns No devices found

    and in dmesg it shows

    Code
    [ 3.338380] ite_cir: Auto-detected model: ITE8708 CIR transceiver
    [ 3.338382] ite_cir: Using model: ITE8708 CIR transceiver
    [ 3.338385] ite-cir 00:02: IR PNP Port not valid!

    Using LibreELEC (community): nightly-20210313-c5d7822

    Any ideas?


    PS Just saw 10.0 Beta 1 has been released. dmesg output is the same

    It's the Ryzen 3 4300 model. Did a build with a Kingston A2000 nvme, and 16GB of 3200Mhz ram.

    A bit overkill on the specs for LE, but I figured if I weren't satisfied with the experience, I'd still have a well spec'd machine for some other workload.

    Well I think I'll be hijacking this thread. My new PN50 just arrived, so...

    • I can confirm latest stable refuses to boot. Managed to boot LibreELEC-Generic.x86_64-10.0-nightly-20210307-7932f3f.img successfully.
    • System did shutdown successfully on nighty v10. Didn't test reboot yet
    • Haven't tested IR yet.

    Deezle Audio passthrough for TrueHD seems to work after a quick test. I'll try to report in detail in the following days

    I think it's about time I replaced my old NUC5CPYH, and was looking at the ASUS PN50 (the Ryzen 3 version probably)

    1. What's the status of support 3 months after the OP? Would I have to go with a test/nightly build?

    2. @ karpediemrsi Have you tested the IR receiver? Is it supported out of the box on libreelec (like the NUC ones) ?

    Actually it was hardware problems (combined with my lack on experience on EXT4) that led me back to NTFS after a catastrophic loss of data that even PhotoRec couldn't save in the end. (about 8TB worth).

    So now I'm trying to move whatever else I have on EXT4, back to NTFS, so that I can more easily work with them on Windows in case of problems.

    In the end, after a lot of trial and error, I managed to create new NTFS partitions (using GParted) that mount fine both on LibreELEC and Windows 10.

    Something in my setup, causes Windows 10 created GPT/NTFS partitions to be problematic on linux.

    Again, thanks to everyone for their help.

    Regarding the actual fix/patch discussed earlier, as I said, I can't offer any advice because it would appear my problems originate elsewhere. Unless someone can verify the fix actually works (or at least doesn't introduce new issues) I would advice against merging it.

    Big thanks to everyone for their help.

    Unfortunately, it seems my problems may be different than what I thought.

    I tried both the builds provided, and also a Fedora 28 live CD.

    In all three I failed to mount my NTFS drives.

    So I can't really comment on the fix (maybe it works, maybe it doesn't, maybe it solves some problems and causes others), but it would seem something else is wrong with my NTFS drive.

    If anyone has any more pointers on how to research my problem I would appreciate it. What I have until now:

    - External enclosure with 4TB NTFS drive

    - Windows 10 Home fully updated

    - Fast boot is disabled, and powercfg /h is set to off

    - Windows 10 sees the drive perfectly well, chkdsk reports no errors

    - fdisk -l claims "The primary GPT table is corrupt, but the backup appears OK, so that will be used."

    - gdisk output

    Sorry for reviving this old thread, but it seems to me that:

    a. This problem still persists & I think I'm facing the same issue. NTFS disks without errors from fully updated Windows 10 system that fail to mount on LibreELEC

    b. Windows 7 installation base is constantly decreasing (and I do not have access to a Windows 7 system atm, only fully updated Windows 10 systems)
    c. There seems to be a bugfix available for this exact issue at Bug 1527231 – Linux cannot mount NTFS filesystem from Windows 10 creators update 1709

    If (c) indeed corresponds with the issue described, I'll be happy to test a build (if someone can port the fix).

    Intel has released a security advisory about a series of critical vulnerabilities that can lead to loading and executing code even outside the visibility of the operating system.

    Intel® Management Engine Critical Firmware Update (Intel SA-00086)
    Intel® Product Security Center

    Alongside the advisory they have also released a diagnostic tool that allows you to check your system:

    Download Intel-SA-00086 Detection Tool

    This also comes in a Linux flavor that appears to run in the LibreELEC shell.

    So check your systems, ask your manufacturer for BIOS updates if needed, and stay safe.

    *A number of Intel NUCs (a favorite for LibreELEC) appear to be vulnerable --> SA-00086 for Intel® NUC, Intel® Compute Stick and Intel® Compute Card

    with BIOS updates scheduled for December.