Shared Library and MySQL does not work on LibreELEC (Krypton) v7.90.008


  • outcave can you post the output from "journalctl -a | pastebinit" and the corresponding kodi.log - this would allow us to see when the network is coming up, and what kodi is doing at that time. But it does appear to be a "network wait" type issue, strange it's not working...

    Hi Milhouse

    "journalctl -a | pastebinit" -> aBXM

    cat $HOME/.kodi/temp/kodi.log | pastebinit -> DFRX

  • Ok, I want to put another update.

    I did setup the "WAIT FOR NETWORK" in the advanced network settings, restarted, and now it works!

    So, please try that as well.

    Regards!

    Edited once, last by kino13 (November 18, 2016 at 4:54 PM).

  • Also with 'systemctl restart kodi' same behavior.
    [hr]


    Ok, I want to put another update.

    I did setup the "WAIT FOR NETWORK" in the advanced network settings, restarted, and now it works!

    So, please try that as well.

    Regards!

    WAIT FOR NETWORK is already enabled in LibreELEC settings (up to 10 seconds)
    [hr]
    but... when I execute 'systemctl restart kodi' on the screen I see the Kodi logo for lots of seconds (about 10 seconds...) so.. does WAIT FOR NETWORK really works?
    Is not possible that Kodi will wait these 10 seconds (also if networks is already UP) and later goes in timeout and Kodi think that the network is still not yet started?

    Edited once, last by outcave (November 18, 2016 at 5:05 PM).

  • You never thought to mention you were using a VPN?

    Could your VPN be part of the problem?

    I thought this error had been fixed in busybox:

    Code
    Nov 18 17:46:23 LibreELEC openvpn[278]: ERROR: Linux route add command failed: external program exited with error status: 2

    Is your VPN working?

  • Hi again.
    I never mentioned that I use a VPN because the VPN is NOT part of the problem, I have also tried to disable VPN (and disabled the VPN auto connect) and the behavior is the same, anyway see the new logs with VPN disabled:

    journalctl -a | pastebinit -> DNCB
    cat $HOME/.kodi/temp/kodi.log | pastebinit -> gBgJ

    Yes, VPN is working but thanks to a my workaround (shell script that fix the default route after the error "ERROR: Linux route add command failed: external program exited with error status: 2").

    The "linux route add 0.0.0.0/0 via GATEWAY_IP" problem is still here (also on LibreELEC v7.90.008) as you was able to see in my LibreELEC log.
    See here a my old post about that problem: OpenELEC Mediacenter - OpenELEC Forum - VPN Manager for OpenVPN (38/63)
    My FIX: OpenELEC Mediacenter - OpenELEC Forum - VPN Manager for OpenVPN (38/63)

    About VPN, I think the "route add 0.0.0.0/0 via GATEWAY_IP" problem that you say is solved is still there (also on LibreELEC v7.90.008) on connmand or busybox.
    Also because I cannot understand why connmand go to ADD the default route (route 0.0.0.0 gw 192.168.147.1) just after have deleted it...., see the bold lines:

    Nov 18 17:46:23 LibreELEC openvpn[278]: /sbin/ip addr add dev tun0 10.3.200.14/24 broadcast 10.3.200.255
    Nov 18 17:46:23 LibreELEC connmand[318]: tun0 {add} address 10.3.200.14/24 label tun0 family 2
    Nov 18 17:46:23 LibreELEC connmand[318]: tun0 {add} route 10.3.200.0 gw 0.0.0.0 scope 253 <LINK>
    Nov 18 17:46:23 LibreELEC connmand[318]: eth0 {add} route 159.122.133.197 gw 192.168.147.1 scope 0 <UNIVERSE>
    Nov 18 17:46:23 LibreELEC connmand[318]: eth0 {del} route 0.0.0.0 gw 192.168.147.1 scope 0 <UNIVERSE>
    Nov 18 17:46:23 LibreELEC connmand[318]: eth0 {add} route 0.0.0.0 gw 192.168.147.1 scope 0 <UNIVERSE>

    Nov 18 17:46:23 LibreELEC openvpn[278]: ERROR: Linux route add command failed: external program exited with error status: 2
    Nov 18 17:46:23 LibreELEC connmand[318]: eth0 {del} route 8.8.8.8 gw 192.168.147.1 scope 0 <UNIVERSE>
    Nov 18 17:46:23 LibreELEC connmand[318]: eth0 {del} route 8.8.4.4 gw 192.168.147.1 scope 0 <UNIVERSE>
    Nov 18 17:46:23 LibreELEC connmand[318]: eth0 {del} route 192.168.147.1 gw 0.0.0.0 scope 253 <LINK>
    Nov 18 17:46:23 LibreELEC connmand[318]: tun0 {add} route 0.0.0.0 gw 10.3.200.254 scope 0 <UNIVERSE>

    The last line (route 0.0.0.0 gw 10.3.200.254) that is the new default gateway should be executed just after the first delete (route 0.0.0.0 gw 192.168.147.1).

    Anyway this route add/del problem is another problem that if you want we can talk on another thread.

    About the main problem (MySQL) I think the problem is that some Kodi stuff still starting before the network goes UP.
    Focus your attention to the time in the log files.
    The time starts at "18:52:40" but this is not the correct time (I started LibreELEC at about 21:54), this should be the time inside the LibreELEC release (Odroid C2 does not have a RTC).
    Well.. going on: LibreELEC starts to log MySQL error at "18:52:42".
    Kodi.sh starts at 18:52:44 (Oct 20 18:52:44 LibreELEC kodi.sh[420]: hwclock: ioctl 0x4024700a failed: Input/output error)

    Why kodi.sh start after the MySQL connections?

    Going on, connmand will go to DELETE the network interface:

    Oct 20 18:52:42 LibreELEC connmand[314]: eth0 {del} route 0.0.0.0 gw 192.168.147.1 scope 0 <UNIVERSE>
    Oct 20 18:52:42 LibreELEC connmand[314]: eth0 {del} route 8.8.8.8 gw 192.168.147.1 scope 0 <UNIVERSE>
    Oct 20 18:52:42 LibreELEC connmand[314]: eth0 {del} route 8.8.4.4 gw 192.168.147.1 scope 0 <UNIVERSE>
    Oct 20 18:52:42 LibreELEC connmand[314]: eth0 {del} route 192.168.147.1 gw 0.0.0.0 scope 253 <LINK>
    Oct 20 18:52:42 LibreELEC connmand[314]: eth0 {del} address 192.168.147.27/24 label eth0
    Oct 20 18:52:42 LibreELEC connmand[314]: eth0 {del} route 192.168.147.0 gw 0.0.0.0 scope 253 <LINK>


    And going on: the "Link is Up - 1000/Full" is 2 seconds later (at 18:52:44) these "eth0 del".

    Still going on, we have finally the eth0 add:


    Oct 20 18:52:44 LibreELEC kernel: IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
    Oct 20 18:52:44 LibreELEC connmand[314]: ipconfig state 3 ipconfig method 1
    Oct 20 18:52:44 LibreELEC connmand[314]: eth0 {add} address 192.168.147.27/24 label eth0 family 2
    Oct 20 18:52:44 LibreELEC connmand[314]: eth0 {add} route 192.168.147.0 gw 0.0.0.0 scope 253 <LINK>
    Oct 20 18:52:44 LibreELEC connmand[314]: eth0 {add} route 192.168.147.1 gw 0.0.0.0 scope 253 <LINK>
    Oct 20 18:52:44 LibreELEC connmand[314]: eth0 {add} route 8.8.8.8 gw 192.168.147.1 scope 0 <UNIVERSE>
    Oct 20 18:52:44 LibreELEC connmand[314]: eth0 {add} route 8.8.4.4 gw 192.168.147.1 scope 0 <UNIVERSE>
    Oct 20 18:52:44 LibreELEC connmand[314]: eth0 {add} route 0.0.0.0 gw 192.168.147.1 scope 0 <UNIVERSE>

    and just later the NTP update:


    Oct 20 18:52:44 LibreELEC connmand[314]: ntp: time slew +2520110.999889 s
    Nov 18 21:54:35 LibreELEC systemd[1]: Time has been changed

    How is it possible that LibreELEC strats the MySQL connection before the network interface goes UP?
    Why connmand will go to "eth0 del" before "eth0 add"?
    If this "eth0 del" before the "eth0 add" is correct, I expect that all Kodi stuff will starts just after these "eth0 add".....

    Edited once, last by outcave (November 18, 2016 at 10:04 PM).

  • I guess the "Wait for network" isn't quite working in your case, for some reason.

    You could try adding the following in autostart.sh, it's what I use:

    Code
    # Wait for the network to come up...
    while [ -z "$(connmanctl state 2>/dev/null | grep State | grep -E "ready|online")" ]; do sleep 0.25; done; logger -t "$(basename $0)" "** Network is up **"

    As for the "route add" issue, by all means start another thread but a bump to busybox 1.25.1 might fix it. Unfortunately busybox.net is down right now so I've no clue what fixes and other changes are in 1.25.1.

    Also, please stop trying to contact me direct - I prefer to give public support on the forum. :)

  • it's same with the autostart.sh.....
    do you need others log?
    [hr]
    OK, some news:
    The problems happens only on Odroid C2.
    With Raspberry Pi 2 no problem found (Database created).

    Here the "journalctl -a | pastebinit" of Raspberry Pi 2: KjFU
    You can compare with "journalctl -a | pastebinit" of Odroid C2: DNCB

    All the "eth0 del" found on the log of Odroid C2 (wlan0 on the Raspberry Pi 2) on the Raspberry Pi2 there are not..
    It seem that the boot procedure/sequence is different from Odroid and Raspberry Pi.

    On Raspberry Pi 2 the "systemd[1]: Started Kodi Media Center." happens after "connmand" bring up the network (rightly there is only one connmand).

    On Odroid C2 the "systemd[1]: Started Kodi Media Center." happens after "connmand" bring up the network BUT next connmand will go bring down the network and next again bring up again the network (3 times connmand) .....
    See from the log:

    1. ADD Network (at 18:52:40):
    Oct 20 18:52:40 LibreELEC connmand[314]: eth0 {add} route 192.168.147.0 gw 0.0.0.0 scope 253 <LINK>
    Oct 20 18:52:40 LibreELEC connmand[314]: eth0 {add} route 192.168.147.1 gw 0.0.0.0 scope 253 <LINK>
    Oct 20 18:52:40 LibreELEC connmand[314]: eth0 {add} route 8.8.8.8 gw 192.168.147.1 scope 0 <UNIVERSE>
    Oct 20 18:52:40 LibreELEC connmand[314]: eth0 {add} route 8.8.4.4 gw 192.168.147.1 scope 0 <UNIVERSE>
    Oct 20 18:52:40 LibreELEC connmand[314]: eth0 {add} route 0.0.0.0 gw 192.168.147.1 scope 0 <UNIVERSE>
    Oct 20 18:52:40 LibreELEC connmand[314]: eth0 {del} route fe80:: gw :: scope 0 <UNIVERSE>
    Oct 20 18:52:40 LibreELEC connmand[314]: eth0 {del} route ff00:: gw :: scope 0 <UNIVERSE>
    Oct 20 18:52:40 LibreELEC connmand[314]: eth0 {add} route 0.0.0.0 gw 192.168.147.1 scope 0 <UNIVERSE>
    Oct 20 18:52:40 LibreELEC connmand[314]: eth0 {add} route 8.8.4.4 gw 192.168.147.1 scope 0 <UNIVERSE>
    Oct 20 18:52:40 LibreELEC connmand[314]: eth0 {add} route 8.8.8.8 gw 192.168.147.1 scope 0 <UNIVERSE>
    Oct 20 18:52:40 LibreELEC connmand[314]: eth0 {add} route 192.168.147.0 gw 0.0.0.0 scope 253 <LINK>

    -----

    2. REMOVE Network (at 18:52:42):
    Oct 20 18:52:42 LibreELEC connmand[314]: eth0 {RX} 0 packets 0 bytes
    Oct 20 18:52:42 LibreELEC connmand[314]: eth0 {TX} 10 packets 1088 bytes
    Oct 20 18:52:42 LibreELEC connmand[314]: eth0 {update} flags 36867 <UP>
    Oct 20 18:52:42 LibreELEC connmand[314]: eth0 {newlink} index 2 address 00:1E:06:33:C4:34 mtu 1500
    Oct 20 18:52:42 LibreELEC connmand[314]: eth0 {newlink} index 2 operstate 2 <DOWN>
    Oct 20 18:52:42 LibreELEC connmand[314]: eth0 {del} route 0.0.0.0 gw 192.168.147.1 scope 0 <UNIVERSE>
    Oct 20 18:52:42 LibreELEC connmand[314]: eth0 {del} route 8.8.8.8 gw 192.168.147.1 scope 0 <UNIVERSE>
    Oct 20 18:52:42 LibreELEC connmand[314]: eth0 {del} route 8.8.4.4 gw 192.168.147.1 scope 0 <UNIVERSE>
    Oct 20 18:52:42 LibreELEC connmand[314]: eth0 {del} route 192.168.147.1 gw 0.0.0.0 scope 253 <LINK>
    Oct 20 18:52:42 LibreELEC connmand[314]: eth0 {del} address 192.168.147.27/24 label eth0
    Oct 20 18:52:42 LibreELEC connmand[314]: eth0 {del} route 192.168.147.0 gw 0.0.0.0 scope 253 <LINK>

    -----

    3. ADD Network again (at 18:52:44):
    Oct 20 18:52:44 LibreELEC connmand[314]: eth0 {RX} 0 packets 0 bytes
    Oct 20 18:52:44 LibreELEC connmand[314]: eth0 {TX} 10 packets 1088 bytes
    Oct 20 18:52:44 LibreELEC connmand[314]: eth0 {update} flags 102467 <UP,RUNNING,LOWER_UP>
    Oct 20 18:52:44 LibreELEC connmand[314]: eth0 {newlink} index 2 address 00:1E:06:33:C4:34 mtu 1500
    Oct 20 18:52:44 LibreELEC connmand[314]: eth0 {newlink} index 2 operstate 6 <UP>
    Oct 20 18:52:44 LibreELEC connmand[314]: Skipping disconnect of carrier, network is connecting.
    Oct 20 18:52:44 LibreELEC kernel: libphy: stmmac-0:00 - Link is Up - 1000/Full
    Oct 20 18:52:44 LibreELEC kernel: IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
    Oct 20 18:52:44 LibreELEC connmand[314]: ipconfig state 3 ipconfig method 1
    Oct 20 18:52:44 LibreELEC connmand[314]: eth0 {add} address 192.168.147.27/24 label eth0 family 2
    Oct 20 18:52:44 LibreELEC connmand[314]: eth0 {add} route 192.168.147.0 gw 0.0.0.0 scope 253 <LINK>
    Oct 20 18:52:44 LibreELEC connmand[314]: eth0 {add} route 192.168.147.1 gw 0.0.0.0 scope 253 <LINK>
    Oct 20 18:52:44 LibreELEC connmand[314]: eth0 {add} route 8.8.8.8 gw 192.168.147.1 scope 0 <UNIVERSE>
    Oct 20 18:52:44 LibreELEC connmand[314]: eth0 {add} route 8.8.4.4 gw 192.168.147.1 scope 0 <UNIVERSE>
    Oct 20 18:52:44 LibreELEC connmand[314]: eth0 {add} route 0.0.0.0 gw 192.168.147.1 scope 0 <UNIVERSE>


    "Wait for network connection before starting Kodi" does not work on Odroid C2 :(

    Edited once, last by outcave (December 5, 2016 at 2:18 PM).


  • Hi.
    Has been identified the "Wait for network" problem on Odroid C2?
    Can I help in any other in order to solve?

    Thanks.


    It's working just like it should, however, your network is being brought down again when kodi starts. I'm not sure why that is happening. I'll have to check on my odroid c2 to see if I experience the same thing.

  • Thanks lrusak, let me know. Again, if you need others tests I'm available to do them.

    Yes, the strange is that connmand bring up the network interface, then after will go to bring down and then after will go to bring up again...

  • hi i'm having the exact same issue the Pi cannot connect to a sharedDB. If I remove the advancedsettings.xml and add the path manually it works..... if I add the advancedsettings.xml file back and try to browse the share it hangs the Pi

    has anyone anymore on this?

    the wait for network has been tested with no avail....


  • hi i'm having the exact same issue the Pi cannot connect to a sharedDB. If I remove the advancedsettings.xml and add the path manually it works..... if I add the advancedsettings.xml file back and try to browse the share it hangs the Pi

    has anyone anymore on this?

    the wait for network has been tested with no avail....

    No, that problem doesn't occur for me.
    My configuration: SQL DB running on D-Link NAS, Odroid C2 configured by advancedsettings.xml to connect to that SQL DB provided by IP address (not by name), media content on NAS shared using NFS (no Samba), LE configured to wait for Kodi fo 10 seconds at startup.
    Part of my advancedsettings.xml:

    <videodatabase>
    <name>MyVideos</name>
    <host>192.168.1.111</host>
    <user>kodi</user>
    <pass>kodi</pass>
    <type>mysql</type>
    <port>3306</port>
    </videodatabase>
    <musicdatabase>
    <name>MyMusic</name>
    <host>192.168.1.111</host>
    <user>kodi</user>
    <pass>kodi</pass>
    <type>mysql</type>
    <port>3306</port>
    </musicdatabase>

  • thanks for the reply how weird..... my settings are very similar, using IP not hostname, advancedsetings nearly the same, wait 10 seconds on startup etc etc

    i did notice though that I only rebooted the PI via SSH and not a full powercycle as mentioned in the thread, i'll give that a go....
    [hr]
    no still the same, it can traverse the file structure but not download play any content..... even tried changing the timeout to 30 but nothing :(

    also disabled the FW on the sharedDB box

    Edited once, last by reddevilmeuk (January 29, 2017 at 10:16 AM).

  • I had this issue on two Beelink Mini MXIII's after upgrading from kszaq's 7.0.3.012e Jarvis to 7.90.beta3 Krypton. Both had 10 second wait for network set in LibreELEC settings. Both are connected using Ethernet.

    I tried all different ways of getting it to work and every once in a while one device would connect to the MySQL server but then drop out again. The MySQL server is MariaDB running on a Synology NAS. I thought it may have been a permissions issue and/or NFS issue but changes to either of these on the Synology did nothing to fix it. I also tried 7.90.beta3 installed both on SD card and NAND but this didn't fix it either. I changed wait for network to 25 seconds, didn't fix it.

    In the end I reverted back to 7.0.3.012g Jarvis and restored my backups and the MySQL shared library works fine again on both devices. My logs are identical to the ones pasted on the original post:

    ERROR: Unable to open database: MyVideos107 [2003](Can't connect to MySQL server on '192.168.1.50' (101))
    etc. etc.

    Edited once, last by l45er (January 30, 2017 at 11:45 PM).

  • okay after a lot of testing / rebuilding i fixed it.....

    so if you have the issue as mentioned above, this is how i fixed it.

    1. ensure the PI is in the same workgroup your server is, if not then edit the samba.config file in storage/config dir
    2. reboot the PI
    3. open file manager on the PI add a new source, select SMB and test your workgroup to make sure you can see the server listed
    4. if all your shares are hidden create and share a directory on your windows box
    5. retest step 3 but then but after selecting the server in your workgroup then select the newly created directory
    6. enter a username and password (saving it) and you should be able to now see inside the directory
    7. now open up passwords.xml in storage/.kodi/userdata and you should have

    <passwords>
    <path>
    <from pathversion="1">smb://HTPC/</from>
    <to pathversion="1">smb://USERNAME: PASSWORD@HTPC/</to>
    </path>
    </passwords>

    8. last step i did was to add the IP also like the following

    <passwords>
    <path>
    <from pathversion="1">smb://HTPC/</from>
    <to pathversion="1">smb://USERNAME: PASSWORD@HTPC/</to> ( no space between : and P, put them together and you get :P )
    </path>
    <path>
    <from pathversion="1">smb://192.168.1.50/</from>
    <to pathversion="1">smb://USERNAME: PASSWORD@HTPC/</to>
    </path>
    </passwords>

    9. reboot and voila all the pics are now there and all files play as they should

    ;)

    Edited once, last by reddevilmeuk (February 4, 2017 at 12:26 AM).

  • Primary mistake is to use samba protocol in Linux world. NFS should be used instead of SMB. So if you have RPI, Odroid, Wetek, etc. running Libreelec which is Linux and have your content repository on NAS (Synology, QNAP, Netgear, etc) which is also running on Linux system then its obvious that you should share your files using NFS as this is native file sharing protocol for Linux. SMB in this configuration is simple big mistake. Of course it will work but: slower and utilizing CPU heavily and... as we can read above configuration to get it work require a lot of effort and time.