Database Issue on Matrix leading to crash

Hi, I seem to be having an issue related to a shared database I use. In the past month or so, I’ve had a couple of my N2’s, which use a shared database, crash. What seems to happen is that I watch something (a recorded TV or a movie in an mkv) and when done, kodi locks up for a bit then restarts to safe mode. A couple crash logs from when this happens are below (I seem to get 10 when this happens). If I try to reboot from safe mode I simply go back into safe mode, unless I restart my shared database (mariadb docker on unraid) then kodi starts normally.

http://ix.io/3A4C
http://ix.io/3A4E

I have already recreated my database, but the problem has reappeared. I have successfully had this running for years through several versions of kodi. I’ve been running CoreELEC 19.2-Matrix_rc3 since a couple days after its release. I upgraded from rc2.

Any thoughts on what this might be from?

Only solution is to use Kodi on Windows or Linux and connect it to your database.
Then try to replicate the error and open a issue at TK:

It looks like a Kodi issue.

I’ll double check the next time it happens, but I believe I was able to successfully launch Kodi on Windows when I couldn’t access it on my N2. I haven’t had the crash itself on Windows (maybe because I don’t usually watch TV on my PC).

It turns out it’s an issue with mariadb. Linuxserverio rebased their mariadb docker to alpine and it caused some people to have issues. There’s a fix that worked for some, but not me. So I’ve reverted to an older version.

@doug - do you have a link to info about that, as I’ve had this issue (could access from Windows, but not CE). A restore worked, but if I ever use a Windows machine, it kills the DB again and I have to restore again. So, kinda annoying.

https://forums.unraid.net/topic/40737-support-linuxserverio-mariadb/?do=findComment&comment=1028103
Start reading from that post. There is one post specifically referring to problems with Kodi and he also downgraded to solve the issue. That post also refers to a post here on CoreELEC discussing a database issue when accessed from both Windows and Linux.

Thankyou! I found something else recommending to log in to the container and run a manual mysql-upgrade. Which I have done…will see if that fixes it once I have some time to test tomorrow!

Right, so this is really quite a mess. The post you linked to is precisely the issue I am having - thanks.
(The state of MariaDB in the context of CoreELEC)

Bit frustrating, as it happens, as when I moved all my service thingies to dockers, I went with linuxserver/mariadb (rather than say MySQL 8) - specifically because I don’t need a wizz bang up to date DB (for Kodi use only) - just something stable. So figured since this was the primary db from Linuxserver, it was likely to be the more stable option. Did not realise that MariaDB is, generally, in a bit of a bad state right now. (As I read it, it’s not really the update to Alpine as the underlying OS that’s the problem, it’s the update to the MariaDB version that came with it…).

I am in exactly the same state as this person:
https://forums.unraid.net/topic/40737-support-linuxserverio-mariadb/?do=findComment&comment=1030438

Thus I followed zoggy’s post and rolled back to the older version (deleting the mentioned files etc):
ghcr.io/linuxserver/mariadb:110.4.21mariabionic-ls31

…this seems the easier path, because I have a bunch of installs and I don’t want to needlessly go around adding no compression to them all in advancedsettings.

(But really wishing I’d just gone with MySQL 8 to start with!)

Edit - the above fixed worked and I can access the DB from both CE and Windows again, without issues.

Interestingly I’ve seen the same issues recently with exactly the same setup which is mariadb on an unraid docker. I have multiple clients and all was working fine and then suddenly 1 day I launched 1 of the clients for the 1st time in months and it seemed to then cause me umpteen issues with other agents not launching etc.

I ended up having to recreate the DBs and so far things have been ok. I suspected that the issue may have been with the docker as it seems to be ok now and I think unraid has updated it a few times since. I also noticed on unraid’s forum a few people complaining of other issues with the mariadb docker in the past few weeks.

I have also downgraded to linuxserver/mariadb:110.4.21mariabionic-ls31.

There is a new post in the thread to do a “clean” update. I previously tried a completely new database using “latest” (a 10.5 alpine build) but still had crashes so will just stick with the downgrade for now as it just works.

Well ultimately that’s one of the benefits of containers, I guess. You can lock versions to something stable & working, when you need to at least, as it’s just a packaged service. And if the service is doing everything you need and is safely isolated, then updates aren’t really important. Still, I always prefer to keep things current, so will personally re-visit later after Mariadb 10.6 is out, as per that post. Make a decision then, MySQL 8 or MariaDB, I guess…

I use (and prefer) MariaDB with RocksDB engine.
One instance services Win, Lin and Android clients, although databases for these are separate - platform segregation. :wink:

I’m not following the point of that? You can like MariaDB all you like, but there’s a clear issue with it right now that makes it problematic to use with Kodi. And splitting things such that you have a different DB per platform defeats the entire purpose of a centralised single store, doesn’t it? (I too have installations on all those platforms, but the point of using MySQL (or derivative) is to make sure they’re all looking at the same data…)

Each platform is looking at the same data.
But why different database for each platform?
Because on Win, Lin and Android paths to content differ.
Content is the same.
And I have not experienced the “clear issue with” MariaDB right now.

I’m still not following - I don’t believe Kodi let’s you have more than one path per content item?

So…by ‘the content is the same’ - do you just mean you’re pointing each of these separate DBs at the same content? …so Kodi is indeed filling/maintaining multiple DBs, right? And if so, what advantage is there to using MySQL vs the standard Kodi DB in that case?

Or have you managed to work out a way so that all the meta-info is in one single place, but somehow the paths aren’t?

(I personally use NFS, which lets one normalise paths across those platforms, so that one DB is truly one DB).

As for “clear issue” - putting it in quotes doesn’t make it not exist :wink: Nice for you that you haven’t run into it, but it doesn’t take much browsing here (once you know about it!) - or at the Kodi or UnRaid forums - to see that plenty are. This post documents it really well - The state of MariaDB in the context of CoreELEC

I’m probably just not understanding you, and apologies if I am not - but the classic point of MySQL with Kodi is to have one single centralised store, for everything. Which means Kodi does less scraping (vs. multiple clients), all clients have an identical, consistent view on the data (any changes made appear everywhere etc), and watched points are all synced etc etc. As soon as you move to any multiple database approach, it seems to me you’re just adding complexity for no functional gain over the in-built sqllite stuff?

For the last time:

  • All Windows KODis use single database (login) with mapped SMB drive to the content
  • All Linux (incl CoreELEC) KODis use single database (login) with mounted to local NFS folder
  • All Android KODis use single database (login) with userspace KODi mapped NFS content

The source content is one and only, a NAS server.

Why I did it like this?
Because different client KODi platforms behave differently with SMB, NFS, WebDAV mapped content paths.
So, empirically I’ve discovered the best performace biased settings for MY case.
If I use only one database for all platforms, because the paths differ,
each time KODi scraps the content, it totally rebuilds/overwrites the whole database. Unefficient!

Hope that clears it.

Ok, sure, if that works for you. But if you normalised your paths (which, given you’re sharing from a NAS, would be trivial) - you’d have one centralised store. NFS works perfectly (and efficiently) with all of those clients, for example, or you could use SMB if you prefer. But no worries, if you want multiple DBs, you go for it. I’m not arguing with you, just trying to help & understand.

I agree. 1 database and NFS.

About | FAQ | Terms of Service | Privacy Policy | Legal Notice