I’ve recently tidied up the ID3 tags on my music collection, and have tried to get the headless OSMC install on my RPi A to reflect this. Sadly, it doesn’t seem to be reading the files successfully when I used xbmc-send to request an update. I see that a previous suggestion has been to check permissions on the files: I’m pretty confident this shouldn’t be an issue because the RPi was able to play these files before I cleared the library and attemtped to refresh.
I’ve done an update and what I believe are the necessary debug flags in the advanced settings XML:
before attempting a library update and uploading logs. Whilst I’m not really au fait with the logs, I believe that the /media/MUSIC_CV/Music folder in which my music collection lives has been succesfully mounted, but I’m not confident I can find acknowledgement that the kodi-send action has been sent. I’ve been stricter in making sure I issue the request soon after a restart in generating a second log but still don’t see anything that gives me much hope the request is working. I’m using exactly the same syntax that seems to work successfully on my Vero, so I’m afraid some assistance with whatever I’m missing would be greatly appreciated please.
Are you saying you can play the files as files but they are not being scanned into the library?
The only thing I noticed in the log is that kodi is upgrading all the databases from old versions. If you have just deleted MyMusic60,db to get kodi to re-make it, try deleting MyMusic* instead.
Graham: Yup, that’s what I was trying to describe, thanks for helping clarify. The files would play via the library before I tried refreshing data, and I can now use Yatse to browse files and get OSMC to play them, but having deleted the two MyMusic db files (48 & 60 were present after the above upgrade), if I start an audio scan via the web interface, it very quickly states that it’s started and then completed, so it feels more like it’s not looking at the source list than failing to find the files within the source. Having tried another reboot & library update at around 17:40, I still can’t see acknowledgement in the latest log that the request made it from the web interface to the scraper. MyMusic60.db was recreated, but it seems to stay at 192K & not get populated.
I see you were previously on OSMC version 0.9.9 and Kodi 14.2!
13:00:06 T:3023663104 NOTICE: Starting Kodi (14.2 Git:Unknown). Platform: Linux ARM 32-bit
13:00:06 T:3023663104 NOTICE: Using Release Kodi x32 build (version for Raspberry Pi)
13:00:06 T:3023663104 NOTICE: Kodi compiled Apr 8 2015 by GCC 4.9.2 for Linux ARM 32-bit version 3.16.7 (200711)
13:00:06 T:3023663104 NOTICE: Running on Open Source Media Center 0.9.9, kernel: Linux ARM 32-bit version 3.18.10-1-osmc
It certainly looks like the database is empty. You can double-check by running a simple query:
sqlite3 ~/.kodi/userdata/Database/MyMusic60.db
select count(*) from song;
Then Ctrl-d to exit.
It’ll probably give a count of zero.
You should probably restart Kodi:
sudo systemctl restart mediacenter
and try to scan again. (I assume the music is on /media/MUSIC_CV/Music, but I see you also have a remote NFS share.)
Agreed Dill: that query confirms nothing in the database, and you’re correct in believing the music is at /media/MUSIC_CV/Music. Your mention of the remote NFS share did made me think: presumably an inaccessible source wouldn’t prevent other sources being scraped, would it? That NFS share isn’t listed as a source, just as a mount point, but I’ve tried commenting it out of FSTAB before another restart, and whilst I can now see an attempt to update the library starting at 08:20 in the log, it seems consistent in behaviour: i.e. it doesn’t take long to decide it’s found nothing.
I’ve never used xbmc-send and can’t find any documentation for it in the kodi wiki, but some googling makes me wonder whether it’s still supported. Is it just a front-end for json calls? Maybe if you post the exact syntax you are using, someone here will know.
I just read the actual command is still xbmc-send, although the package is called kodi-send, but that was an old post.
Maybe the xbmc-send on the OP’s client is incompatible with the updated kodi on the Pi when it worked with 14.2. He doesn’t say which vero he’s running or what kodi on that.
Guess it’s possible there’s a send client incompatibility issue (though the command line seems to confirm the action send using either syntax below, and I’ve assumed since kodi-send is packaged, it’s updated when OSMC is), so I’ve tried both (a) using the web interface update library function, and (b) using the web interface configuration options to set the audio library to update on startup. The logs for that scenario seem to show the scan starting at 11:38:53, and completing rather quickly with an event soon afterward: “11:38:54.092 T:2786325488 NOTICE: My Music: Scanning for music info using worker thread, operation took 00:00”
Command line tells me the version of OSMC on the RPi is 2017.10-1, and on the Vero 1 where, as you say, I’m still successfully the first syntax below, the version reported by the command line is also 20173.10-1
action syntax I’ve been using historically:
xbmc-send --action=“updateLibrary(audio)”
syntax I’ve tried as part of this thread investigations:
That looks a little more hopeful, in that I can see notices & announcements around that the scan has started, but logs are also showing the same “timed out” message Graham reported, and the count from the song table doesn’t change from 0 I’m afraid. Notably, using that syntax on my Vero 1 gives me the message
NOTICE: My Music: scanning for music info using worker thread, operation took 00:100:
Am I wrong in thinking that the music database is built purely on the basis of ID3 tags? Could an incorrect scraper setting be the problem perhaps?
Forgot to mention, I tried (music) and got no difference in behaviour, also UpdateLibrary, as per the kodi wiki - case shouldn’t matter, I don’t think.
The database for Music just reads the ID3 tags. It should always work, even if off-line. If you’ve told it to do web scraping as well it will look for stuff on the web.
Your best bet will be to re-install as you seem to have updated from a very old version of OSMC which is not guaranteed to work perfectly.
The problem is that you appear to be on a Release Candidate of OSMC from early 2015.
A fresh install was needed after the stable release on 28th June 2015.
Fair enough. Fresh install does seem to have done the job (albeit needing a wired network connection to complete) with the library update now scanning and Yatse showing that the tags are being read, so thanks for that. Once the scan’s complete, I’ll be trying to get my wireless connection working without immediately resorting to another thread… I’ve seen there a few previous threads on the topic, so hopefully there’ll be enough for me to work it out. Thanks to all.
