I have been using a number of music add-ons with Kodi 17 (last version) on the OSMC version that came with that Kodi version at that time.
I did not upgrade OSMC and Kodi for a longer time, but I upgraded it now to OSMC 2019.07-1 with Kodi 18.3.
They problem that I have now is that when I try to start a music add-on OSMC “crashes”, meaning it shows the blue screen frownie and restarts.
This happens when going through the Add-Ons section and clicking a music add-on in the overview, it also happens when trying to open the music add-ons section, also when opening a music add-on within the Add-on Setting section and clicking on “Open” for the add-on.
The only way currently to start a music add-on is using favourites created before the update, but that does not work for all music add-ons (e.g. MixCloud will crash).
(PVR client radio is still working)
Not sure whats wrong, but it is annoying.
To get a better understanding of the problem you are experiencing we need more information from you. The best way to get this information is for you to upload logs that demonstrate your problem. You can learn more about how to submit a useful support request here.
Depending on the used skin you have to set the settings-level to standard or higher, in summary:
enable debug logging at settings->system->logging
reboot the OSMC device
reproduce the issue
upload the log set either using the
Log Uploader method within the My OSMC menu in the GUI or the
ssh method invoking command
publish the provided URL from the log set upload, here
Thanks for your understanding. We hope that we can help you get up and running again shortly.
OSMC skin screenshot:
No offense intended, but as long as the grab-log -A would upload passwords and confidential information, I’d rather fix the problem myself.
I appreciate that you are not sending passwords.xml!
However, that is not the only place that may contain passwords and confidential information, e.g. in advancedsettings.xml may be mysql database passwords.
If I may make a proposal for making the tool more privacy-friendly:
grab-logs should !by default! read a list of blacklisted regexps and/or tags and filter out all lines that match these regexps.
Obviously, linux savvy users could do that on their own using e.g.
egrep -iv “(.*|word1|word2)” /boot/uploadlog.txt
and writting a wrapper script.
There’s a “Sanitizing your logs” part in the link @Tom_Doyle has provided.
Thanks, I figured out how to write the logs to /boot by reading grab-logs.
Well, they propose nano something you would not want to do over and over again.
My proposal was to integrate it in the process so that the user needs to think about the blacklist of words only once and when it changes.
However, I wrote my small wrapper by now.
Just my 2 cents.
# grep load files and clean out confidential artefacts and write out to:
echo Grabbing logs...
grab-logs -C -A
echo Cleaning logs...
egrep -iv "(\
)" /boot/uploadlog.txt >/home/osmc/.kodi/temp/uploadlog-clean.txt
echo You find logs in .kodi/temp/uploadlog-clean.txt
echo You may upload them using the script paste-log.
PS: Found and fixed the problem on my own by now.
For the team to fix the problem:
The problem actually was a mistyped password for the remote Music Database!
I would suppose that it should result in an empty database or an error message, but not in a crash!
On the old / un-updated platform it actually did not crash…
Sounds like something you should tell the add-on author about.
It even crashed when opening the overview of all Music add-ons.
I would suppose that code for reading the Music Database is something happening more centralized than in each add-on? Just guessing, but it would just make more sense.
I thought by ‘remote’ you meant on-line and accessed by one of your add-ons.
Without logs, we won’t have enough information to reproduce the issue.
Nope, just mysql on LAN. Not using any special app for that.
I would assume it is easy to reproduce, since I think you are testing with mysql anyway. Just remove 1 character from the password in advancedsettings.xml.
We are always grateful for bug reports, but if you wouldn’t mind giving a bit more info, like what device is hosting MySQL, and under what OS, is it really MySQL or MariaDB and what device is/are the client(s)?
What I would like to know is how the password would have changed upgrading from v17.x to 18.3. I have five Kodi clients on two different platforms running on MySQL and have not had that issue.
It is a Linux server running MariaDB.
darwindesign: Your assumption is not correct. The password did not change during the update. I did not say that.
It was like this:
The password was wrong all along, but the Linux server was not in use. I used the vero without the server for a long time, also for streaming music from the internet, without any problems.
I took the server back in use after many months and updated the vero box without using it for music. Actually I used a different Kodi box before the vero for music and never used the vero for accessing the Music Database. The password was set wrongly on the vero all along, but it did not provoke any crashes before the update.
After updating I wanted to use it for streaming music again, but now it crashed when using e.g. MixCloud, or when trying to open the overview of all music add-ons.