Posts by chewitt

    I'm running the bare board inside a closed space (cupboard fronted with speaker cloth) in a room with an ambient (AC controlled) temp around 24ºC. There's no case (so no fan) and it's out of sight and out of harms way .. until the flirc cases start shipping. It's never 40ºC cool but also never that hot, so temps and throttling haven't been an issue.

    Copy a 'problem' test file to the local SD card. If it plays fine (which it probably will) the finger points at the nework being unable to sustain the required data rate. If you bump to an LE12 nightly it's possible to fiddle with cache settings in the GUI (in LE11 you can do the same though advancedsettings.xml) but cache fiddling is a double edged sword and causes as many problems as it solves. If you increase the cache size the RPi5 may be able to cope better with temp glitches in connectivity and data rates, but you'll also need to read more data over the flaky connection before playback starts. The read-factor may be the better tool to adjust, and reducing the cache or read-factor can sometimes also be the solution, not increasing. It's all about what works in YOUR network so it's all about testing and experimentation not reading forum posts on what worked for someone else.

    If the file doesn't play well from SD card .. then it's something else, but my money's on the evil that is WiFi connectivity. I'm playing a wide assortment of very large filesize media from a wired NAS to a wired RPi5 with zero issues.

    The EDID hack ensures the RPi thinks something is always connected; solves missing audio due to slow startup of the connected AVR or TV device when all powered on at the same time. However re-reading your description it sounds more like the receiver loses the connection to the RPi when the source changes; as the other way around isn't possible because the EDID hack ensures the RPi sees something connected and outputs continuously. Hmm..

    I think the root issue is that certs were created with passwords and thus you need to authenticate them to use them, but LE runs OpenVPN as a daemon (non-interactive) process so the correct option is "askpass /path/to/<filename>" so the required certificate password is read from a static file: edit the path to reflect somwhere on /storage where you created the file (plaintext file containing only the cert password). IIRC the "auth-ask-pass" option is used with connections that require interactive user:pass authentication, which is not the same as authenticating the certificate. There's lots of overlapping terminology though so it's easy to get confused.

    I got the YouTube add-on working again but I'm missing something to replicate the problem. All the "audio" content that I can find on YouTube also has video so I see normal video playback not audio with a visualiser. Can you share a link to something?

    IIRC the S905 chip in the Hub does not support the HD formats so cannot pass them through. The DD+/TrueHD streams contain a DTS (5.1) core with additional metadata; the core stream provides compatibility with hardware that doesn't support the full format so you still hear something. Note: no need to rename files if following the wiki instructions to create AMLGX "box" SD cards.

    Kodi provides instructions to draw shapes on-screen using OpenGLES and these instructions are translated by mesa into "jobs" that are scheduled and executed on the GPU cores through the lima driver. The non-exhaustive list of possible opportunities for bugs are: a) Kodi sending bad GLES instructions to the DRM layer (mesa), or b) Kodi sending valid GLES that mesa incorrectly translates into jobs, or c) mesa sends valid jobs that the lima driver does not correctly handle during execution.

    Changing the visualiser is "wagging the dogs tail to make the head move" and does not itself provide much of a clue where things go wrong. I need to see if I can resurrect the YouTube add-on (as it stopped working for me at some point and I switched to Tubed) to see if the issue exists on RPi5 too. If yes, it points to a Kodi issue as mesa effectively runs different code for the Mali 450 GPU in an S905 chip vs. the VideoCoreVII GPU in the RPi5, ergo a failure in both paths would be unusual and indicates something in Kodi-core or visualisation shader doing something wrong. If no (and I suspect it will be no) it's something lower in the stack and we'll need to capture debug job traces and share those with upstream maintainers to see if they can spot the problem.

    NB: Testing on the LE12 image is useful as we're typically running the latest lima/mesa versions so we elimiate any bugs that have already been resolved since the older LE11 versions.