I'll feign suprise that the banned add-on doesn't give good playback. No further support.
Posts by chewitt
-
-
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.
-
If it's the general issue that seems to show up when warm rebooting after initial install; it's nothing to do with the AMLGX image for C2 and a cold boot (pull power, reconnect, boot again) should fix things?
-
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?
-
Create the SD card first, then the files are just sat there in the boot partition.
-
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.
-
Can someone guide me where to make those changes?
The skin authors in Kodi forums would be the best people.
-
Please update to a current LE12 nightly and retest. Any difference?
-
and also used the system to install Transmission, Qbittorrent
I don't know what your channel is (and not sure I want to be informed). However I will clearly state that if your channel instructs people on how to setup download (aka. piracy) rigs on our distro you are not welcome in this forum.
-
Amlogic mmc controller issues normally exhibit with high-speed card modes and faster speeds and the current/upstream U9-H device-tree is already defeatured to run at a minimum level. The usual way to rule out those issues with modern cards (that have fancy modes and such) is to test with an old, slow, low-capacity card. I have some 2GB cards which aren't much use for an install but are reliable for that kind of testing. Most vendor firmware will power-up the USB section in u-boot automatically which will make the AMLGX boot media discoverable and useable there too, so perhaps try with a USB stick instead of SD card.
NB: For power-issues I'm thinking the device-tree description of how things are connected (which influences driver probing and power sequencing) might be off; not that the PSU itself is bad (although that would also cause problems). The vendor kernel has drivers for a Minix MCU chip which is not supported upstream; the MCU does handle some power things, but it's mostly low-level and the essentials are configured by u-boot so Linux shouldn't really need to care.
