Glad you got it sorted.
1. For RPi/RPi2 with 4.14.y kernel the extra DVB drivers are included. However for Generic (x86_64) with 4.17.y the additional DVB drivers are not currently included as they're not compatible, but will be when 4.18.y arrives in 2-3 weeks time. So, depending on your hardware the answer is "maybe".
2. For an older generation Intel, the Skylake systems are fine and generally problem free, eg. NUC6i5SYH - they can play 4K videos without a problem, and also HEVC, but will never be able to output HDR. If you want 4K and 10-bit HDR then there's nothing from Intel right now that is guaranteed to support HDR, not even once Kodi, the Linux kernel and the various GPU drivers and sub-systems include 10-bit HDR support.
Personally speaking, I can't recommend any current Intel systems given the uncertain support for HDR and other niggling issues that bedevil their hardware. The same applies to Nvidia, btw, but the uncertainty there is ongoing Kodi support which seems fairly unlikely post Kodi 18. My advice would be to look at an AMD Raven Ridge APU based solution.
Or save your money and live with your current system a bit longer until Intel sort themselves out (which could take a while) - try disabling deinterlacing and/or video scaling options in case they're maxing out the i3 CPU. Finally, consider replace your Intel i3 with an RPi3+ which can handle 1080p HEVC without too many issues, and then buy x86_64 once you're sure what to get (yes, I'm serious!)
Forgot to add - have you tried rebooting the RPi3?
will be apply correctly?
Yes - so long as your movies and tv shows have the same names before and after (which they should). The script doesn't actually care where they are (or were) located when restoring the watched status, it only matches on the movie or tvshow names.
then let me know if the order of steps is correct:
Yep, you got it.
[of course I need to know how to install the script on my existing libreELEC.
It's explained in the first post of the thread I linked.
If you want the super simple version, log in to LibreELEC and run:
Then to backup your watched status:
and to restore watched status (after you have rescraped the new library):
then what do I do on my other kodi instances besides pointing them to the new external database?
Point them to the MySQL database by copying advancedsettings.xml.
I'd also suggest copying sources.xml (in the same directory as advancedsettings.xml) from the LibreELEC client to your other clients just so that you have the same sources on all your clients. This step probably isn't essential, particularly if you don't plan on doing any scraping on those clients, but it may be useful.
Do I need to do something else to get the watched count etc on those boxes as well? Or will that start coming from the database?
Nope, that will all come from the central MySQL database.
Once you have scraped your library on the LibreELEC machine you may find that the other non-LibreELEC clients don't have any artwork cached. They will cache the artwork as it is displayed, but this can mean navigating the GUI on those clients will be quite slow. A solution is to use texturecache.py running on the LibreELEC client to automate the caching of artwork on your other clients, but that's probably a story for another time (or read the first post of the linked thread, the details are all there, pretty much).
Milhouse that is too advanced for me.
I'm really pretty sure it's not, particularly if you're willing to persist with path subs which are far more complicated IMHO!
To use nfs:// paths just create an nfs:// source, in your case you'd create a Movies source with nfs://192.168.1.121/volume1/video/ and a TV Shows source with nfs://192.168.1.121/volume1/TV, then scrape the contents of each source into your new library.
I'm sure you'll get it working with path subs eventually, but you'll always have a schizophrenic database that will try and break itself at every opportunity. Best of luck!
So you have these two path subs:Code
- 21:52:34.954 T:18446744072517099920 DEBUG: Configuring path substitutions
- 21:52:34.954 T:18446744072517099920 DEBUG: Registering substition pair:
- 21:52:34.955 T:18446744072517099920 DEBUG: From: [/storage/videos/]
- 21:52:34.955 T:18446744072517099920 DEBUG: To: [nfs://192.168.1.121/volume1/video/]
- 21:52:34.955 T:18446744072517099920 DEBUG: Registering substition pair:
- 21:52:34.955 T:18446744072517099920 DEBUG: From: [/storage/tvshows/]
- 21:52:34.955 T:18446744072517099920 DEBUG: To: [nfs://192.168.1.121/volume1/TV/]
but they're not working for your artwork as Kodi continues to retrieve the artwork files using the "local" path:
What you'll need to do is add yet another path sub for /storage/downloads.
I'm just trying to get it working as I don't want to loose my watched status
If you just want to save watched status (ie. watched state, resume point and play count) then might I suggest using texturecache.py: [RELEASE] Texture Cache Maintenance utility
You can install the script very easily into LibreELEC. In fact I include it as standard in my own LE9 test builds.
To backup your watched status, on the LibreELEC client:
Now create your new library in MySQL using only nfs:// paths, then restore the watched status to the MySQL database:
Are you using Yatse as well, because some of the JSON requests in your log look like the polling spam typical of Yatse. If you are using Yatse, please disable it while testing with your Tuefel, as they could be interacting with each depending on how badly the apps have been written. If you are not using Yatse then maybe the Tuefel app has the same design inefficiency as Yatse.
In your kodi.old.log I can see (once I filter out the spam) that an app - presumably the Tuefel, maybe Yatse - is requesting song details in batches of 975 songs. It manages to request 16750 songs, then stops at 09:18:04.581- there are no further JSON requests (other than spam) which suggests the Tuefel is still working. Kodi doesn't appear to have crashed at this point as it is still processing the spam requests.
Someone (Teufel? Yatse?) starts a music library scan at 09:20:21.511, which runs for several hours, finishing at 14:37:30.579.
Then, at 16:30:24.536, there is a UPnP request (presumably from the Tuefel?) which seems to be requesting all songs - 49621 in total, in batches of 100. Kodi seems to responsd OK with the first 400 items, but then hangs when being asked to process the 5th batch. My guess is there is a serious memory leak (or scale issue) in Kodi's UPnP implementation, which is a highly experimental feature in Kodi 18.
Please open a trac ticket on Kodi - TRAC and include the link to kodi.old.log - this will need the Kodi UPnP developer to investigate further.
Post your kodi debug log from the Firestick when using path substitution, I can't really comment further without knowing what the actual error is. Do the movies play successfully on the Firestick when using path substitution?
Note that if you perform a library scan on the Firestick which added new content to the database, chances are the nfs:// paths will be added to the database so you'll end up with a mixture of /storage and nfs:// paths in your database. The nfs:// paths will probably still be accessible by the LibreELEC device (even without path substitution) but from an OCD perspective this would drive me up the wall... you could probably have re-scraped a clean, 100% nfs:// database by now.
I'm not sure why you don't want to start afresh, but if you don't want to rescrape because you want to retain your watched statuses then there's a very simple solution for that which does not involve exporting the database. Also, exporting artwork is (IMHO) a really bad idea as the quality of the exported artwork is so much lower than the original artwork - again there is a solution for converting remote artwork to local artwork without losing quality. Unfortunately both solutions involve a command line, but if you're comfortable with that then you shouldn't have too many problems. I can post more details if this is of interest to you.
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.