Kodi reads the EDID data to determine resolutions and audio capabilities once at startup and never checks again. One of these days that might change, but that's how the current implementation works. The forced EDID at kernel DRM level means everything on the Linux side (all the way up the code stack) is blissfully unaware that anything on the HDMI connection changes/changed.
Posts by chewitt
-
-
I suggest you read LE 11.0.4 release notes first. If that doesn't deter you, read https://wiki.libreelec.tv/hardware/amlogic
-
"Is there a secret to allowing pasting to work in this forum?
Or perhaps the forum software is broken because I keep seeing ..."
^ seems to work here copy/pasting a screenshot and raw text (macOS 14.1.2 and latest Firefox with a ton of privacy extensions)
-
Cache fiddling can sometimes smooth out the drops/glitches in WiFi, and other times it can't, but if it can it's free. I've also used an old router in bridge mode to traverse longer distances than the weak-as-hell onboard WiFi that lots of boards (not only RPi flavoured ones) have these days. Even old routers usually have better antennae and more receiving power.
-
Both logs show that playback starts in 2.0 pass-through then TrueHD/DTS-MA are detected and AESinkALSA renegotiates to output with 7.1 output. Kodi appears to be doing the right thing here. What spec is the HDMI cable?
-
Please (re)test with an LE12 nightly image.
-
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.
-
Explain "nothing is happening" in more detail.
-
I'll feign suprise that the banned add-on doesn't give good playback. No further support.
-
Have you tried running without it? .. the boards are designed to run way hotter than most users are comfortable with.
-
You can share a Kodi debug log after clean boot and playing a couple of non-working things.
-
No Dolby Vision or HDR10? Meh.... I don't think im missing out on much at this point.
RPi4/5 support HDR10, but not the dynamic version HDR10+ .. otherwise I agree
-
Where is the stream played from (internet, local drive, nas in network)? and if internet/network; how is the Pi connected (wifi or ethernet)?
-
Our empathy for users that write "I love piraty" on post changes and then change their avatar to a pirate flag is low. Your ability to use a custom avatar has been removed and further attempts to be "funny" about piracy matters will result in a ban.
-
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..
-
Using an LE12 nightly image, put Kodi into debug mode, reboot, play something, then run "paste kodi" and share the URL.
-
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.
