[Resolved] Music database generating an error

I have a number of RPI’s in place and have started to migrate them over to OSMC from RaspBMC. As I have a few RPI’s I setup the advanced option of using MySQL databases for Music and Video.

Here’s the contents of my advancesettings.xml as you can see I haven’t done anything complicated.



Reviewing the kodi.log file I receive this error; ERROR: Unable to open database: MyMusic48 [2003](Can’t connect to MySQL server on ‘x.x.x.x’ (113))

The username and password are correct and have be granted the correct access to both databases. Both devices are on the same network and there is no firewall in between them.

The Movies and TV Shows are fine, it’s just the Music database.



After a little bit of head scratching and a bit of luck I’ve found what is causing my issue. Even though I have the setting Wait for Network enabled the timeout doesn’t appear to be long enough. I have Cisco switches and they take up 60 seconds to initialize. Is there a way to extend the time OSMC waits for the network?

You turn your switches off ?

Yes you could extend the timeout, by editing the service file for the wait-for-network service and saving it to a different directory.

sudo cp /lib/systemd/system/connman-wait-for-network.service /etc/systemd/system
sudo nano /etc/systemd/system/connman-wait-for-network.service

Increase the value of count=60, (for example to 120) save and reboot.

Any systemd services in /etc/systemd/system take precedence over the system supplied ones in /lib/systemd/system, so even if an update updates the original file your custom version will still be in effect.

We’re looking into whether a user defined delay should be a GUI option but haven’t decided whether it should be an adjustable timeout for the wait for network service, or a separate delay independent of network - it depends on the use case as to what is useful. (For example waiting longer for the network to come up doesn’t help if you’re waiting for a remote server to boot not the network itself)

Thanks for the quick reply.

I’ll have a go at making the change to see what works best for me.

To answer your question though, no I don’t turn off my switches. I’m running fully managed Cisco switches, they shutdown the port if there is no physical connection; ie the device at the other end of the cable is switched off, rebooted or the cable is removed. Once a physical connection is detected the port then initializes, this take time.

An alternative method would be to maybe ping the default gateway and wait for a response. At that stage you know the network is up and therefore any external access requirements will have a fighting chance.

Pinging the default gateway is not a general purpose method of testing a network is up - not all networks even have a default gateway, or if they do it may not respond to pings.

connman-wait-for-network.service already handles checking for the network being up by checking connman’s state - and connman has its own methods of checking whether the network is up which vary depending on whether it’s ethernet or wifi, and whether you’re using DHCP of Static addressing.

(For example on DHCP Ethernet it will wait for a valid response from the DHCP server before considering the network to be up - ethernet link level activity alone is not enough)

So we already check everything feasible to see if the network connection is up. That is not enough though if you are for example turning on a MySQL/NFS server at the same time as the Pi - the network may come up quickly but the server could take much longer to boot up and be ready to serve requests, hence for some people they might want a customisable arbitrary delay to allow their server time to boot up.

I made this change last night, setting the count to 300. This hasn’t helped, I still see error’s in the log. Is there a way of increasing the logging detail?

After digging around further I found the solution to my problem. I needed to enable PortFast on the switch ports that have a RPi connected. So with the delay suggested by DBMandrake and the improved response times from the switch all now well.

Strange that you needed to do any thing at all with your switch configuration - I’ve used my Pi’s on a variety of switches, both consumer and enterprise and never seen any issues like what you described.