Posts by chewitt

[Unit]
Description=Hidden SSID Connect Service
After=network.target connman.service iwd.service
Wants=network.target connman.service iwd.service
Before=kodi.target

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/usr/bin/iwctl --passphrase <PWD> station wlan0 connect-hidden <SSID>
ExecStop=/usr/bin/iwctl station wlan0 disconnect

[Install]
WantedBy=multi-user.target

^ Something like that probably works. Create and enable /storage/.config/system.d/hidden-ssid.service

Amlogic uses the same patches in LE11 now - there are several boards with embedded chips or optional RTL8822CS modules.

It looks like I still have this driver in my RPi4 tree (from providing build guideance before) so you can use this image:

https://chewitt.libreelec.tv/testing/LibreELEC-RPi4.arm-11.0.1.tar

I make no promises that it works (if it does, great. If not, so be it). I also make no promises of future images; I have no need for this driver so the first time it fails to compile I'll drop it from my tree.

First read the LE11 release notes so you understand the limitations of AMLGX on an S905X3 board. Then (as per the notes) read the Amlogic boot instructions in the wiki: https://wiki.libreelec.tv/hardware/amlogic - there is no specific device-tree for that box but pick another SM1

Android box and it will probably work (they are all fairly similar).

gonp that kind of confirms the issue is noise on the UART pins. Have you tried resoldering the UART pins?

LE10 uses wpa_supplicant. LE11 uses iwd. I'm not sure knowing that helps, but it probably explains the difference.

Make a backup .. then update to 11.0 via the settings add-on. This avoids the need for clean-install and restore. If (and only if) something goes wrong you have the backup to restore back to 10.0.

P200 is for internal PHY boards with 10/100 Ethernet. P201 is for external PHY boards with Gbit Ethernet (like your box). Cold boot the box with Ethernet connected, then SSH in and run "pastekodi" and share the URL generated so I can see the boot log. This will show if any WiFi drivers and firmware are being loaded (or not).

You should read the LE11 release notes. These clearly state the AMLGX image is not perfect; although it works well with most normal media and codecs but some users have odd content and it might not suit them. They also tell you there is no support for internal DVB cards. I'd need to see debug logs to make any further comment on playback issues. Run "pastekodi" after clean boot and enabling debug logging and demonstrating problems.

All files under /storage/.kodi should be owned by root and except for specific files under /storage/.kodi/addons nothing should be executable; so a simple find/exec command setting 644 permissions but excluding the addons path should work. As a general rule permissions are not something that should end up being changed though, so I wouldn't waste time creating script tools. And that's probably why I've never seen them being created.

None.

    0.000000] Linux version 4.19.62-sunxi ([email protected]) (gcc version 7.4.1 20181213 [linaro-7.4-2019.02 revision 56ec6f6b99cc167ff0c2f8e1a2eed33b1edc85d4] (Linaro GCC 7.4-2019.02)) #5.92 SMP Wed Jul 31 22:07:23 CEST 2019

I think you've pasted the wrong log .. becuase all I can see are Armbian boot logs (Armbian issues are theirs to solve).

Put https://chewitt.libreelec.tv/testing/LibreE….arm-11.0.0.tar in /storage/.update and the WiFi might work. The RTL vendor driver is not in the upstream LE image and I have no plan to add it.

Quote from barturblits

Well it seems my artifacts were an artifact. Cannot reproduce them anymore. I restored the backup I made of Nexus so it is just as I left it last time. But now, no artifacts anywhere, not even the files I tried last time.

Maybe chatGPT-4 can solve the HEVC seeking problem

Then again, it might soon rewrite the entire video driver.

I'm confident there are memory useage/buffering issues in the current HEVC codec, and ultimately there are closed-source firmware blobs involved that can layer their own issues too.

ChatGP is quite interesting but linux media drivers are rather complicated. As Douglas Adams fans will appreciate; the challenge is about asking the right question

Quote from phyrros1

Why does Kodi "Leia" have no problems with HEVC seeking ? What is different to Nexus ?

LE11 uses the upstream Linux kernel that has no code in-common with the LE9 and older vendor kernel. As written in release-notes; AMLGX is not perfect and will not be for all users. I'd love to see improvements to HEVC seek, but I don't write driver code, and there's been a multi-year gap in anyone taking an interest. I'm currently attempting to get the (abandoned but cleaned-up a little) HEVC driver merged upstream in the hope putting the code somewhere public attracts some community contribution.

There's no such thing as "too powerful"

Either the configuration expects files to be in a standard location and you've put them somewhere else, or you configure the location in the add-on (which I don't use or have any experience with) but some kind of unhandled issue with paths or formatting or permissions prevents the files from being read. As generic advice; don't use paths with spaces, ensure the text files have unix line endings (not Windows) and ensure the certs have 600 perms not 644/755/777.

S905L is an S905X without VP9 support, 10/100 Ethernet, no BT, and faked 2GHz CPU (all GXL boards are 1.5GHz). There is no direct support in the upstream kernel but differences from S905X are minor so creating a custom device-tree shouldn't be hard; I started to look at changes for the Venz V10 - though that user disappeared so progress stalled. NB: The current hardware decode drivers assume all GXL boards support VP9 so attempting VP9 media playback will result in blank screens in Kodi.

P201 is a GXBB (S905) device-tree; hence it will not boot a GXL (S905X) derived device. SSV6200 is a newer variant of the SSV6051 chip and also not supported. The SSV vendor drivers are horrific quality (achieving new depths of bad) and do not compile against an upstream kernel, only the vendor kernels. No support means no support.

If you can provide me with the Android dtb file and dmesg boot log, and a working remote control config, I can look at adding support.

The second partition on the SD card is designed to self-resize on first-boot so there is no need to "fix" this non-problem. Just create an SD from the box image and set the dtb name in uEnv.ini .. and that's all to do. As per the Amlogic page in the wiki; do not rename dtb files to dtb.img; do not change the location of files.