OSMC June 2023 on RPi3 and RPi4 wireless and MySql issue

It’s been in a docker container for years. None of the permissions have changed. That’s why I suspect that there is something else going on here.

Have you actually updated a major Kodi release in that Docker container configuration before?

Every schema change results in creation of a new database.

From your log, it’s very clear that your SQL user is simply not privileged to create the new databases that are needed.

I just swapped the user for root as a test. Same result. And yes, I’ve had major Kodi releases in the Docker container with no issues. This is the docker image for context (Docker)

How do I rollback to the previous version until we iron out this issue? I don’t have time to troubleshoot this with my kids hollering at me that they can’t watch their shows.

If Kodi cannot create a database as the MySQL root user, I think you have a serious DB issue.

Reinstall to any previous 2023.06-1 version from Download - OSMC. As versions before this will be Kodi v19.x based.

The old database will be intact.

Cheers

Sam

But I don’t think you read my note. It’s creating the database just fine. I’m not sure why it won’t access it. I’m using Vero devices, how do I install this?

See Reinstalling OSMC - Vero 4K - OSMC

We will try and reproduce the MySQL issues here.

Your log is showing:

2023-06-06 16:02:01.697 T:2959 error : SQL: Can’t create database for copy: ‘MyVideos119’ (1007)

Does mysql show show the existence of this database then?

The error you have (1007) does indeed suggest the database already exists.

This thread seems to outline the issue you may be experiencing: Reddit - Dive into anything

Once we have ascertained a solution, we will advise users properly.

Cheers,

Sam

It does create a database but based on that reddit article, it may be an incomplete one. I’ll try the commands in the Docker console and report back in about an hour (after dinner).

It looks like having binary logging on can cause your problem.
I’m not sure what the deployment target of your Maria container is.

But I don’t know why binary logging would be on by default. It’s primarily used for replication, such as Galera. Albeit not being a necessity, a DROP table without bin-logging would require you to restore a backup.

Sam

My log has the same error (1007).

Sam,

Success! Following the guide from Reddit solved the issue. I also noticed when checking the MariaDB logs, it also suggested that I upgrade my databases as well. I did this prior to the log_bin adjustment.

For anyone searching through google, here are the steps that I took, verbatim.

  1. If you notice in your MariaDB Logs or in my case the Docker Container MariaDB logs, that you need to upgrade your databases, do it. Command: mariadb-upgrade -u root -p (enter your root password on the next prompt).

  2. Log into the MariaDB console. Command: mariadb -u root -p (enter your root password on next prompt)

  3. Type show global variables like ‘log_bin_trust_function_creators’; into the console. It will give you a result that will look like this:

±----------------------------------------------±---------+
| Variable_name | Value |
±----------------------------------------------±---------+
| log_bin_trust_function_creators | OFF |
±----------------------------------------------±---------+
1 row in set (0.001 sec)

  1. If yours is set to OFF, you need to turn it ON. If it’s already ON, I’m not sure what your issue is, unfortunately.

  2. Assuming you had it OFF, the command to turn it ON is:
    set global log_bin_trust_function_creators = 1;

  3. Confirm that the variable was set with this command:
    show global variables like ‘log_bin_trust_function_creators’;

It will show you something like this:

±---------------------------------------------±--------+
| Variable_name | Value |
±----------------------------------------------±------+
| log_bin_trust_function_creators | ON |
±----------------------------------------------±------+
1 row in set (0.001 sec)

  1. Drop your MyVideos121 database, it’s only partially created and your previous copy MyVideos119 will be used when you initiate the migration again.

  2. Reboot your Kodi/OSMC device, the database migration should occur during the start-up process and show with the Kodi logo present

  3. Now you have a functioning Database

image

3 Likes

Thanks for confirming.

I don’t know if binary logging was enabled by default on your Docker instance or you chose to enable it yourself.

It’ll only be useful if using replication or something like XtraBackup, which as a form of online backup is in effect a form of replication.

It was on by default. Not sure if that’s a common thing with MariaDB or this docker container.

I use MariaDB in Docker for my Kodi setup using the official MariaDB container. Binary logging is not on by default for that one at least. Obviously if you’re using a different Docker image that might not be true.

1 Like

This did the trick for me too!