[Hitcher]

My mistake, I've just checked Isengard and every level in MyMusicSongs is classed 'files'.

[DaveBlake]

My mistake, I've just checked Isengard and every level in MyMusicSongs is classed 'files'.

But in Isengard navigation through the subfolders of an added music source only lists folders and song files. Other files that may be there are ignored. But if the source has already been scanned into the library then in file view you see album cover art for folders. Song files are listed with their title from the tags (not the file name) and artist name, and in "Media Info" view type some of the other tag data shown for the selected file.

That sounds like content is set to "songs", but need to debug to know for sure. Won't be able to do that until tomorrow at least.

[jjd-uk]

But if the source has already been scanned into the library then in file view you see album cover art for folders.

No need for that if you have embedded covers as they also show in Files view without the files being scanned into Library.

[DaveBlake]

But if the source has already been scanned into the library then in file view you see album cover art for folders.

No need for that if you have embedded covers as they also show in Files view without the files being scanned into Library.

Yes embedded covers show for the selected song file without scanning to library. But also a selected folder in a list can show cover art, but it seems only when there is a library entry. I don't get the same behaviour for subfolders unless the library knows about them.

[phate89]

But if the source has already been scanned into the library then in file view you see album cover art for folders.

No need for that if you have embedded covers as they also show in Files view without the files being scanned into Library.

Yes embedded covers show for the selected song file without scanning to library. But also a selected folder in a list can show cover art, but it seems only when there is a library entry. I don't get the same behaviour for subfolders unless the library knows about them.

if you have a folder.jpg in the subfolder is going to be used as as image in file view...

[Jeroen]

Well I certainly misunderstood you before!! That is providing by "file properties" you mean all data inherent in the file including tags.

Definitely.

What you say about the mixed content of folders is certainly true. What I am less clear about is whether Isengard having CGUIViewStateWindowMusicSongs, other than being yet another window to code, caused similar skinning or content problems?

I don't have an Isengard install available at the moment but I didn't have the same problem. But in Isengard and before, because of the clear distinction between MyMusicNav.xml and MyMusicSongs.xml it was "manageable" I guess. The removal of the latter is something I definitely applaud though.

It is unclear to me why setting the content type to songs is needed for the file properties to show in the music files node? Would it be possible to not set a content type or set any non-library node to a "files" content type? That way the behaviour would be more predictable for skinners. They could adjust the layout simple based on whether an entry is a folder or a file (and I guess also based on the file extension) and use variables to set the desired infolabels. I think that would cover most needs in that regard, but other skinners might have different opinions.

I may still be misunderstanding you so please bear with me....

Does the first point in your list mean that once the user has added a folder as a music source you are OK with setting content to "songs" even though the music files themselves may be several subfolders down, and there could be other kinds of file in there too?

Is it that the way the fix is implemented even the top level window that lists the sources (and has an "add music..." item) gets labelled as having content of "songs" that is the problem?

Well, I realize I should have given my first point about that some more thought as I was mainly thinking about video I'm afraid. Which is obviously where setting up the sources is more...predictable, my bad.

Of course using the fact that the user has added a folder as a music source does not ensure it contains only music files.
So say we have a "files" content type. Would it be possible for a skin to adapt to what kind of file is currently selected and show the music tag data, or picture data or whatever data we may have available that is inherent to the file? Could it adapt the sort criteria available depending on the files it finds. Or would it all become a matter of lowest common denominator?

Yes I think it could, which is basically what I described in the first part of this comment.

Basically using a variable the process would (simplified) be:

Code:

<value condition="ListItem.IsFolder">Show stuff you want a folder to display</value>
<value condition="!ListItem.IsFolder + !IsEmpty(ListItem.Artist)">show music / artist / song related data</value>
<value condition="!ListItem.IsFolder + StringCompare(ListItem.FileExtension,jpg)">show data like file data, dimensions or whatever</value>
<value condition="!ListItem.IsFolder>fallback to any set of generic file properties / data</value>

Just an example of course, but that would be the basic thought behind it.

[DaveBlake]

Well I certainly misunderstood you before!! That is providing by "file properties" you mean all data inherent in the file including tags.

Definitely.

Good

It is unclear to me why setting the content type to songs is needed for the file properties to show in the music files node? Would it be possible to not set a content type or set any non-library node to a "files" content type? That way the behaviour would be more predictable for skinners. They could adjust the layout simple based on whether an entry is a folder or a file (and I guess also based on the file extension) and use variables to set the desired infolabels. I think that would cover most needs in that regard, but other skinners might have different opinions.

It is unclear to me too. But with content "files" MyMusicNav.xml / CGUIWindowMusicNav does not show the tag file properties in the way that MyMusicSongs.xml did. Changing content restored the visibilty, so seemed a reasonable fix, but clearly causes other problems that I had not forseen. I have a build of pre PR8011 (the unified view) chugging away, and I will try and work through debug to see if I can understand the differences better and find another solution.

You seem to suggest that adapting the display depending on the files on show is something that could be done in the skin. Was MyMusicSongs.xml doing that?

[DaveBlake]

Finally had a Eureka moment

In my fix to the file view functionality inadvertantly lost in PR8011, I set content to "songs" as it was the only way at the time I could see to get "media info" view type available in the way it was before CGUIWindowMusicSongs was removed. It is the view type that displays the most file properties. I now realise that it was actually a change to ViewsMusicLibrary.xml, made at the same tme, that I was trying to overcome and doing so in a bad way. I mistakenly was trying to fix a skin issue in the GUI code. Doh!

So perhaps the skinners can advise.

In Isengard in ViewsMusicLibrary.xml for "MusicInfoListView" (506) we have

Code:

<visible>Window.IsVisible(MusicFiles) | Window.IsVisible(MusicPlaylist) |  Container.Content(Songs) | Container.Content(Albums)</visible>

After PR8011 this became

Code:

<visible>Window.IsVisible(MusicPlaylist) |  Container.Content(Songs) | Container.Content(Albums)</visible>

Simply restoring Window.IsVisible(MusicFiles) does not make "Media Info" appear in the list of view types. Would the following be a reasonable solution, along with ensuring that content = files of course.

Code:

<visible>Container.Content(files) | Window.IsVisible(MusicPlaylist) |  Container.Content(Songs) | Container.Content(Albums)</visible>

If someone can confirm this is OK, afterall I don't want to upset anyone even more. If it is then I will fix my fix (again) before Jarvis Beta.

[ronie]

yup, if you make sure content is set to files inside the 'Files' node, all skinners will be happy.

as for your proposed Confluence changes, i have no problem with enabling the MediaInfo view for files as well.
it may look a bit empty when there's no info to display, but it wouldn't hurt either.

[DaveBlake]

Right then, I have raised PR8377 that restores content = "files" (by no longer forcing to to be songs) when in file view, and makes a small change to Confluenece so that "Media Info" view type visible when Container.Content(files).

The latter is what I was trying to achieve when I set content to songs, but I was unaware of how the skin could be modified to achieve "Media Info" visibility.

Hopefully this will suit everyone

Jenkins is building so it should be available for testing sometime today. Like to get this into the beta if possible.

Win32 build here http://mirrors.kodi.tv/test-builds/win32...iaInfo.exe

[blutstein]

As a user with a large database of musik (~1 TB) manually tagged with all information i need (mostly DJ mixsets), i would scream no to a simple filelist, and for a software calling itself "mediacenter" it would be a shame if tagging would be abandoned.

Imho get rid of the file view and use only tag, THIS would be contemporary.

[DaveBlake]

As a user with a large database of musik (~1 TB) manually tagged with all information i need (mostly DJ mixsets), i would scream no to a simple filelist, and for a software calling itself "mediacenter" it would be a shame if tagging would be abandoned.

Imho get rid of the file view and use only tag, THIS would be contemporary.

No worries, no plans to abandon tags. They are essential to the music library, if anything Kodi will process more tags in the fuiture. But he usefulness of keeping a file view that shows tag data has also been demonstrated so we will keep it. The coding that was causing the skinning problems that prompted this thread has been fixed.

Having such a large music collection, could you give some feedback on this thread
http://forum.kodi.tv/showthread.php?tid=248430 [corrected!!]

Do you use the music library (scan all that tag data)? Do you scrape artist or album data?

[zag]

wrong thread link? ^^

[BatterPudding]

Having such a large music collection, could you give some feedback on this thread http://forum.kodi.tv/showthread.php?tid=24843

That's a post on WOL....

Do you use the music library (scan all that tag data)? Do you scrape artist or album data?

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..

[DaveBlake]

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