Posts by chewitt

OpenVPN works fine but lots of people (mostly folks that fell for the 'privacy' BS marketing of VPN services and have no real-world need for VPN in the first place) don't make the effort to learn basic commands and instead search for add-ons that allegedly make it easy (but under-the-hood mostly complicate it).

In short:

• Save/store/place your OpenVPN conf file (and if not embedded in the conf, the cert files) in /storage/.config
• Create a systemd service for OpenVPN in /storage/.config/system.d/ that executes OpenVPN with an explicit path to the OpenVPN conf file in /storage/.config - You can use the wireguard example file to crib 95% of the required content.
• Enable and then Start the systemd service and you should have a working and persistent OpenVPN connection

This works for any OpenVPN service.

The kodi.old.log contains the previous session. If the session crashed then you have a kodi crashlog instead.

[provider_wireguard] <= changed
Type = WireGuard     <= changed
Name = ProtonVPN     <= changed
Host = 1.2.3.4 
WireGuard.Address = 10.2.0.2/32 
WireGuard.ListenPort = 51820 
WireGuard.PrivateKey = <hidden>
WireGuard.PublicKey = <hidden>
WireGuard.DNS = 10.2.0.1 
WireGuard.AllowedIPs = 0.0.0.0/0, ::/0 
WireGuard.EndpointPort = 51820 
WireGuard.PersistentKeepalive = 25

^ See above for some formatting fixes; formatting is important. Working?

The 5c image in my test share now has the patches RadxaNaoki linked (inc. the audio fix) above. The previous image only has the &hdmi0_sound node added, not the i2c node.

If gnarlsnishi confirms all is working I'll push a kernel/patches update to official LE nightlies. I've been holding off bumping the kernel to 6.18-rcX as there were PCI issues in the initial rc releases, but those seem to be resolved upstream now.

f1gogata no idea what the problem is but I've updated the branch with current patches and it works for me. NB: I'm building on an older Ubuntu 22.04.5 (LTS) host.

Nightlies are created on a "best efforts" basis so there is no guarantee or promise of one being created every night. If there is no nightly there is no real need to post about it because 99% of the time any cancelling of nightly builds is our doing so we already know about it, and if something is broken we get alerts and know about it, and if there are no changes and thus no nightly to be built, we're enjoying some downtime and don't need the distraction of forum posts.

Quote from Sammy

I have reinstalled VPN Manager for OpenVPN .. 7.04 (Gaia Respository)

Your problem is not our problem https://kodi.wiki/view/Official:Forum_rules/Banned_add-ons

Oct 13 15:01:55.422594 LibreELEC kernel: dwhdmiqp-rockchip fde80000.hdmi: i2c read timed out
Oct 13 15:01:55.422709 LibreELEC kernel: rockchip-drm display-subsystem: [drm] HDMI Sink doesn't support RGB, something's wrong.

^ No idea what this means, but I have a hunch this is likely to be responsible.

It's an odd behavior. Is the DAC externally powered? I'm wondering if the PSU is sufficient.

Please update to the latest LE13 nightly and see if anything gets magically fixed there?

I've seen similar issues with ARM SoC boards and the typical solution there is changes to device-tree files to correctly describe the hardware (and how it is powered) but x86_64 hardware doesn't require/use device-tree things at all, so that's not relevant.

No firmware is required for the internal USB hubs.

Please update to the latest LE13 nightly and see if the newer kernel etc. in the image randomly fixes anything?

gnarlsnishi The only other difference I can see in hdmi0 nodes between Rock 5b (3588) and 5c (3588s) is something related to FRL support which is not (or should not be) linked to HDMI audio support. I've updated the rock5c image in my testing share so device-tree has the extra line though, but I can't see it changing anything. So:

a) Put Kodi in debug mode, update to the latest 5c image in my test-share, reboot, then run "pastekodi" and share the URL so I can see some other things in the system log.

b) If that didn't magically change something, edit extlinux.conf in the boot partition of the SD card and experiment with some other rk3588s board device-tree files (all are in the 'rockchip' folder on the SD card) and see what happens. Some might not boot. Some might not show HDMI either. If one does show HDMI audio .. let me know which one.

EDIT: Wait 30 mins until I rebuilt and sync'ed new files!

EDIT: Files are now posted..

gnarlsnishi I can see the device-tree for Rock 5A/5C is missing the &hdmi0_sound node so I think you will only see the Analogue audio output on the board? - If yes, the images in my test share have been updated to add that and HDMI audio should be visible. If you can test and confirm HDMI audio is now working (for PCM output) I'll send the patch/change upstream to the kernel.

Filebrowser is an add-on not a Docker container. The default credential is admin/admin. If you changed them and forgot the details the easiest option is to uninstall the add-on, and when Kodi asks if you want to keep add-on settings, say 'no' and allow everything to be removed. Then reinstall the add-on and it will reinstall to defaults again. If you say 'yes' it will reinstall with the old (forgotten password) settings.

It has HDMI and the SoC has a GPU in silicon .. so I'd guess that's okay

Quote from LAP1

Is there a minimum USB stick size in "Run" mode to play a 25 GB .m2ts file without problems?

26GB would do it, but since those don't exist the logical size would be 32GB

Quote from LAP1

What is the "nightly" version?

LE13 development image: https://test.libreelec.tv/13.0/Generic/Generic/ (scroll to the bottom for latest)

Kodi has standard/advanced/expert settings modes and standard hides some of the PT audio options. Are you using the higher ones? .. have you enabled True-HD pass-through?

If yes to both I'd ask you to update to a current LE13 nightly and test again (and share a log using the pastebin function in the LE settings add-on) as this eliminates everything that got fixed since LE12.x; even if we find an issue on 12.x now the fix will be in 13.

Ahh, I'm not interested to add support for boards that nobody is using so it's not in the official list right now. The board appears to have upstream kernel and u-boot support so adding it is a trivial task. How it then works is a different set of questions; Rockchip is still maturing but moving in the right direction.

Are you talking about the OS configuration wizard in the Kodi GUI (system name, wifi, services, etc.) or the installer wizard used for selecting a target disk to install the OS to?

If the former, this is good and the box is booting okay and you have a clean Kodi environment (as /storage/.kodi was renamed out of the way). This was intentional to ensure there is no conflicts with add-ons compiled for Xorg not GBM. You can restore the previous config by stopping Kodi and swapping the folders around again; or if there are any issues, by stopping Kodi and moving specific bits of config back again (add-on settings, sources, passwords, etc.). Binary add-ons like screensavers/visualisers compiled for the Generic Legacy (Xorg) image are not compatible with the Generic (GBM) image so I would normally suggest the partial restore option, or swap folders back but deliberately nuke /storage/.kodi/addons/* then reinstall add-ons.

If the latter, no idea what's going on..