Thanks for confirming. We understand which change causes the difference.
Please see if adding SDRAM_BANKLOW=3 in config.txt changes the experience?
Posts by chewitt
-
-
The (bad) log shows two videos, one HEVC, one H264. To confirm, the video is choppy with both videos?
-
It appears to be latest Linux + packages from LE13 but with LE12 Kodi
There are endless delays in the release of Kodi Piers, and while it's perfectly usable (and stable) it's technically in a pre-Alpha state.
Meanwhile users keep showing up with x86_64 hardware that needs newer kernels/drivers than present in LE12.0, and upstream RPiOS has moved to a newer codebase, while other ARM SoC devices generally benefit from newer kernels to reduce patchsets or add functionality.
The original goal was a 'minimal' backporting of things from LE13, though it's grown a little since, but basically it's K21 with newer kernel and drivers. It will need testing, but as this is mostly stuff from LE12 which is stable and LE13 which is well tested we aren't expecting drama and won't be running a long test period.
LE12.2 probably has a short shelf-life as there are signs Kodi might finally start moving towards an Alpha release, but I'm not the type for holding breath as similar signs were present 8-months ago .. and we're still in the same state.
-
Kernel driver in use: i915
i915 supports the GPU for basic DRM output (so you see the splash screen) but mesa doesn't support the 82865G (gen2) hardware so it throws the "Driver does not support the 0x2572 PCI ID" error and Kodi cannot open an OpenGL context to render the GUI into. There's no workaround for the lack of mesa support.
-
Kodi Settings > System > Logging
-
So i've created the directory .nocompat
It's a file not a directory. The full path for 'touch' is /storage/.update/.nocompat
Another method is to untar the update file and move KERNEL, KERNEL.md5, SYSTEM, SYSTEM.md5 to /storage/.update and reboot.
-
I'm (still) failing to understand what you are trying to achieve. Synchronous playback on multiple devices?
-
Full clean build? .. or you pulled changes and just did a respin?
-
You cannot edit the original skin files as those exist inside the read-only SYSTEM file, but you can copy (clone) the skin directory to a writeable location like /storage/.kodi/addons/skin.myskin and then edit the addon.xml file for the skin to rename it so there's no name clash between the embedded skin and your cloned one. Stop and restart Kodi (or reboot) and then enable and select the skin to be the active one. Use kodi-remote from the SSH console or kodi-send commands to reload the skin as you make/test changes.
-
USB 2.0 ports provide different speeds and current draw limits to USB 3.0 ports. Power and bandwidth on a specific port (and the upstream hub) are also shared between other devices connected to the same hub). I'd guess you had the device in a 2.0 port and have now moved it to a 3.0 port .. or something like that.
-
Kodi is crashing. You'll need to enable debug logging and then share the resulting Kodi crash log for anyone to comment.
-
There are hundreds of HOWTO articles on installing grub2 out there. I don't have one to-hand so you will need to go find and read one. The main point to understand is bootloaders are installed to a root disk device like /dev/sda, not partitions like /dev/sda1, or folders inside the filesystem contained within a partition. The only files that need to be copied are KERNEL/SYSTEM. The bootloader will want a config file though, which should reside in the same partition. The grub2 config file will have some kind of 'APPEND' line for boot params and you can crib that content from the syslinux.cfg file.
-
Our distro packaging makes customising the skin complicated because Estuary is inside a squashfs file (SYSTEM) which is expanded into a virtual and read-only filesystem on each boot. You can clone the skin to /storage and then make changes to the clone, or you create a custom LE image that compiles the changes into the image.
LE is minimalist so we don't have git and change management tools in the filesystem. You could add them via a Docker container if you wanted to, with a clone of the Kodi repo to e.g. /storage/xbmc.repo acting as the source of the skin and symlinks between the root folder of the Estuary skin files and /storage/.kodi/addons/skin.MyEstuary making the skin appear locally. It has the advantage of being somewhat self-contained on the device. It requires quite a bit of setup/fiddling though (and there are no guides for it) and you need to reinvent the wheel when moving to another device. If the changes are not extensive; perhaps skip "doing it right" and just clone the skin files locally and apply changes; and rinse/repeat occasionally if needed.
The ultimate "doing it properly" is creating a custom image with the changes baked in. I have virtual machines and resources for that, and I'm using this workflow:
Fork https://github.com/xbmc/xbmc/ to your own GitHub account. Now clone your repo locally, git remote add an 'upstream' source for the Kodi repo, and git checkout -b a local topic branch to contain commits for your skin changes. You can now make changes and git commit them to the branch, and generate diff patches using git format-patch. Over time and if required, you can git fetch upstream Kodi changes from their repo and git rebase your local branch against them, and regenerate the patches.
Fork https://github.com/LibreELEC/LibreELEC.tv/ to your own GitHub account. now clone your repo locally, add an upstream remote for the LE repo, and checkout a local topic branch for your LE image changes. Add the diff patch(es) generated in the Kodi repo to packages/mediacentre/kodi-theme-Estuary/patches/ then commit them to the branch. You can now build a custom image that applies the diff patches to the skin. You can periodically fetch changes from our upstream repo and rebase your branch against them. and then rebuild the image.
No idea what works best for you .. it's about time/effort/resources/skills available
-
If the file glitches consistently in both LE and Kodi on Windows that might hint at a VAAPI hardware decoding issue. MPV is also a big fancy wrapper around libavcoded, but is probably using a different underlying version and/or is software decoding the file resulting in a different code path and capabilities. You can experiment in LE by disabling VAAPI hardware decoding. You can also experiment with an LE13 nightly which has newer kernel (drivers) and FFMpeg versions to see if newer is better (not always).
-
The extlinux.conf file is in a VFAT partition readable (and thus editable to change the dtb name) on any modern OS, even Windows.
-
Do you recommend another board that works better with LibreELEC than RPi5?
Nope. I have 40+ ARM SoC boards and RPi5 is the best (consistent and reliable) experience of them all. I don't ever use WiFi with any device though, and if forced to use WiFi i'd be using a USB device with a proper external antenna, or a WiFi bridge; not the onboard module which I've always found to be a bit rubbish for streaming use.
The error message is generated between kernel + iwd + ConnMan so isn't something we control and the key is something obscure and internal to 802.11 radio standards. If you're already using a WPA2/3 mixed mode network poor signal strength is probably the underlying cause.
-
There is no database or config file in Kodi that stores ROM/Emulator/Controller data but if you are using IAGL? it stores that kind of information under /storage/.kodi/userdata/addon_data/plugin.program.iagl/dat_files .. there's usually an XML file per target platform (being emulated).
Have you tried installing other emulators so there's a choice to use? (no idea if that might prompt something... just a guess).
-
LE13 has general rendering improvements over LE12 and older releases as @sarbes has spent time on optimisations.
Note: the patch I linked will do nothing for you on an x86_64 device as it's for the OpenGLES rendering path (used with ARM SoC devices) and Generic does not use GLES rendering. There's probably a similar point in the OpenGL code path where you can add something similar though.
