Yes, the simple way is to drop the database and start again using network shares!
Everything else, including path substitution, is nothing but a barely working workaround, as you're discovering.
I don't know how you've set up your path substitution but the problems with artwork are most likely because the artwork locations are once again inaccessible to the remote clients. You might be able to add more path substitution rules for the artwork, maybe. I personally wouldn't bother with path sub - you'll be dealing with this issue forever in one form or another, bite the bullet and fix it properly...
Both devices must access the content via the nfs:// network share, even the LibreELEC client that is attached to the local storage.
openssl does use this file by default, but it will be trying to access /etc/ssl/cacert.pem - we seem to have dropped the ca filename prefix (creating cert.pem not cacert.pem) in the transition back from libressl.
openssl example using current LE master (bogus private key, just for testing):Code
- rpi22:~ # openssl ca -keyfile /storage/.config/private/cakey.pem
- Using configuration from /etc/ssl/openssl.cnf
- Error opening CA certificate /etc/ssl/cacert.pem
- 1996051232:error:02001002:system library:fopen:No such file or directory:bss_file.c:406:fopen('/etc/ssl/cacert.pem','r')
- 1996051232:error:20074002:BIO routines:FILE_CTRL:system lib:bss_file.c:408:
- unable to load certificate
openssl.cnf is not relevant here.
Can you tell me what else is using /etc/ssl/cert.pem ? We had some "backward compatability" links to /etc/ssl/cert.pem which are now linked to /etc/ssl/cacert.pem, but what all references I can find seem to refer to cacert.pem not cert.pem. And curl is hard-coded to use whatever we like.
But you need to leave /etc/ssl/cert.pem because this is default name used. Use symbolic link instead.
I'm not so sure - the openssl config is referencing /etc/ssl/cacert.pem not /etc/ssl/cert.pem, so it looks like /etc/ssl/cert.pem is a misconfiguration on our part. It has probably never been an issue as curl is hardcoded to use the /etc/ssl/cert.pem path.
Also I would rename openssl-config to something more appropriate.
It's not the greatest name I grant you, but it's consistent with our other kodi-config, smbd-config etc. scripts that all do something similar.
vpeter what do you think of this change? Comparing LibreELEC:master...milhousevh:le90_user_ca · LibreELEC/LibreELEC.tv · GitHub
It should allow a user to safely add *additional* CAs in /storage/.config/cacert.pem without losing the benefit of existing system-supplied CA certs.
Replacing the shipped system CA cert file with a user CA file is going to result in long-term issues as CA certs expire or are compromised/replaced, and users with custom CA files start reporting weird and unreproducible certificate-related issues with public websites because their CA file is out of date.
I've also reverted the name of /etc/ssl/cert.pem to /etc/ssl/cacert.pem as per the contents of /etc/ssl/openssl.cnf.
It seems the Android addon is grinding it's way through your database using UPnP.
What makes you think it runs out of memory - you've said "Memory is getting more and more low up to 40140 kb", how are you determining this?
Unfortunately I can't see the journalctl log you posted to ix.io (the service is down at this time) but if Kodi is not restarting then it's probably not being killed by the out of memory process killer.
From the kodi.old.log it looks like 1,111 UPnP items are processed in approximately 3 minutes. Then the "bing" screensaver starts. I don't see any further processing of any kind after that.
It might be worth testing without any additional addons installed - start with a "clean" .kodi folder:
1. systemctl stop kodi
2. mv /storage/.kodi /storage/.kodi.bak
4. Add your music
5. Run the Android addon
Once you are done testing:
1. systemctl stop kodi
2. rm /storage/.kodi
3. mv /storage/.kodi.bak /storage/.kodi
With #0708, does Kodi actually crash due to out of memory (it may take a while, up to 30 minutes or so)? Once Kodi restarts, post kodi.old.log and also the contents of "journalctl -a".
It looks like the Teufel app is hammering on the Kodi webserver for information. Maybe this is causing a memory leak, or the Teufel is just flooding Kodi with requests.
You could try enabling debug logging, and then also enabling JSON-RPC and Webserver component logging, and then start your Teufel and maybe we'll see what requests the Teufel is making to Kodi. Assuming Kodi restarts, upload kodi.old.log and "journalctl -a".
Try looking at an existing addon.
If your add-on is a binary add-on - ie. it contains C/C++ code - then look (for example) at pvr.demo, and if not - ie. it's 100% Python and/or XML - then look at something like the LibreELEC-settings package.
You need to add the package (ie. package.mk) to the build, with the package.mk linking to your add-on source repo, then you need the package to be included in the build by adding the package name as a "PKG_DEPENDS_TARGET" in packages/virtual/mediacenter/package.mk
Patch for GLK HDMI bug was updated to V3: [v3] drm/i915/glk: Add Quirk for GLK NUC HDMI port issues
There's a v4 of this patch included in last night's #0703 build: LibreELEC Testbuilds for x86_64 (Kodi 18.0)
Just to say for LibreELEC there's a couple of extra steps when extracting the firmware:
1. Extract bootcode.bin, start_x.elf, fixup_x.dat from the popcornmix zip
2. Rename start_x.elf to start.elf
3. Rename fixup_x.dat to fixup.dat
4. Copy bootcode.bin, start.elf and fixup.dat to /flash
I would suggest getting PVR Simple working with LE 8.2.5, then once you have it working only *then* upgrade to an LE 9 test build.
I'm not saying there are known problems with LE9 and PVR Simple, but you're starting with an unstable build and it's entirely possible you've found an issue, but it's just as likely (from our point of view) that you're simply not setting it up correctly.
So start with known good software, ie. LE 8.2.5, then upgrade to LE9.0 once you have a working system.
I'm not aware of any reported issues with interlacing or black/flickering screens in 9.0 (there's a dedicated 9.0 testing thread on the Kodi forum) and without any bug reports there isn't likely to be a fix.
Sorry, been a bit busy.
I'll ask popcornmix if he can determine what changed in the firmware between #0226 (stable) and #0305 (unstable) that might explain the instability. It's very strange that this is only affecting a very small number of users (you, maybe Mario).
Did you try the latest LE9 test build as you were instructed? It includes a more recent version of xf86-video-ati (18.0.1 vs. 7.8.0) and newer versions of a whole bunch of components, any one of which might contribute to this bug in LE8.2.x. AMD hardware now supports VAAPI by default in LE9 builds.
Testing with the current development version is your best option because as already stated there are no plans for further LE 8.2.x releases.