[DaveBlake]

Rather than clutter Git I would like to pull the discussion of this topic out onto the forum and a wider audience. I hope that some users see it here, although communicating with the average user is difficult.

Until Jarvis when using music file view if the files were songs then the tags were scanned and tag data displayed. Then PR8011 aiming to reduce the diversity of dialogs to simplify skinning and make music more like video, resulted in this tag data no longer being displayed. This loss in functionality was discussed in the middle of this thread http://forum.kodi.tv/showthread.php?tid=235259&pid=2129282#pid2129282, mixed up with other things. The conclusion was that until such a time as the function could be performed by the library the original functionality should be restored. I did just that in PR8205 and a better fix in PR8287.

However there are some devs that can not see the point in keeping an enriched music file view. They believe that music file view, just like video, should just be a list of folders and files and nothing more. It is a comment that came up post merge on both PRs. Personally I don't see why there is a desire to dumb-down Kodi, by removing useful functionality, but I am a new dev team member and could easily (and even reasonably) be voted out on this matter.

There may also still be flaws in my implementation of the fix, I'm not saying I did a great job just advocating that the functionality need to be provided.

So can we discuss it one more time, and be clear on what the issues and requirements are. I may try and summarise posts from the previous thread (or can someone merge the approriate posts?)

[Koying]

Personally, I've always be confused by the fact that the file view for Music showed tags. IMO that makes the library redundant or vice-versa.
Although I agree this is a removal of functionality, I think that being consistent brings value, too.

[Tolriq]

Well just to repeat myselft as in those discussions

Currently library of Kodi for music is limited and unclear for users with tags / MB / nfos and online scrapers.
From Yatse stats more than 50% of music users do not use the library and use the file mode to use Kodi for music as they have organized their data in folders but they still want to see the correct names and information in lists as opposite to filenames that can be very very long and unusable. (IMO this will become true also for video when video tags are more spreads)

Removing this function before having a 100% valid replacement with a working library, will only cause more grief against database for music and keep users out of Kodi for music.

And no removing a function and saying we will fix other things in 2 or 3 version is not the solution as users will never switch back if you break their usage, they'll find another way with something else and keep to it even if Kodi fix it afterwards.

[Koying]

Removing this function before having a 100% valid replacement with a working library

That I agree. I don't use the music library enough to judge, but if it's not on par with the video one, we shouldn't remove the file view.
OTOH, I stand on my position that a file view should be... a file view. Even the current mix up in the video file view (where data is pulled from the library if a match exists) annoys me.

[BatterPudding]

The TAGs are in the files so therefore should be part of the file view. There should not be any database lookups, just reading of data that is in the file.

Look at Details View in Windows Explorer, the file manager. That allows for more information to be extracted from a file to be displayed in an extra column for sorting. As the Track Number is in a tag, and the tags are in the files, it seems logical that KODI should allow this to be a field to sort on.

Those track numbers are vital as many people play whole albums and want them in order.

The way I understand this: File view should be reading the files. Library view should be reading the database.

[DarkHelmet]

I vote for showing tags in files view. Usually the video section is more developed than the music section on kodi. In this case however reading and showing tags is the more advanced solution. I have videos with tags and I'd wish the tags were read in files view in the video section too.

I therefore vote for tags in music files view AND video files view to keep it consistent.

I also vote for moving this thread into the feature request section. I think some users will not read the development section.

[zag]

The idea of 'dumbing features down' as you put it, is basically simplification.

If the code can be made more simple and streamlined then new cool features are much quicker to build (and there is less discussion on blockers). But as a software developer, I'm sure you know that already

I see why its wanted, but its just one of those features that some people have gotten used to so I guess we have to keep it.

My personal opinion is that all tags should be read into the library and nodes ect should be setup by default to let people browse by decade ect.

I've also submitted a new node PR's for things like A-Z listings and that was rejected, so I definitely think we need a solid plan of action for the future on this.

[Martijn]

I see why its wanted, but its just one of those features that some people have gotten used to so I guess we have to keep it.

This is absolutely false! Features should be kept because they make sense in the bigger picture. Not because some people are used to it and are to stubborn to move on.

[Jeroen]

Ok, let's try this again.

First let me respond to what you said in the PR

There are lots of users that only use file view for music, and there are good reasons for doing so rather than add all files to the library, it is not just personal preference.

It is all about personal preference for those users. That doesn't mean it is the only way. For me? It has absolutely nothing to do with personal preference. I don't even use Kodi for music. My comments were made from a skinner's perspective, not from a user perspective.

It may not make sense to you, but removing this functionality would simply drive users away from upgrading to Jarvis.

The same was argument was made many years ago when files mode was removed from video. Angry people raising hell claiming XBMC was doomed. When was the last time you heard anybody about that? But again, I am not advocating the removal of using tags in the music section.

An enriched file view is quite standard for Windows

Aside from comparing an OS' file manager to a media center application being...off, my objections have nothing to do with not wanting an enriched file view... 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 . You are making my objections about something completely different.
It
It's as if in the video files node we would set the content type of the tv show sources to episodes...it's simply incorrect and it causes / forces inconsistent behaviour.

, and has been standard for Kodi music. Just because you don't use that feature in Kodi what is the reason to remove it? I don't understand the desire to dumb down Kodi?

Just because we have done things a certain way, does not mean it is a valid reason to keep doing it that way. Again, I am puzzled as to why you think this because of my usage? I made it pretty clear I have objections with this from a skinning perspective.

I understand your motivation for needing to move this to the forum now, but I don't feel like I am taken very seriously by being told I am basically cluttering Git, even though I posted in the skin dev forum first and was asked by ronie to comment on the PR. You twisting my words and putting words into my mouth doesn't really help either. I have been skinning since '08 so I like to think I have some sensible thoughts about this.

Users may think I want features to be taken away, or that I want to force my way. This really is not the case. As I have said before, if library mode is lacking something that makes people cling onto files mode, then that is the problem that needs to be fixed. Using methods that are logically false just to workaround the problem is not the way to go IMO. There is nothing logical about having two modes that "sort of do the same, but not quite". It is confusing and redundant. Find a way to merge files and library in away that makes sense.

Even the current mix up in the video file view (where data is pulled from the library if a match exists) annoys me.

Fully agree.

[jjd-uk]

As has already been sated, tags are part of the file properties, why should we be force to add stuff to the library to view and sort by these these file properties?

I've got some stuff I simply do not want to be part of my library but the files are fully tagged and organised by folder structure, stuff such as singles, seasonal music e.g. Christmas songs, or perhaps a new downloads I'm unsure whether I'll keep.

OTOH, I stand on my position that a file view should be... a file view. Even the current mix up in the video file view (where data is pulled from the library if a match exists) annoys me.

Seems like Microsoft disagree with you.

Oh look I can set content type on my folders



and then see my metadata and sort by it



OS-X does something similar as well.

Any user friendly software will give you the ability to view all properties of a file including any embedded metadata.

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 . You are making

...it's simply incorrect and it causes / forces inconsistent behaviour.

Could you explain why this is wrong? seems logical to me that a folder of music contains a content type of Songs?

What inconsistent behaviour does this cause? is this inconsistent behaviour new with the Jarvis changes? did you have this inconsistent behaviour when the GUIViewStateWindowMusicSongs was used previously for the Files view?

[DaveBlake]

@Jeron is still sounds that you are angry and offended by me. I can only apologise again, and assure you that you misunderstood my reply on Git. 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 understand your motivation for needing to move this to the forum now, but I don't feel like I am taken very seriously by being told I am basically cluttering Git

I understand entirely, but I was actually concerned that my reply was likely to be seen as "clutter". I had been told in another thread that my contribution was "Spam", and yes I was offended!! I readily engage in discussion, I believe it makes for good design, and take what people have to say seriously, senior devs and users alike.

[DaveBlake]

@jjd_uk thanks for the clear post!

It is entirely possible that my fix restoring the broken file view display of tag data is poorly implemented. And let's be clear this facility was not removed, all the scanning still happened, it was just the display of the resuts that was broken. If it is the implementation that is causing issues for skinners then can we look at improving it.

But I still really don't understand those here that want to remove useful functionality.

[jjd-uk]

I understand entirely, but I was actually concerned that my reply was likely to be seen as "clutter". I had been told in another thread that my contribution was "Spam", and yes I was offended!! I readily engage in discussion, I believe it makes for good design, and take what people have to say seriously, senior devs and users alike.

As an attempt to clear this up.

Discussion directly relevant to the changes contained in the PR is ok on Github, but always be mindful that every Team member or anyone just watching the repo will be getting a notification email for every comment made. If the comments drift off topic or turn into an extended discussion generating a lot of notifications then that can annoy people, so you may get the comment from someone along the the lines of "please take the discussion to the forum". It's a balancing act sometimes of keeping comments with the code changes but trying not annoy people by generating what they view as spam filling up their inbox, and it's something none of us get right a 100% of the time.

So a few back and forth comments is fine, a number of comments over an extended period is also probably fine, a lively discussion with 10 or more comments in the space of an hour is probably not ok.

[Koying]

Seems like Microsoft disagree with you.

Oh look I can set content type on my folders

The major difference is that Microsoft does *not* have a library, so their only choice is indeed to mix both kind of views.
As Kodi *does have* both kind of views, it makes no sense to me to make them similar.

Take an actual music player like MediaMonkey, you just *don't* have any kind of file view, just library.

The goal of a library is specifically to avoid to make FS-based organisation, but metadata-based organisation, and that's what make Kodi different than VLC.
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.

P.S. As I said, I don't use Music much, 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...

[jjd-uk]

It is entirely possible that my fix restoring the broken file view display of tag data is poorly implemented. And let's be clear this facility was not removed, all the scanning still happened, it was just the display of the resuts that was broken. If it is the implementation that is causing issues for skinners then can we look at improving it.

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.