Posts by chewitt

    RPi boards have no real-time-clock (RTC) hardware so 'dateTime' in the OS initially starts from the libc release date (in the LE image you're using this is a date in Febuary 2023) and then once the network is up an NTP request to pool.ntp.org time servers corrects dateTime. At least, that's what's supposed to happen. In your case boot looks normal and I can see the board gets an IP, but NTP isn't resetting dateTime so the clock remains in Febuary, and this means any website/service that presents a TLS certificate with a start date newer than the OS clock is seen to be in the future and invalid, which renders that website/service inaccessible; and this can be seen in the logs.

    It's unclear why the NTP request is failing, but that's the cause of the issue. The workaround is to set the correct date/Time using the "date" command via SSH, but this will not be persistent over a reboot due to the lack of RTC chip on the RPi board.

    Some ISPs seem to block NTP requests to pool.ntp.org servers, in which case another can be configured and used via the LE settings add-on or through 'connmanctl' (the connection manager utility). Many routers will also respond to an NTP request.

    Kodi is not good with large file listings, but this is how Kodi is coded (and something likely changed between Leia and Matrix) so your options are to seek changes from the people who code Kodi (via the Kodi forum) .. or since everything is open-source, you can modify Kodi code and recompile things yourself (although few users will have the skills for that).

    RPi2 (1GB) should be as smooth at H264 decoding/playback to RPi3/4; except for being slower at everything requiring CPU, e.g. navigating around the Kodi GUI (where RPi3 is quicker and RPi4 considerably quicker). The VC1 license won't help H264 (as different codec). If you only need offline media you might want to compare the older LE 9.2.x release with LE11.x as it's a little lighter and more optimised on older Pi hardware.

    Code
    2023-08-30 18:37:01.357 T:910      info <general>: ffmpeg[0x3cb1230]:   Stream #0:1(por): Audio: ac3, 48000 Hz, stereo, fltp, 384 kb/s (forced)
    2023-08-30 18:37:01.357 T:910      info <general>: ffmpeg[0x3cb1230]:   Stream #0:2(eng): Audio: dts (DTS), 48000 Hz, 5.1(side), fltp, 1536 kb/s (default)

    ^ Have you selected the right audio stream? .. it looks like the Portugese audio is stereo, and English is 5.1.

    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.

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

    /shrug

    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

    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.

    /shrug