Win Local Information Only (.NFO) scraper functionality issues
#1
Question 
Hi Folks,

Experimenting with XBMC GOTHAM (13.1 Git:20140604-84725b0). Platform: x86 Win32 32-bit] installation on Windows 7 64-bit; no extra add-ons or skins ... using what was installed at default. Noticed as few add-ons were updated but the Universal & Local audio scrapers don't appear to have been updated post-installation.

Confused on how the Local Information Only (.NFO) scrapers are intended to function.

The file metada and folder structure noted below ensures the library is usuable with XBMC, iTunes, Windows Media Player, WinAMP, Foobar2000 ... oh, and in case I forgot to mention XBMC. Smile


OVERVIEW

All of my audio files are IDTagged with: Track, Title, Artist, Album, Album Artist, Year, Genre, Grouping, Album Art (200x200x96).

Album Artist = Artist or Various Artists if compilation/soundtrack
Grouping = Genre


My audio library folder structure is as follows:

<MUSICSOURCE> = The NAS 'Read Only' share added via XBMC Music Add Source >> smb://NAS-NAME/Audio
<0-Z> = Single Letter Folder Name, artist group beginning with number/letters (0=2PAC, A=ABBA, etc.)
[DISC #] = Disc subfolder added when multi-disc title, otherwise audio files directly under album folder


<MUSICSOURCE>/Artists/<0-Z>/ARTIST/ALBUM/[DISC #]
<MUSICSOURCE>/Compilations/<0-Z>/ARTIST/ALBUM/[DISC #]
<MUSICSOURCE>/Soundtracks/<0-Z>/ARTIST/ALBUM/[DISC #]
<MUSICSOURCE>/Books/<0-Z>/ARTIST/ALBUM/[DISC #]
<MUSICSOURCE>/Karaoke/<0-Z>/ARTIST/ALBUM/[DISC #]


EXAMPLE

I created an ARTIST.NFO for each artist and an ALBUM.NFO for each album.

ALBUM.NFO folder placement.

Code:
XBMC: Books\C
XBMC: Books\C\Chester L. Karrass
XBMC: Books\C\Chester L. Karrass\Effective Negotiating
XBMC: Books\C\Chester L. Karrass\Effective Negotiating\Disc 1
XBMC: Books\C\Chester L. Karrass\Effective Negotiating\Disc 1\album.nfo
XBMC: Books\C\Chester L. Karrass\Effective Negotiating\Disc 1\AlbumArtSmall.jpg
XBMC: Books\C\Chester L. Karrass\Effective Negotiating\Disc 1\Folder.jpg


ARTIST.NFO folder placement.

Code:
XBMC: Books\C\Chester L. Karrass\artist.nfo
XBMC: Books\C\Chester L. Karrass\Folder.jpg



BEHAVIOR - ALBUM

Prior to scanning the 'Books' folder to the XBMC Library, I set the "Local Information Only scraper" as the default scraper under Settings > Music > Library for both ALBUM and ARTIST. I also set the Search For Thumbnails On Remote Shares option. Once completed, I disabled the remote thumbnails option.

Now if I navigate to Music > Library > Albums, I can see several albums - one for each group of files found within the corresponding folder.

An Album Title
Another Album Title
Effective Negotiating - Disc 1
Effective Negotiating - Disc 2
Yet Another Album Title - Disc 1
Yet Another Album Title - Disc 2
Yet Another Album Title - Disc 3
...


I select the Query Info For All Albums from the Context menu. At this point, I assume that XBMC uses the Album Local Information Only (.NFO) scraper to retrieve the information provided in each of the ALBUM.NFO. If I select Album Information from the Context Menu, I see the information that I expect to see - i.e. it seems to match what I put in the ALBUM.NFO file.



BEHAVIOR - ARTIST

I select the Query Info For All Artists from the Context menu. At this point, I assume that XBMC uses the Artists Local Information Only (.NFO) scraper to retrieve the information provided in each of the ARTIST.NFO. If I select Artist Information from the Context Menu, I am prompted to search for the Artist in some cases - such as the artist noted above, others not.

I performed different tests on the above artist so as to isolate what's going on. Here's the results with different 'default' scrapers:

Universal Scraper (Artist/Album)
  • Connected to the Internet = prompted with artist search box
  • Disconnected from the Internet = prompted with artist search box for all artists


Local Information Only (Album), Universal Scraper (Artist)
  • Connected to the Internet = prompted with artist search box
  • Disconnected from the Internet = prompted with artist search box for all artists


Local Information Only (Artist/Album)
  • Connected to the Internet = prompted with artist search box
  • Disconnected from the Internet = prompted with artist search box for all artists



SUMMARY

My observations lead me to think that the Artist Local Information Only (.NFO) is initiating a query against an external source before attempting to read the ARTIST.NFO file. I had a look at the debug log (see below) and there doesn't seem to be any errors being generated or references to an external (web) url being queried. I also had a look at the LOCAL.XML metadata file but it doesn't contain any parsing logic.

I have also noticed that refreshing the Artist/Album information by re-running the respective Query options does not update the XBMC music database - i.e. the old .NFO information remains present.

Is this expected behavior? If so, how does one force exclusive parsing of .NFO files and *no* Internet query?

Advance thanks,



Reference Links

Local Information Only Scraper
http://wiki.xbmc.org/index.php?title=NFO_files

Bug Tracker
http://trac.xbmc.org/ticket/15247
http://trac.xbmc.org/ticket/15221
http://trac.xbmc.org/ticket/15204
http://trac.xbmc.org/ticket/14612


XBMC Log Snippet

Code:
16:20:13 T:5524  NOTICE: special://profile/ is mapped to: special://masterprofile/
16:20:13 T:5524  NOTICE: -----------------------------------------------------------------------
16:20:13 T:5524  NOTICE: Starting XBMC (13.1 Git:20140604-84725b0). Platform: x86 Win32 32-bit

...

16:20:22 T:5524   DEBUG: DialogProgress::StartModal called
16:20:22 T:5524   DEBUG: ------ Window Init (DialogProgress.xml) ------
16:20:22 T:5524    INFO: Loading skin file: DialogProgress.xml, load type: KEEP_IN_MEMORY
16:20:22 T:5524   DEBUG: MUSIC_INFO::CMusicInfoScanner::UpdateDatabaseArtistInfo downloading info for: Chester L. Karrass
16:20:22 T:4020  NOTICE: Thread MusicInfoScraper start, auto delete: false
16:20:22 T:4020   DEBUG: ADDON::CScraper::FindArtist: Searching for 'Chester L. Karrass' using Local information only scraper (file: 'C:\Program Files (x86)\XBMC\addons\metadata.local', content: 'artists', version: '1.0.0')
16:20:22 T:4020   DEBUG: Thread MusicInfoScraper 4020 terminating
16:20:22 T:5524    INFO: Loading skin file: DialogKeyboard.xml, load type: KEEP_IN_MEMORY
16:20:22 T:5524   DEBUG: ------ Window Init (DialogKeyboard.xml) ------
16:20:22 T:5524   DEBUG: CAnnouncementManager - Announcement: OnInputRequested from xbmc
16:20:22 T:5524   DEBUG: GOT ANNOUNCEMENT, type: 128, from xbmc, message OnInputRequested
16:20:24 T:5524    INFO: Python, unloading python shared library because no scripts are running anymore
16:20:24 T:5524   DEBUG: CApplication::ProcessMouse: trying mouse action leftclick
16:20:25 T:5524   DEBUG: ------ Window Deinit (DialogKeyboard.xml) ------
16:20:25 T:5524   DEBUG: CAnnouncementManager - Announcement: OnInputFinished from xbmc
16:20:25 T:5524   DEBUG: GOT ANNOUNCEMENT, type: 128, from xbmc, message OnInputFinished
16:20:25 T:5524   DEBUG: MUSIC_INFO::CMusicInfoScanner::UpdateDatabaseArtistInfo downloading info for: Chester L. Karrass
16:20:25 T:5704  NOTICE: Thread MusicInfoScraper start, auto delete: false
16:20:25 T:5704   DEBUG: ADDON::CScraper::FindArtist: Searching for 'Chester L. Karrass' using Local information only scraper (file: 'C:\Program Files (x86)\XBMC\addons\metadata.local', content: 'artists', version: '1.0.0')
16:20:25 T:5704   DEBUG: Thread MusicInfoScraper 5704 terminating
16:20:25 T:5524   DEBUG: ------ Window Init (DialogKeyboard.xml) ------
16:20:25 T:5524   DEBUG: CAnnouncementManager - Announcement: OnInputRequested from xbmc
16:20:25 T:5524   DEBUG: GOT ANNOUNCEMENT, type: 128, from xbmc, message OnInputRequested
16:20:26 T:5524   DEBUG: CApplication::ProcessMouse: trying mouse action leftclick
16:20:26 T:5524   DEBUG: ------ Window Deinit (DialogKeyboard.xml) ------
16:20:26 T:5524   DEBUG: CAnnouncementManager - Announcement: OnInputFinished from xbmc
16:20:26 T:5524   DEBUG: GOT ANNOUNCEMENT, type: 128, from xbmc, message OnInputFinished
16:20:26 T:5524   DEBUG: MUSIC_INFO::CMusicInfoScanner::UpdateDatabaseArtistInfo downloading info for: Chester L. Karrass
16:20:26 T:6016  NOTICE: Thread MusicInfoScraper start, auto delete: false
16:20:26 T:6016   DEBUG: ADDON::CScraper::FindArtist: Searching for 'Chester L. Karrass' using Local information only scraper (file: 'C:\Program Files (x86)\XBMC\addons\metadata.local', content: 'artists', version: '1.0.0')
16:20:26 T:6016   DEBUG: Thread MusicInfoScraper 6016 terminating
16:20:26 T:5524   DEBUG: ------ Window Init (DialogKeyboard.xml) ------
16:20:26 T:5524   DEBUG: CAnnouncementManager - Announcement: OnInputRequested from xbmc
16:20:26 T:5524   DEBUG: GOT ANNOUNCEMENT, type: 128, from xbmc, message OnInputRequested
16:20:27 T:5524   DEBUG: Keyboard: scancode: 0x01, sym: 0x001b, unicode: 0x001b, modifier: 0x0
16:20:27 T:5524   DEBUG: CApplication::OnKey: escape (0xf01b) pressed, trying keyboard action f01b
16:20:27 T:5524   DEBUG: ------ Window Deinit (Pointer.xml) ------
16:20:27 T:5524   DEBUG: ------ Window Deinit (DialogKeyboard.xml) ------
16:20:27 T:5524   DEBUG: CAnnouncementManager - Announcement: OnInputFinished from xbmc
16:20:27 T:5524   DEBUG: GOT ANNOUNCEMENT, type: 128, from xbmc, message OnInputFinished
16:20:27 T:5524   DEBUG: ------ Window Init (DialogOK.xml) ------
16:20:27 T:5524    INFO: Loading skin file: DialogOK.xml, load type: KEEP_IN_MEMORY
16:20:29 T:5524   DEBUG: Keyboard: scancode: 0x01, sym: 0x001b, unicode: 0x001b, modifier: 0x0
16:20:29 T:5524   DEBUG: CApplication::OnKey: escape (0xf01b) pressed, action is PreviousMenu
16:20:29 T:5524   DEBUG: ------ Window Deinit (DialogOK.xml) ------

...
Reply
#2
A bit more research on this issue today and it seems like it may be a bug according to the URL's below. Although it's indicated as solved/closed, the description of the problem is exactly what I'm experiencing. I did verify the file encoding on a working artist and non-working .NFO file and they match.

http://trac.xbmc.org/ticket/15294
http://trac.xbmc.org/ticket/14964
http://forum.xbmc.org/showthread.php?tid=186965



* EDIT 14/06/2014 *

I discovered that I had inadvertently added an incorrect tag in the artist.nfo ... should have been: <musicBrainzArtistID></musicBrainzArtistID>. Made the correction, deleted the music DB and thumbnails in my test environment and issued: Scan Items To Library, Query Info (Albums), Query Info (Artists). Still experiencing the same issue.

Deleted the music DB and thumbnails in my test environment and issued: Scan Items To Library, Query Info (Albums), Query Info (Artists) and retried with <musicBrainzArtistID> related tags omitted from some of the problem NFO. same results. Still experiencing the same issue.

Noticed that my NFO's are UTF-8 PC and those exported by XBMC (Export > Library) are UTF-8 UNIX so I changed some of the problem NFO to be UTF-8 UNIX, deleted the music DB and thumbnails in my test environment and issued: Scan Items To Library, Query Info (Albums), Query Info (Artists). Still experiencing the same issue.
Reply
#3
Some progress ...

After some additional experimenting, I discovered that if I move the ARTIST.NFO file down one folder level, the Query Artist Info retrieves the contents of the .NFO. The problem seems to occur on artists where an additional sub-folder to accommodate multi-disc scenarios has been created and the artist contains a single album. For clarity;

Works

XBMC: Books\A\ARTIST\artist.nfo
XBMC: Books\A\ARTIST\Folder.jpg
XBMC: Books\A\ARTIST\ALBUM\

XBMC: Books\A\ARTIST\artist.nfo
XBMC: Books\A\ARTIST\Folder.jpg
XBMC: Books\A\ARTIST\ALBUM1\DISC 1\
XBMC: Books\A\ARTIST\ALBUM1\DISC 2\
XBMC: Books\A\ARTIST\ALBUM2\


Doesn't work

XBMC: Books\A\ARTIST\artist.nfo
XBMC: Books\A\ARTIST\Folder.jpg
XBMC: Books\A\ARTIST\ALBUM\DISC 1\
XBMC: Books\A\ARTIST\ALBUM\DISC 2\
Reply
#4
Yes, this is because the common root of all the songs is Books\A\ARTIST\ALBUM in this case.
Always read the XBMC online-manual, FAQ and search the forum before posting.
Do not e-mail XBMC-Team members directly asking for support. Read/follow the forum rules.
For troubleshooting and bug reporting please make sure you read this first.


Image
Reply
#5
(2014-06-21, 00:47)jmarshall Wrote: Yes, this is because the common root of all the songs is Books\A\ARTIST\ALBUM in this case.

Hi Jonathan,

Appreciate the reply.

That makes sense I suppose; it seems inconsistent that it's working as I expected for cases where there's more than one album in the artist folder.

Works

XBMC: Books\A\ARTIST\artist.nfo
XBMC: Books\A\ARTIST\Folder.jpg
XBMC: Books\A\ARTIST\ALBUM\album.nfo
XBMC: Books\A\ARTIST\ALBUM\Folder.jpg

Works

XBMC: Books\A\ARTIST\artist.nfo
XBMC: Books\A\ARTIST\Folder.jpg
XBMC: Books\A\ARTIST\ALBUM1\DISC 1\album.nfo
XBMC: Books\A\ARTIST\ALBUM1\DISC 1\Folder.jpg
XBMC: Books\A\ARTIST\ALBUM1\DISC 2\album.nfo
XBMC: Books\A\ARTIST\ALBUM1\DISC 2\Folder.jpg
XBMC: Books\A\ARTIST\ALBUM2\album.nfo
XBMC: Books\A\ARTIST\ALBUM2\Folder.jpg
XBMC: Books\A\ARTIST\ALBUM3\DISC 1\album.nfo
XBMC: Books\A\ARTIST\ALBUM3\DISC 1\Folder.jpg
XBMC: Books\A\ARTIST\ALBUM3\DISC 2\album.nfo
XBMC: Books\A\ARTIST\ALBUM3\DISC 2\Folder.jpg
XBMC: Books\A\ARTIST\ALBUM3\DISC 3\album.nfo
XBMC: Books\A\ARTIST\ALBUM3\DISC 3\Folder.jpg


In the scenario below however, it won't work unless I place the .NFO in the .\ALBUM\ folder.

Doesn't Work

XBMC: Books\A\ARTIST\artist.nfo
XBMC: Books\A\ARTIST\Folder.jpg
XBMC: Books\A\ARTIST\ALBUM\DISC 1\album.nfo
XBMC: Books\A\ARTIST\ALBUM\DISC 1\Folder.jpg
XBMC: Books\A\ARTIST\ALBUM\DISC 2\album.nfo
XBMC: Books\A\ARTIST\ALBUM\DISC 2\Folder.jpg


My entire (18+ yrs "in progress") audio library is configured, see first post, in this format and short of flattening the "DISC" sub-folders (1K+), I'm not sure what else can be done short of customizing the scraper via some form of XML file.

Should time ever permit, it would be nice if the Local NFO scraper could handle sub-folder hierarchies.

Cheers,
Reply
#6
How do you propose we do that? Keep going up the heirarchy until we hit a .nfo (even if that might be in music root, where a misplaced .nfo file will be used for every single artist?)

Come up with a solution that will work for your use case as well as most use cases and we can go from there.
Always read the XBMC online-manual, FAQ and search the forum before posting.
Do not e-mail XBMC-Team members directly asking for support. Read/follow the forum rules.
For troubleshooting and bug reporting please make sure you read this first.


Image
Reply
#7
(2014-06-21, 03:25)jmarshall Wrote: How do you propose we do that? Keep going up the heirarchy until we hit a .nfo (even if that might be in music root, where a misplaced .nfo file will be used for every single artist?)

Come up with a solution that will work for your use case as well as most use cases and we can go from there.

Hi Jonathan,

In my case, going up the hierarchy until the artist .NFO is reached would certainly work; however, folks with a library design different than mine may find this a challenge. In all cases, a Query Artist Info would have to look at the folder path stored in the DB and work *forward* from the there instead of *back* ... obviously, I'm assuming that everyone stores their files in ..\ARTIST\ALBUM\... or ..\ARTIST\ALBUM\DISC #\... For example, a Query on the Artist would lookup the associated Path and work downwards from there.

Pondering the dilemma further, I suppose it comes down to when artist .NFO files (and album .NFO) are parsed. IMHO; if someone has gone through the trouble of creating ARTIST or ALBUM .NFO's, they should *all* be parsed regardless of where they reside when the Local NFO scraper is selected ... assuming that someone intentionally selects the Local NFO scraper via Settings. If someone selects any other scraper, then .NFO parsing should fall to last position, if even considered at all.

On an export library, the artist .NFO file should reside in the artist root folder and the album .NFO file should reside in the track (aka album) folder - be it ..\ALBUM\ or ..\ALBUM\DISC #\ (or whatever convention). This would mean that the logic would have to examine the commonalities during library export - i.e. write the artist .NFO in the artist root folder ... which I'm not certain how that could be handled.

If others are following this discussion, now would be a good time to provide some insights/thoughts.

Cheers,
Reply
#8
As you suggest, the "how" is the key. How do we know to go up a folder and keep looking? When do we stop?

We can start at the common root (this is what we use at the moment) but that can in some cases be completely wrong (songs under "various artists" in addition to being under "artist" -> common root is the root of music -> completely wrong)

We could try some sort of fuzzy-matching to folders, but that's always a bit problematic (might be better than what we have though).

Jonathan
Always read the XBMC online-manual, FAQ and search the forum before posting.
Do not e-mail XBMC-Team members directly asking for support. Read/follow the forum rules.
For troubleshooting and bug reporting please make sure you read this first.


Image
Reply
#9
(2014-06-21, 05:01)jmarshall Wrote: As you suggest, the "how" is the key. How do we know to go up a folder and keep looking? When do we stop?

Keeping the context specific to the Local NFO scraper as I'm seeing this issue specific to this scraper - other scrapers rely on external "feeds". There will likely need to be some assumptions such as: choosing the Local NFO in Settings, audio files are/are not pre-tagged, the NFO may be supplying some/all supplemental album/artist details, local NFO contains URL's for fetching supplemental data from an external "feed".

Again though; I'm working in the mindset of how I've organized my library, which I'll touch on below, and this may not be how others have theirs defined ... and that if one is choosing the Local NFO as their choice scraper, it's because they're handling the information locally.

Folder Up

Working from the end of the directory tree backwards, a stop might be possible upon 'hitting' the first instance of the ARTIST.NFO. Possibly something like:

<XBMCSOURCE>\FOLDER\FOLDER\ARTIST\< ALBUM\< DISC #\< album.nfo



Quote:We can start at the common root (this is what we use at the moment) but that can in some cases be completely wrong (songs under "various artists" in addition to being under "artist" -> common root is the root of music -> completely wrong)

Right; and this leads to my earlier comment about soliciting some feedback from others viewing this thread.

That said, my mindset is coming from 18+ years of building my audio library when a time existed where one had to include the metadata within the tag. As I'm somewhat of a completist (couple of other words come to mind Smile ), I prefer control over the information displayed about album, tracks, artists. Since I'm handling the album and track information in the NFO files, I'm only seeing what I have as opposed to what I have and don't have. I touch the NFO whenever I need to add new entries.


My audio file metatags are defined as follows:

Code:
Track Number
Title
Artist
Album Title
Album Artist
Year
Genre
Grouping (Genre)
Album Art (JPG: 200x200x96)


My library is designed as follows:

Code:
<XBMCSOURCE>\artists\<0-Z>\artistname\albumname\[disc\]
            \books\<0-Z>\authorname\albumname\[disc\]
            \karaoke\<0-Z>\artistname\albumname\[disc\]
            \compilations\<0-Z>\albumname\[disc\]
            \soundtracks\<0-Z>\albumname\[disc\]


ARTIST, BOOKS

<XBMCSOURCE> = Read Only share from a NAS (ex: MYNAS\MYAUDIO); allows library use on Windows Media Player, iTunes, WinAMP, etc.

<0-Z> = Artists/Authors are grouped by the first name with number artists/authors placed in the '0' folder. Legacy carry-over from XBMC for XBOX to deal with 4096 object limit per folder.


KARAOKE

The karaoke folder handling is similar to artists and books with the exception that:
  • The GENRE audio file metatag has been altered to "Karaoke" to force all Karaoke tracks to be grouped under a single genre for smart playlist handling.
  • The ALBUM audio file metatag has been altered to include the word "Karaoke: " before the album name.
  • I break apart a karaoke compilation so that it matches my artist folder structure. I don't have a lot of karaoke so it's manageable, this could be an issue for karaoke masters with extensive libraries.
  • I copy the ALBUM.NFO and FOLDER.JPG to the karaoke folder and strip out the non-relevant tracks and adjust the <genre></genre> tag.
  • I append the KARAOKE album to the ARTIST.NFO.
  • I copy the ARTIST.NFO and FOLDER.JPG from the ARTIST folder to the karaoke folder.
  • I handle net new karaoke artists similarly to artists.

This approach has worked very well so far. For example; selecting the artist information on an artist with a karaoke track, I'll see two (2) instances of the same album - one for the album, and the other for the karaoke version.


SOUNDTRACKS, COMPILATIONS

Soundtrack/Compilation folders are special cases.

<0-Z> = Grouped by soundtrack/compilation name with soundtracks/compilations beginning with a number a placed in the '0' folder (ex: 8-Mile)

The ALBUMARTIST metatag in my compilations/soundtracks is set to "Various Artists". I adopted this convention when the concept of grouping by album > artist was introduced in a previous release of XBMC quite some time ago. Before this, I used to break down soundtracks/compilations so that tracks by a specific artist where in the artist folder ... very tedious and happy to have moved away from that approach.

An artist-specific compilation (ex: Greatest Hits) remains in the .\ARTIST hierarchy but a tribute to the artist by various artists would reside in the .\COMPILATIONS hierarchy. Typically, the ALBUMARTIST metatag dictates where I intend to place the album - i.e. always set to "Various Artists" in audio files found in soundtracks/compilations. Soundtracks (and scores) are bit of an exception in that if an artist did an entire soundtrack/score, I'll place the album in the .\SOUNDTRACKS hierarchy and set the ALBUMARTIST metatag to "Various Artists".

As I've been testing the NFO handling, I have noticed that most often, the correct image appears for the artist. Obviously, artists that are only on a compilation/soundtrack display a generic artist thumb image. I can think of a few ways to handle this scenario:

#1 - I create a "placeholder" folder under my .\ARTIST structure which only contains ARTIST.NFO and FOLDER.JPG.

Tedious to do on large libraries; likely still need some XBMC code change.

#2 - Extend the ALBUM.NFO file to include additional XML tags in the <TRACK> </TRACK> body

Additional tags likely required: <TRACKARTISTNAME></TRACKARTISTNAME> & <TRACKARTISTTHUMB></TRACKARTISTTHUMB>. XBMC code change required.

For example;

Code:
\compilations\M\mycompilation\album.nfo
                             \folder.jpg
                             \artist1thumb.jpg
                             \artist2thumb.jpg


Quote:We could try some sort of fuzzy-matching to folders, but that's always a bit problematic (might be better than what we have though).

Have to agree with you on the subject of fuzzy-matching. Although talented programmers, such as yourself, can likely "make it work", it always seems like it's never quite right or worse yet, introduces a world of exception coding every time the application needs extending.



Extending Local NFO With Configurable Options

Maybe it's a simple matter of extending the Local NFO scraper to provide some configurable options such as the number of folder levels to parse back when looking for artist NFO files, number of folder levels to parse forward when looking for album NFO, etc.

At the moment, it does seem like the album NFO scraper is parsing as expected and not presenting any issues ... so maybe the focus should be on the artist NFO portion of the scraper.

Whatever happens, the WIKI needs some cleanup as the examples for the music section NFO's as well as the explanations need some refreshing ... which of course, I'm happy to help with should Ned be interested.

Cheers,
Reply
#10
These issues have still not been resolved. It is not a scraper addon issue, but fundamental core music library management design. I'm taking a look at how this could be handled better, user input welcome.
Reply
#11
'Lo,
I hope there are some progress on these issues,
Artists management is unusable as it is right now.

In my opinion, there shouldn't be any link between the physical location of an artist.nfo and the files it applies to.

I hoped i could create a directory (say "artists"), put there as many folders as i have artists (i used the name of the artist as folder name) and put there nfos with bio etc, fanarts, thumbnails for every artist missing on fanart.tv, but they can't be used by any scraper ...

they are only read when placed one folder above albums, and apply to all the albums underneath.

those nfos contain musicbrainzartistid, but no link seems to be made between this id and the ids tagged in music files ...

it's very disappointing, especially for jazz or classical music where you would like to find a particular file from several artists ...

Is there any hope for an improvement in kodi 17 ?

Or will i sadly have to look for another media center for music ? (i've been using kodi for a while now, on xbox 1 when it was called xbmP, something like 15 years ago ^^)

Cheers, and thanks for the (otherwise) good work !
Reply
#12
I totally agree with your observations, and yes there is hope to improvement in 17. IMO it counts as bug fixing (even though it means quite a bit of work), so the window of opportunity to fix it is bigger than it is for adding new features. Hence I tend to look at the new feature work first, and it is also not down to me how quickly things are reviewes etc., so I can't promise anything, but I certainly will try.
Reply
#13
Thx for the answer, Dave.
And glad to see we're on the same page.
As a "data man" myself, I coul'dnt understand the logic of music library as it is right now.
I've found your thread thread about music library improvements :

http://forum.kodi.tv/showthread.php?tid=257203

Will follow it with attention (and hope ^^)
Please tell us when there is something about this subject to look at in the nightlies.
Reply

Logout Mark Read Team Forum Stats Members Help
Local Information Only (.NFO) scraper functionality issues0