Music File View Mode Display of Tag Data - keep or remove it
#16
(2015-11-07, 11:47)jjd-uk Wrote: What I'm wondering is that if setting content type to Songs is indeed causing issues for skinners, would it be possible to go back to using GUIViewStateWindowMusicSongs for the Files view? Being able to use tags in this way has been in Kodi since the XBMP days over 10 years ago, it's what brought me to this software in the first place.
I think that the existence of yet another dialog - GUIViewStateWindowMusicSongs - is also something that the skinners would like to avoid. But perhaps they could confirm?
Reply
#17
(2015-11-07, 11:46)Koying Wrote: If there is something missing in our library that makes you use FS based organization, we have to add that to the library, not clutter the file view, imo.

Just to be clear, I do use the Library for my unadulterated Albums, by that I mean albums as they would come from itunes, amazon, cd etc.

Where the Library does not work for me is my own user created collections (since there is no online metadata), some of this this stuff I don't want in my Library as it would create loads of duplicates, other stuff I could probably migrate over to using the custom audio nodes, but their creation is not the most user friendly of processes at the moment and takes a lot of time and effort compared to something that would take a few minutes via folder structure.

My view is simply why not offer users the choice when to my inexperienced eyes it adds very little overhead to the code.

(2015-11-07, 11:46)Koying Wrote: but how many times, in video file view, did I swear to god because I couldn't see the actual filename or filetype of a video because it was replaced by it's library counterpart...

Then turn the option off in the Settings.
Reply
#18
I have previously made my feelings clear on this:

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

Like Dave Blake, I favour retaining the legacy handling of File View. The way it is right now in Jarvis is fine. If there's to be any change it should be towards being useful and respecting what's specified in the File Naming Template.

I strongly oppose rigidly displaying only an unhelpful DIR listing - such as size, date, type and literal file name. This is old school thinking even by Windows 95 standards.

The purpose of Kodi is to be a useful media reader, not a remote file explorer.

As for forcing Library View, sorry it just doesn't work for me, and for most people I know. There's a point when it chokes on too many artists. Being able to sort into folders perhaps isn't ideal, but it's better than lumping them all in together in a ball of mixed tag integrity. And that's a common use case.

If you need me to elaborate, I'll happily labour through the reasons. Suffice to say, it's not because I'm lazy or don't understand it.
Reply
#19
I think music is very different than movies. I have my albums organised in the library but I have other music like for example my Christmas and I don't want it or Idon't need it in my library.
I really don't see why in the file view you shouldn't be able to sort by file properties. They're directly from file without extra info...
Reply
#20
Anotber use case, I'm having a party and friends bring some of their favourite music on usb stick, at the moment all I need to do is add usb stick as a source as I may not want their music polluting my Library, however I still want to see the tags.
Reply
#21
Yep, valid use cases.
Not sure what was the case for removing tag support in files list in the first instance, but a setting (like there is for video, apparently Smile ) would be a compromise.
Reply
#22
(2015-11-07, 10:24)Jeroen Wrote: My point, again from a skinner perspective, is that treating a list of folders as a list of songs is... just wrong...it does not make any sense... I really don't get what is so hard to understand about this Rolleyes Huh. You are making my objections about something completely different.
This is also a problem for me because I had one view that was only to be used for songs but with the change it was then used to display folders because their content became 'songs'. I had to hack around this by adding SubString(Container.FolderPath,musicdb) to my views.
Reply
#23
(2015-11-08, 13:31)Hitcher Wrote: This is also a problem for me because I had one view that was only to be used for songs but with the change it was then used to display folders because their content became 'songs'. I had to hack around this by adding SubString(Container.FolderPath,musicdb) to my views.

I am happy to work with you to try and find a way to keep the facility to see tag properties for music files in file view without making it difficult for skinners. I presume that restoring GUIViewStateWindowMusicSongs is not a direction you want to go in? The question is how to replicate its functionality without giving you other issues.

Can we agree that it is reasonable for file view to continue to display and sort by the properties of the files? If that is music files then that means the tags, could also do so for video once tagging them becomes more mainstream, and does for image files too.
Reply
#24
Could we have a new content type for music files that makes use of tags so content type Songs is only used for Library items, then Files functions as a pure File list or uses tags by how "Enable tag reading" in Settings is configured.
Reply
#25
(2015-11-07, 11:30)DaveBlake Wrote: @Jeron is still sounds that you are angry and offended by me.
I am not angry, just annoyed by the response as I see discussions on Git all the time. I think it's healthy and that it encourages involvement of the (developer) community. But as I said, I understand now what your comments about clutter and wanting to move this discussion to the forum were based on, even though I don't agree with them.

Quote:I did not intentionally twist any words, I simply responded to what I thought you were saying. I want to discuss this issue reasonably and calmly even though it is one where opinion is clearly divided.
I reported that the merged PR is causing a problem for me as a skin developer, and you explain this as me wanting to "dumb down Kodi" user features. That is twisting my words, be it intentionally or not.

But let's leave this false start behind us and focus on the matter.

(2015-11-07, 11:27)jjd-uk Wrote: Could you explain why this is wrong? seems logical to me that a folder of music contains a content type of Songs?

Yes, that is logical (in most cases), and I am not claiming otherwise. In this folder / file listing:

Code:
[filesystem]
  [folder]
     [song1.mp3]
     [song2.mp3]
     [...]

It is totally logical to set the content type of the folder to songs.

In this example
Code:
[filesystem]
  [folder]
  [folder]
  [folder]

I don't find it logical at all to set the content type to songs, as there are none in this listing. Yet this is what Kodi currently does, simply because of the fact that this folder structure is present in music's files node.

In this example
Code:
[filesystem]
   [folder1]
   [folder2]
      [subfolder]
          [song1.mp3]
      [...]

I find it logical to set the content type of the subfolder of folder2 to songs, but nothing else. Yet, Kodi treats everything in this listing as songs.

Futhermore it is very dependant on the file and folder structure, epecially in a files view as different people use different structures.

I can have this layout for example

Code:
[filesystem]
[folder]
   [subfolder]
      image1.jpg
      booklet.pdf
      somefile.foo
   [song1.mp3]
   [song2.mp3]

The subfolder could contain album art, digital booklets, whatever. They are related to my music, but they are not songs and as such do not contain any song related tags or metadata on which skinners often base the chosen layout, infolabels, etc.

I have said on multiple occasions over the years that I feel that content types should be used for the library, or files mode should simply be set to a "files" content type (for music, video, pictures, everything). That way skinners can simply base their layout in the files nodes on ListItem.HasFiles, ListItem.IsFolder, etc. And maybe for music there could be specific infolabels that interpret the tags / file properties. I am in no way saying that reading file properties should be removed from Kodi. Quite the contrary, I feel that a file properties based listing should be the default, with the optional retrieval of rich metadata from the web. That would truly be a unified music section.

But to me the heart of the matter is, don't make assumptions about the content type. Content types should be set according to:
  • What the user has set the content type to (when setting up media sources)
  • What an add-on reports the content type to be (this is hardly without it's own set of problems, but that's another discussion)

And not based solely on the fact that some folder happens to be somewhere in the music's sources.
Reply
#26
Ok now I see your point. Did you have any of these problems with Isengard? or is it purely the additional view types now available due to Content being set to Songs? The problem with the current way is we only know they are folders within the music source, has nothing has been scanned into the database there's no way of knowing at what level the actual music files reside.
Reply
#27
(2015-11-09, 09:44)Jeroen Wrote: I am not angry, just annoyed by the response as I see discussions on Git all the time. I think it's healthy and that it encourages involvement of the (developer) community. But as I said, I understand now what your comments about clutter and wanting to move this discussion to the forum were based on, even though I don't agree with them.

Ironically I totally agree with you. I would prefer to be free to discuss matters on Git, but the past behaviour of the repo owner means that I do not feel that I can. I have seen what I felt to be productive design discussion just abruptly locked, and I didn't want that to happen in this case. I possibly now over self-censor myself as a consequence which is unfortunate.

But yes let's focus on the matter in hand.

Quote:I am in no way saying that reading file properties should be removed from Kodi. Quite the contrary, I feel that a file properties based listing should be the default, with the optional retrieval of rich metadata from the web. That would truly be a unified music section.

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

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?

Quote:But to me the heart of the matter is, don't make assumptions about the content type. Content types should be set according to:
  • What the user has set the content type to (when setting up media sources)
  • What an add-on reports the content type to be (this is hardly without it's own set of problems, but that's another discussion)

And not based solely on the fact that some folder happens to be somewhere in the music's sources.

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?

Is that the crux of it? Am I finally getting it?

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?
Reply
#28
How did the old music files know when the content was actually songs? I had folders within folders but the content only ever changed to songs when I entered a folder of songs.
Reply
#29
I think Microsoft does have a library, WMP or WMC.

Many users have set up complex folder structures to organize music. Seems to work for them.

As far as MediaMonkey, it has a "location" node in its tree view which expands into the actual file system folder tree. It shows all the metadata.

Kodi has a side effect that you can add tagged mp4 files (such as music video) as a music source and have the metadata displayed in file view. Can be helpful for those who have trouble extracting tags to nfo.

I don't use the file view myself, but I see the use cases for it.

scott s.
.
maintainer of skin  Aeon MQ5 mods for post-Gotham Kodi releases:
Matrix see: Aeon MQ5 Mod Matrix release thread
Nexus see: Aeon MQ5 Mod Nexus release thread
Aeon MQ 5 skin and addon repo 11.1.0
Reply
#30
(2015-11-09, 21:25)Hitcher Wrote: How did the old music files know when the content was actually songs? I had folders within folders but the content only ever changed to songs when I entered a folder of songs.

I don't know, but it does seem a key point. I think that the content changed once you entered a folder that you have added as a music source, regardless of whether that folder contains any song files, or other kinds of file or just more folders. But not sure.
I guess I am going to have to go back to Isengard and step through debug to try and understand how it worked. I have been putting it off as my dev environment takes forever to rebuild so switching versions is non-trivial.

Unless anyone else already knows how it all worked?
Reply

Logout Mark Read Team Forum Stats Members Help
Music File View Mode Display of Tag Data - keep or remove it0