If the OS date/time has not been updated via NTP (which would be unusual) it can mean the OS time is before the validity start-date of TLS certificates used by websites; ergo the cert is invalid (from the OS perspective) and comms can fail. That's simple to check via SSH and usually somewhat human-readable in a Kodi debug log.
Reboot with Kodi in debug mode and run "pastekodi" and share the URL so people here can read the logs.
LE 11.x supports NTFS, but we switched from the NTFS-3G (FUSE) drivers to the upstream/in-kernel drivers, so there are technical differences and likely new and exciting error messages to discover and understand.
Best to read/check the add-on support thread in the Kodi forums.
Best to check/read the add-on support thread in the Kodi forum, and if needed ask the Q there, since it's not really an LE issue.
The correct resolution would be getting a NAS device to avoid all the wiring and silliness associated with USB devices .. but I doubt that's the answer you're looking for 
You'll need to share a boot log for any serious comments. That will also shed some light on what device you connected all the drives to..
It sounds like more of a hardware problem than software. Perhaps a bad power-supply? .. or dry solder joints on the PCB inside the box? .. or failing RAM .. it's hard to comment when it's hardware (and hardware issues can't be fixed with software).
Bookmarks and Series/Episode watched status are different. Bookmarks are temporary; they exist only for a single episode to permit restart at the same point in a single episode. After the episode is watched, the bookmarks are cleared. Similarly (but separately) TV show episodes are watched/unwatched, and this allows Kodi to position which episode is next in a series when you navigate into a series. Watched/unwatched status is persistent in the library views, so once an episode or series has been watched it remains 'watched' .. but this can be changed via the context menu; and you can set the series as watched or unwatched.
All this is documented in the Kodi wiki: https://kodi.wiki
Perhaps try adding "video=HDMI-A-1:1920x1080M@60" to the kernel boot params in /flash/syslinux.cfg .. "mount -o remount,rw /flash" to make the partition read-write first.
RPi4 is no longer unobtanium so pricing is returning to normal. The 2GB board it's not the $20-30 device you're looking for, but if you want something super reliable and no issues or guesswork on software support.. that's the device.
This is the current also conf we embed: https://github.com/chewitt/alsa-l…sound-card.conf
This is an older version: https://github.com/chewitt/alsa-l…sound-card.conf
The older conf has all the analogue device pcm extras needed for speaker-test to work with multiple channels. In the absence of all of them (as per the current conf) speaker-test will only output stereo since this is all the default pcm device supports/exposes. This is 100% same on my system; which happily outputs multi-channel PCM and PT on the HDMI connection (which is not the analogue pcm device). So kudos for playing "spot the difference" .. but this difference is not the thing you are looking for.
NB: The only reason the older conf exists was an earlier attempt to work around a driver not-technically-a-bug where alsa does not pass mixer controls correctly. This patch hacks a fix: https://github.com/chewitt/linux/…702a070dc71c133
I'd ask that you play with cables and AVR/TV ports. Multi-channel output depends on the ELD data read from EDID/HDMI and the usual "but it works in the legacy image!" claim means little due to a) the upstream codebase being 100% different, and b) the amount of hideous stuff the legacy kernel ignores/overrides/fakes to work around TVs and monitors that provide bad/broken EDID data.
And yes the greatest percentage of AMLGX users are probably using default 2-channel output. However, enough folks have complained about the earlier multi-channel state (that the kernel patch resolved) that I know people are using multi-channel output.
Can you retest with a current nightly image .. I believe the kernel should be newer than 6.1 by now. Let's see if that changes anything..?
It makes no difference. VNC relies on copy/cloning the windowing system output. LE does not use a windowing system. So VNC would need an interface that taps directly into the zero-copy (designed not to copy/clone content) display pipeline.
You cannot select between the AVR or the de-embedder in Kodi, it will only offer "the" device it sees on the HDMI connection. If the splitter claims to be passing-through the properties of the upstream device or it's injecting properties .. no idea. If the splitter device is giving you problems perhaps remove it and attach the HTPC direct to the AVR, then run "getedid" to capture the EDID from the AVR and set things up so the HTPC/Kodi always sees the AVR as direct-connected. Then place the de-embedder back in the chain and hope it all still works.
Read previous posts. Nothing changed.
LE is not a conventional Linux distro, so /var/lib/alsa exists inside the read-only SYSTEM file and there is no asound.state file there because it is not required (sound is configured on each boot). There is also no need to create alsa.conf files since PCM and PT work fine with the default board based conf that we embed in the image (the "error" message that you post shows "Found hardware: gx-sound-card" which proves this is loaded). All GXBB devices have the same alsa.conf and this is proven with a large number of box/board devices, and C2 is the most-used device with the AMLGX image. I have no idea what the issue is, but I'm highly confident it's local to your iLE nstall or more people would be complaining (and it works fine here). Have you gone through the normal routine of checking cables, ports?
should I worry about any settings I need for the SSD, Trim etc?
It's no longer 2008, SSDs are normal, and the kernel understands when trim etc. are needed.
Thank you, yeah I should have mentioned I'm currently working with CE
You are definitely in the wrong forum then, and the kernel mailing list won't be interested in the problem either. Neither of us support the vendor codebase these days.
