[BatterPudding]

As another heavy music users I have been watching these threads, but a difference is I do use the library mode. So I do all that scanning you are asking about to another TB+ of tunes..

Love hearing from other music users - if I can get the thread right! http://forum.kodi.tv/showthread.php?tid=248430

I'll read and add some thoughts to that thread. All of us Music Collectors are odd and have our own ways of organising collections. My music is certainly not a simple case of just albums and singles! I already have some feedback to add when I get a few minutes.

[blutstein]

Having such a large music collection, could you give some feedback on this thread

done!

[tomc]

Hello,

Thanks to DaveBlake and Others for improving Music in Kodi!

Something that keeps me using file mode for music is cover art for multi disc releases:
I have a lot of classical music boxes, each disc having its own cover. Importing in library results in having the same cover art for all discs...

Could something be done for this?

[DaveBlake]

Have moved BatterPudding's addition to http://forum.kodi.tv/showthread.php?tid=249493&page=2 with other scraping discussion.

But relating to file mode...

Something that keeps me using file mode for music is cover art for multi disc releases:
I have a lot of classical music boxes, each disc having its own cover. Importing in library results in having the same cover art for all discs...

Could something be done for this?

Intreagued Tomc that lack of chosen art work for box sets causes you to use file mode. Really? You would see any embedded cover art in both file view and library view. Is it scraping extra art that is the issue, as Batterpudding interpreted? Do you use the library, but not scrape? Of course you may not like embedding any art.

Further discussion, not file view related, probably belongs on the thread above, but do feedback.

[scott967]

Hello,

Thanks to DaveBlake and Others for improving Music in Kodi!

Something that keeps me using file mode for music is cover art for multi disc releases:
I have a lot of classical music boxes, each disc having its own cover. Importing in library results in having the same cover art for all discs...

Could something be done for this?

If you look at MusicBrainz, they use the idea of release group / release / medium. This is for the purpose of uniquely identifying what a music file represents. "Album" seems to be more of a logical concept. I think it comes down to how you determine what is an "album" for your tags. Of course, other scraping sources such as TADB I think don't directly follow the MusicBrainz schema so that can cause issues, if for example you use scraping to get album art.

scott s.
.

[tomc]

I am using Musibrainz and picard for tagging, but not a Kodi scraper. folder.jpg files are embedded with MP3Tag.
This is the same problem as Batterpudding.

With boxsets like:

Artist\Boxset\folder.jpg
Artist\Boxset\CD1\folder.jpg
Artist\Boxset\CD2\folder.jpg
Artist\Boxset\CD3\folder.jpg
Artist\Boxset\CD4\folder.jpg

when boxset appears as a release on musicbrainz, same art is used by Kodi when importing to library, Local info only.
Like this:

watch gallery

image 1 = File Mode / 2= Library: art used is different from embedded art

Only solution I found is to have a musicbrainz pseudo release for each disc of the box...

Take for example the "Bach Editions" by Brilliant Classics.
"2006 edition" is splitted in 6 volumes as explained here: https://wiki.musicbrainz.org/Series/Bach..._Classics)
Covers for volume 1 are available to picard. (https://musicbrainz.org/release/5431cbcf.../cover-art)

In library mode the bach edition is only 6 albums, with quite long list of tracks... In File mode There are 155 parts with different art...

Maybe I missed something ? Do you guys have a solution for this?

[DaveBlake]

Thanks Tom for clarifying. File view is better for boxed sets than library, an unexpected reason for using it.

Clearly handling of boxed sets could do with improvement, and sorry I don't have an immediate fix. But I have copied your post over to a suitable feature request thread http://forum.kodi.tv/showthread.php?tid=248328, because it illustrates what some of the issues are. I have a lot on at the moment, but it is on the list of music things that need work.

[BatterPudding]

As another heavy music users I have been watching these threads, but a difference is I do use the library mode. So I do all that scanning you are asking about to another TB+ of tunes..

Love hearing from other music users - if I can get the thread right! http://forum.kodi.tv/showthread.php?tid=248430

Where did that thread go? I was just about to post some details

[DarkHelmet]

Here it is

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

[BatterPudding]

Here it is

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

Thanks

[scott967]

Q on musicfiles.trackformat setting. I was looking at the 1121 nightly and it is kind of confusing (also some problems when I compared to Isengard). The default setting is [%N. ]%A - %T. That works in both library - song view and files view. But I can't figure out the intent of the square brackets. If instead you set %N. %A - %T that seems to result in the same. If you try [%S/%N ]%A - %T you get [01/01 ]Artist - Title in library - songs, but in file view you get 01 ]Artist - Title. Is it no longer possible to get the discnumber in file view? (shows in Isengard) But %S/%N. %A - %T works in library songview though again just the track number in file view. And why do the square brackets sometimes show but not always? Or does [%N] have some sort of special meaning? (I don't see the difference from just %N )

scott s.
.

[Hitcher]

I guess it's to only show the dot and space if the number is available.

[DaveBlake]

Q on musicfiles.trackformat setting. I was looking at the 1121 nightly and it is kind of confusing (also some problems when I compared to Isengard). The default setting is [%N. ]%A - %T. That works in both library - song view and files view. But I can't figure out the intent of the square brackets. If instead you set %N. %A - %T that seems to result in the same. If you try [%S/%N ]%A - %T you get [01/01 ]Artist - Title in library - songs, but in file view you get 01 ]Artist - Title. Is it no longer possible to get the discnumber in file view? (shows in Isengard) But %S/%N. %A - %T works in library songview though again just the track number in file view. And why do the square brackets sometimes show but not always? Or does [%N] have some sort of special meaning? (I don't see the difference from just %N )

That is odd behaviour, well spotted Scott. I tagged all my few multi-disc sets as if they were one big disc, so unlikely to have noticed this. I'll have a look into it. [Edit: Ah ha, caused by PR8012, a tidy up in SetSong to use setters rather than direct setting. Disc number is lost. SetSong only used from file view, library view reads from database. No value means that the left static contents gets skipped too, in this case a bracket. Have fixed in PR8469, hopefully will be in nightly. Oh yes the brackets are just eye candy, no signifcance at all]

Have you had any other odd behaviour in file view? I have had an issue with the latest build that I can't repeat consistently where the tag data disappears for non-library sources. Might just be a cache issue with my frequent movement between versions (clean builds take forever), but another person giving it a test out would be appreciated.

Did you resolve the ALBUMARTISTS behaviour mentioned in a previous post?

[scott967]

Q on musicfiles.trackformat setting. I was looking at the 1121 nightly and it is kind of confusing (also some problems when I compared to Isengard). The default setting is [%N. ]%A - %T. That works in both library - song view and files view. But I can't figure out the intent of the square brackets. If instead you set %N. %A - %T that seems to result in the same. If you try [%S/%N ]%A - %T you get [01/01 ]Artist - Title in library - songs, but in file view you get 01 ]Artist - Title. Is it no longer possible to get the discnumber in file view? (shows in Isengard) But %S/%N. %A - %T works in library songview though again just the track number in file view. And why do the square brackets sometimes show but not always? Or does [%N] have some sort of special meaning? (I don't see the difference from just %N )

That is odd behaviour, well spotted Scott. I tagged all my few multi-disc sets as if they were one big disc, so unlikely to have noticed this. I'll have a look into it. [Edit: Ah ha, caused by PR8012, a tidy up in SetSong to use setters rather than direct setting. Disc number is lost. SetSong only used from file view, library view reads from database. No value means that the left static contents gets skipped too, in this case a bracket. Have fixed in PR8469, hopefully will be in nightly. Oh yes the brackets are just eye candy, no signifcance at all]

Have you had any other odd behaviour in file view? I have had an issue with the latest build that I can't repeat consistently where the tag data disappears for non-library sources. Might just be a cache issue with my frequent movement between versions (clean builds take forever), but another person giving it a test out would be appreciated.

Did you resolve the ALBUMARTISTS behaviour mentioned in a previous post?

I installed 1201 now for testing. After much experimenting, I think the intent of the single brackets is that if the included tag field is empty, nothing within the brackets is to be shown, for example [%N. ] with no track number then it doesn't display the dot-space either. That would be analogous to $INFO[infolabel,pre-text,post-text]. But it doesn't actually work that way, at least not all the time.

I had a another music file laying around, this one album Lulu credited to Lou Reed & Metallica and in Musicbrainz it gives the album artist as Lou Reed separate from Metallica. And when I scanned it in that's what I got. I did some studying of the tags and couldn't see a functional difference between the file that scans correctly and the one that scans incorrectly, so I need to do some more digging into it. But at least it does seem that the intent is that "album artist" is a credit when "album artists" and "musicbrainz albumartistid" are provided and "album artists" + "musicbrainz albumartistid" should determine what artists are added to the db.

I have another problem, in files view a have a handful of song files that instead of showing "duration" on the right, show the file size. In library song view (note has to be in "name" sort to see this data) the duration is just blank. Any idea how Kodi gets the duration? Other software seems to figure it out somehow. I guess in library views it is set in infolabel ListItem.Label and ListItem.Label2 and the actual contents is set based on the sort value of the view.

scott s.
.

[DaveBlake]

I have another problem, in files view a have a handful of song files that instead of showing "duration" on the right, show the file size. In library song view (note has to be in "name" sort to see this data) the duration is just blank. Any idea how Kodi gets the duration? Other software seems to figure it out somehow. I guess in library views it is set in infolabel ListItem.Label and ListItem.Label2 and the actual contents is set based on the sort value of the view.

When a file is scanned (for library or on the fly for file view), duration is set to length (seconds as integer) taken from TagLib for the format of file. This gets stored in the song table as seconds too. Duration is in CMusicInfoTag.iDuration as seconds either way (scan or display).

For display "D" the label formatter converts musicinfotag.GetDuration() into a string of H-M-S or M-S depending on size > 0. When 0 (a value has not been determined by TagLib and stored in the database) it uses the fileitem.m_dwSize value instead. The later is also use for sorting by duration (not FileItem.musicinfotag.GetDuration()). It would seem from your testing that fileitem.m_dwSize does not get populated when in library view, but does when in file view, that kind of makes some sense.

You could check the database song.iDuration values for these files to see this. One could ask with these files why TagLib is failing to get a length for these files. I think we have a new version of TagLib in Jarvis if you are seeing differences with library view of these files in Isengard, but what happens inside is beyond me.

And yes, in Jarvis the contents of lable2 is dictated by sort value. Only when sort is by name does musicfiles.trackformat apply.

Thanks for the testing Scott, always good to get another pair of eyes on this stuff.