Posts by chewitt

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..

See if https://chewitt.libreelec.tv/testing/LibreE…nopi-r3s.img.gz boots and runs?

The behaviour in suspend is largely determined in u-boot firmware.. but that's all I know. It's not my area of expertise.

ffmpeg[0x105b0020]:   Stream #0:0: Video: hevc (Main 10), yuv420p10le(tv, progressive), 3840x1606 [SAR 1:1 DAR 1920:803], 23.98 fps, 23.98 tbr, 1k tbn (default)

The only unusual thing that I see is the resolution (3840x1606) which has an unusual height (aspect ratio) although later in the log Kodi is selecting the [email protected] mode in the whitelist. I'm wondering if the dimensions fall outside expected limits elsewhere in the video pipeline, e.g. sometimes drivers have hardcoded expectations on things being generally 16:9 or 4:3 ish.

First thing to do in any case is update to a current LE13 nightly to eliminate everything fixed since 12/12.2. Any difference?

Quote from swever

LE is indicating that its only detecting around 4GB of RAM in the System Information

Some of the Rockchip kernel drivers assume 32-bit memory regions (under 4GB) and behave badly when the OS has more, so we currently limit what the kernel can access via mem=3838M in kernel boot params, https://github.com/LibreELEC/Libr…56X/options#L31 to workaround the problems. You can remove the cap and might briefly see 8GB reported, but then it will lock up. LE rarely uses more than 1GB in normal Kodi use so the cap shouldn't be a problem.

This has been resolved. I've forked Milhouse's repo to the Kodi GitHub org where it can be maintained semi-officially.