I tagged all my mp3's with MP3Tag and additionally created nfo-files with MediaElch for each artist and album.
But for a few artists the artist information enclosed in the nfo-files is not shown in Kodi, neither the artist picture (folder.jpg).
The same happens with the album information of albums of the related artist.
(this happens with Kodi 15.2 and Kodi 16 beta 4)
I uploaded the information of two artists (8 MB), one of them working normally (Billy Idol), the second one with the mentioned problem (Abuelos de la nada).
Because of coypright reasons the mp3-files are not part of the uploaded information, but are normally available within the album-folder.
Anyone has got an idea what is happening ?
https://dl.dropboxusercontent.com/u/3066...xample.zip
I'm not an NFO expert, but I can't see anything wrong with the files. I am guessing there could be a mismatch between artist name in the library and the NFO.
In Jarvis what happens if you chose Album Infomation from the context menu when the problem album (Abuelos de la nada) is selected, and then click on the Refresh button? Could you try that with debug enabled and post the log.
The only other obvious omission is the musicBrainzArtistID from
Los Abuelos de la Nada... if you're just using local NFOs, it shouldn't really be needed, but if it's trying to do some kind of lookup then it might be relevant.
I also couldn't find those guys on theaudiodb, which would also impact a lookup (scraper-dependent, obviously).
Thank you for having a look at the nfo-files!
I uploaded a log at
http://pastebin.com/7iAa2FwM
I also recorded a video showing what's happening (2 minutes duration):
Apart from the Titan-Skin that's a completely new installation of Kodi 16 Beta 4.
On another computer, where I am using Kodi 15.2 I even can't enter the detail information screen after pressing 'i' / 'ctrl-i'.
I am not using the universal music scraper or any other scraper, just local nfo-files. But normally if I do a 'refresh' he gets the information correctly from the nfo-files.
(removing the musicBrainzArtistID doesn't change anything, I already tried that.)
Love the video
Could it be something as simple as your folder hierarchy? Trying to use .NFO files for the first time in testing (said that I didn't know much about NFO) I got that wrong. Kodi derrives the artist path from the path of the songs for that artist. If there are many it calculates the common one, but if there is only one path it assumes an artist>album>song file system.
Noting that for Los Abuelos de la Nada you have 1 album that is a 2 CD set, I am going to guess that Kodi is just looking in the wrong place for the .nfo files. I know that Kodi handling of multiple disc sets is weak and there are other posts that describe issues, I suspect that is what is happening here.
Are all the problem artists and albums multiple CD sets?
Concerning your first idea:
In my example the folder hierarchy is quite simple, something like:
F:\Music\Artist_1\Album_1
F:\Music\Artist_1\Album_2
F:\Music\Artist_1\Album_3
F:\Music\Artist_2\Album_1
F:\Music\Artist_2\Album_2 (F: can be a local drive or a NAS, doesn't matter)
Regarding the second idea:
No, it also happened with just "one-CD-album"
There are dozens of other artists and albums, one and multiple albums, in the same path working well and all nfo-files have been created with the same program (MediaElch).
The only thing I can do at the moment is adding the folder.jpg manually in the refresh-dialogue and adding the artist resp. album information by manipulating directly the SQL-database on the NAS, that way it works, but obviously one should avoid the second approach ;-)
Anyway, thanks for your support.
All sounds normal enough
I am intreaged what is going wrong here, so let's see if we can figure it out.
From the debug (and video) it seems that Kodi is not finding an artist.nfo file in the place it is looking. The NFO looks OK, in fact I have created a fake song file, scanned it into my library creating that artist and used the NFO to load the biog etc. So why isn't Kodi finding it in your system?
Well if you are up for looking at the SQL directly, just looking not editing, then I would be interested to know what path is stored for all the songs from the Abuelos de la nada album. Take a look at the songview and let me know.
The songs of the album link to the right location, something what doesn't surprise me as I am also able to play the songs.
I don't know where to look for the path of the artist / album. The fields of the artist seem to be normal to me ('strBiography' was manually filled by me and didn't contain anything after scraping). Especially strImage and strFanart are empty, but they are also empty e.g. in case of Billy Idol, where all pictures work fine.
watch gallery
I found where the location of the pictures are saved. The entries are wrong, but why?
watch gallery
(2016-01-04, 23:47)malvinas2 Wrote: [ -> ]The songs of the album link to the right location, something what doesn't surprise me as I am also able to play the songs.
I wasn't implying it would be wrong, just wondering what it was.
That location is ..../Los Abuelos de la Nada/Himnos del corazon/CD1/ (my eye sight isn't what it was)
What folder is the artist.NFO located in?
Quote:I don't know where to look for the path of the artist / album.
They don't have a path, Kodi derrives it from the related songs. I am guessing that it is somehow messing up because of "CD1", hence using the album folder.jpg for artist.
I want to try and recreate your file layout so I can test it in debug.
(2016-01-04, 23:47)malvinas2 Wrote: [ -> ]The songs of the album link to the right location, something what doesn't surprise me as I am also able to play the songs.
I don't know where to look for the path of the artist / album. The fields of the artist seem to be normal to me ('strBiography' was manually filled by me and didn't contain anything after scraping). Especially strImage and strFanart are empty, but they are also empty e.g. in case of Billy Idol, where all pictures work fine.
watch gallery
Looking at your screenshot, it appears your folder structure is: artist/album/CD1
in that case I think artist.nfo has to be in the album folder. Overall my experience with trying to get artist.nfo to work isn't that great. What I do is wrap it in a <musicdb></musicdb> wrapper, use .xml extension and do a music library import. Never have a problem with that.
scott s.
.
We do put guides in odd places... I would never have looked under skins for guidence on my folder structure. Posted 2009, I do wonder if it is out of date?
Like Scott, with a folder structure of artist/album/CD1 and only one album for this artist, I think that Kodi is looking in the album folder for the artist.nfo, two levels up from the song files. Could you move the artist.nfo for Los Abuelos de la Nada to the album folder below and see if it works.
What Scott then suggests is that you create an import file by putting combining your NFO files into a single xml file with <musicdb>... </musicdb> tags at either end of the file. Try export and see what the resulting file looks like, then you will understand what he is saying.
But do try relocating the NFO first, I would like to know if that is the issue.
Your assumption was right:
I changed the structure to the following one:
\music
\artistname
\album
artist.nfo
folder.jpg
\CD1
album.nfo
folder.jpg
fanart.jpg
lots of mp3's
\CD2
album.nfo
folder.jpg
fanart.jpg
lots of mp3's
And it is working !!! I also have to correct myself: The second artist affected by this error indeed has got one album consisting of 2 discs.
Changing its structure results in the same behaviour. Awesome!
Well, maybe it is better to reduce all multiple disc albums to a one-disc album adjusting the track numbers? To avoid such kind of problems ?
(2016-01-05, 20:39)malvinas2 Wrote: [ -> ]Well, maybe it is better to reduce all multiple disc albums to a one-disc album adjusting the track numbers? To avoid such kind of problems ?
I have, it was just simpler and I have very few 2 CD albums anyway. But I understand that there are cases where people want to keep the disc set data, it depends on your needs really.