2015-10-09, 18:00
2015-10-09, 18:15
(2015-10-09, 18:00)Fist Wrote:(2015-10-09, 17:10)DaveBlake Wrote: Yes, in 16 file view the tags are still read from the files, had a look in debug. But the display format has changed, and now there are no sort options either. So is it a Confluence change?
I'm using Mimic skin. It's the same there.
So not skin, I thought not almost as soon as I posted it, but thanks for confirming.
I am guessing it has something to do with the sort and label changes that have gone on in Jarvis, I just don't know much about that part (yet).
Edit: It would seem that Evilhamster is right (as he often is), PR8011 removed GUIWindowMusicSongs.cpp, and this was providing sorting (I think). Now we use CGUIViewStateWindowMusicNav for all the music file views, and it doesn't recognise when we get to track/song level and have data to sort by. Just hours ago PR8184 "Align video and music sort types on file listings to each other" has added file date and size sorting, but we have more than that in Isengard.
Note (tagged) music files can be sorted in ways that video files can't because we have artist, song name, album etc. data. To deminish music functionality to match video file limitations is a mistake, we need to fix this inadvertant change.
2015-10-09, 19:33
Dave:
It actually is 8011, if you would like to verify it:
git reset --hard 2e3a86fec4400f98ca320016da5c9399fc27f5a8 (after 8011 was applied)
For me this produce a build where it lists the filenames and no sort options in music file mode.
git reset --hard 8f5435d430ca4bb48aa4877c4be3bf7ea81bfcce (commit before 8011)
For me this produce a build where the sort options in file mode works and music files are listed by their tags.
This also has the effect that users that store their music in cue/flac format will have some issues in file mode, since we filter out the cue/flac file and create fileitems based on the contents of the cue file we know get X items with the same filename (X being the number of songs in the cue file).
It actually is 8011, if you would like to verify it:
git reset --hard 2e3a86fec4400f98ca320016da5c9399fc27f5a8 (after 8011 was applied)
For me this produce a build where it lists the filenames and no sort options in music file mode.
git reset --hard 8f5435d430ca4bb48aa4877c4be3bf7ea81bfcce (commit before 8011)
For me this produce a build where the sort options in file mode works and music files are listed by their tags.
This also has the effect that users that store their music in cue/flac format will have some issues in file mode, since we filter out the cue/flac file and create fileitems based on the contents of the cue file we know get X items with the same filename (X being the number of songs in the cue file).
2015-10-09, 20:03
(2015-10-09, 19:33)evilhamster Wrote: Dave:Yeap you are right
It actually is 8011, if you would like to verify it:

I think the fix goes into GUIViewStateWindowMusicNav.cpp creator but have not got further than that. I am on an under powered laptop (until I do some shopping), so builds take forever! Get in there and fix it for us if you have a moment

2015-10-10, 03:06
(2015-10-09, 01:16)scott967 Wrote:(2015-10-08, 19:14)DaveBlake Wrote: Of course what you really want is alias name capability. Evilhamster and I are plotting such a possibilty
Thanks for looking at this. I can try with FLAC too and see if there is a difference. You are right that I need alias and I have used the existing used tags to workaround. 95% of files, I use album artist for the alias (list all variants as album artists) and artist is the "most used" variant (I note that musicbrainz is inconsistent in how they handle artists names that are not in a latin variant script). I use musicbrainz artist id (not album artist) and that seems to work OK in Isengard and the mods so far in Jarvis (with "prefer online info off" as I don't want musicbrainz' opinion on the "correct" name variant). For the other 5%, these are in "various artist" compilations (typically soundtracks/"OST") and in this case I place the name variants in the artist tag but still the single MB artist id tag.. That's what I was checking in this test file.
Will check again with FLAC and also read out the actual db contents.
OK I built some FLAC files to check out. All files were part of a single album with ALBUMARTIST Various Artists and Kodi log reported that the album was a compilation due to album artist Various Artists and no overlapping tracks.
First test was with
ARTIST A
ARTIST B
tags
This gave song strArtist A / B
song artist had entries for both A and B
artist had entries for both A and B
Second test was with added single
MUSICBRAINZ_ARTISTID A
tag
This gave song strArtist A
song artist had entry for only A
artist had entry for only A
Third test was with added tags
ARTISTS A
ARTISTS B
This gave same results same as test 2
Fourth test was with added (second)
MUSICBRAINZ_ARTISTID with fake entry
This gave song strArtist A / B
song artist had entries for both A and B
artist had entry for both A and B
So conclusion is that if there are multiple artist entries and there is at least 1 artist MBID, you must add fake MBID for any artists as needed to get all the artists added to the database -- same performance as in Isengard without the fake MBIDs. I can do this but it doesn't seem like a step forward from Isengard. (as an aside, I tried to use the same MBID twice, but the second one seemed to be ignored or rejected. So then I used the faked one and that worked, though of course I get the fake one in the database but I'm not sure that causes a problem.)
scott s.
.
2015-10-10, 03:18
(2015-10-09, 12:20)jjd-uk Wrote:(2015-10-08, 12:13)zag Wrote: file mode should act exactly like other file modes such as movies and tvshows.
(2015-10-09, 07:59)DaveBlake Wrote: And I don't get the "file view should be just files not tag data", OK video fileview is like that but video doesn't have tag data!! Have an option not to scan on the fly (be just like video), but keep the functionality.
That's just not true, in videos there is also the possibility to use metadata in the Files view as well so it's not just a file name view, this is what "Replace names with library titles" is, so using tags in the Music Files view is the same kind of functionality.
I will object strongly to any formal attempt to remove reading of tags for music from Files view as it's something I too rely a lot on.
I note also for music video in file view with "replace names with library titles" you get the tile and artist available for the view. And taglib already can get tags out of mp4 files so we could more with video files if we wanted to. Or you can add music video as a music source and in Isengard you get artist - title in music file view without having to create nfo files for every MV file (Jarvis just gives the filename).
scott s.
.
2015-10-10, 11:12
(2015-10-10, 03:06)scott967 Wrote: So conclusion is that if there are multiple artist entries and there is at least 1 artist MBID, you must add fake MBID for any artists as needed to get all the artists added to the database -- same performance as in Isengard without the fake MBIDs. I can do this but it doesn't seem like a step forward from Isengard. (as an aside, I tried to use the same MBID twice, but the second one seemed to be ignored or rejected. So then I used the faked one and that worked, though of course I get the fake one in the database but I'm not sure that causes a problem.)Thanks for further testing, your observations are correct and I have repeated them now. My first test attempt I messed up the MBID tag. Fake MBID would be a temp work around, as you have found, but I would rather fix the code to handle this (until we eventually have artist alias handling). Raised PR8191 to do just that.
The current processing in Jarvis (alpha) covers the possibilty of more MBID than artists (and fixes a previous issue) but not more artists than MBID, and current lack of alias support provides the situation where you may want to do that.
Edit: unfortunately my friend Evilhamster, who did the original ARTISTS tag work, is not happy with my fix. I respect his view and concerns, so would like some additional input from other devs and users (I'm sure he would too).
Are we in fact happier to take the simple approach, currently in Jarvis, that once you have artist MBIDs any extra artist names in ARTIST tags (without matching MBID) get ignored?
2015-10-10, 12:18
(2015-10-09, 19:33)evilhamster Wrote: Dave:Thanks Evilhamster for all that tedious building to validate which PR caused the problem.
It actually is 8011, if you would like to verify it:
git reset --hard 2e3a86fec4400f98ca320016da5c9399fc27f5a8 (after 8011 was applied)
For me this produce a build where it lists the filenames and no sort options in music file mode.
git reset --hard 8f5435d430ca4bb48aa4877c4be3bf7ea81bfcce (commit before 8011)
For me this produce a build where the sort options in file mode works and music files are listed by their tags.
This also has the effect that users that store their music in cue/flac format will have some issues in file mode, since we filter out the cue/flac file and create fileitems based on the contents of the cue file we know get X items with the same filename (X being the number of songs in the cue file).
Recently merged PR8184 has restored some of the sort criteria (filename, size, date).
I am looking at how we get the other tag data e.g. artist, album etc. as sort criteria if we have it, and restore the choice of display to include media info. PR forth comming soon. Where we have the data it seems a mistake not to be able to see and use it.
2015-10-10, 19:03
Some images to help show how PR8011 has changed the music file view.
With Isengard we have this

Note that we can see the artist name in the left hand list, and because this is Media Info view we see more info under the cover image on the right.
But with Jarvis, after PR8011, we have this

Only filename is shown, and view type choice limited to List/Big List/Thumbnail (List view shown).
The tag data is still automatically retreived from the music files as they are navigated to, but no longer shown on the display.
I am looking at how the tag data display can be restored, but other than adding sortbyartist to all levels of music file navigation (something I am sure the "make it like video" people will reject out of hand) I am having difficulties. I also have not discovered how to extend the choice of view types available to include media info etc. I am still investigating, but hope there is someone out there that understands this better than I do.
But I am sure that users will be delighted to know that this lack of displayed information makes this music display consistent with video file viewing.
With Isengard we have this

Note that we can see the artist name in the left hand list, and because this is Media Info view we see more info under the cover image on the right.
But with Jarvis, after PR8011, we have this

Only filename is shown, and view type choice limited to List/Big List/Thumbnail (List view shown).
The tag data is still automatically retreived from the music files as they are navigated to, but no longer shown on the display.
I am looking at how the tag data display can be restored, but other than adding sortbyartist to all levels of music file navigation (something I am sure the "make it like video" people will reject out of hand) I am having difficulties. I also have not discovered how to extend the choice of view types available to include media info etc. I am still investigating, but hope there is someone out there that understands this better than I do.
But I am sure that users will be delighted to know that this lack of displayed information makes this music display consistent with video file viewing.

2015-10-11, 01:45
Just a remark. I think a file view which is not showing files is really a library view. That is just a general statement not aimed at what's going on or even video.
I feel like we're really suffering from fragmentation here.
If I had anything to say, file view should only be very basic. And library should have all the sorting and meta data.
Like, why does file list for songs have a sort option that sorts by listeners. But library mode has not. It's just so random.
Just saying, but I guess we're really locked into the status quo and probably can't do a clean up anywhere.
I feel like we're really suffering from fragmentation here.
If I had anything to say, file view should only be very basic. And library should have all the sorting and meta data.
Like, why does file list for songs have a sort option that sorts by listeners. But library mode has not. It's just so random.
Just saying, but I guess we're really locked into the status quo and probably can't do a clean up anywhere.
2015-10-11, 11:03
The only status quo is that library needs to be fixed so users can use it.
But there will always be users that does use file mode for many reason, like removable devices, or (most often) a particular organization of their media that they can not have with library.
On use case that I have and many others since asked in Yatse is Folder : Genre\Artist\MediaType(Albums/Single/Compilation\Album\song.
Currently genre is not even in the main confluence screen, and I'm pretty sure many users like me want to listen to a genre depending on their mood.
The thing is as repeated, what are the users needs
But there will always be users that does use file mode for many reason, like removable devices, or (most often) a particular organization of their media that they can not have with library.
On use case that I have and many others since asked in Yatse is Folder : Genre\Artist\MediaType(Albums/Single/Compilation\Album\song.
Currently genre is not even in the main confluence screen, and I'm pretty sure many users like me want to listen to a genre depending on their mood.
The thing is as repeated, what are the users needs

2015-10-11, 11:11
(2015-10-11, 11:03)Tolriq Wrote: The only status quo is that library needs to be fixed so users can use it.
But there will always be users that does use file mode for many reason, like removable devices, or (most often) a particular organization of their media that they can not have with library.
On use case that I have and many others since asked in Yatse is Folder : Genre\Artist\MediaType(Albums/Single/Compilation\Album\song.
Currently genre is not even in the main confluence screen, and I'm pretty sure many users like me want to listen to a genre depending on their mood.
The thing is as repeated, what are the users needs
I agree, that there are things to do. But doing a battle on two fronts is just stupid to me (excuse my choice of language)
The Genre\Artist\MediaType(Albums/Single/Compilation\Album\song) use case you mentioned, how is it possible to solve with the file view?
I don't think it is. And yes we could do this with the library view.
Basically the file view is only there to check out if there is something that got not picked up correctly by the library view.
2015-10-11, 11:26
(2015-10-11, 11:11)Razze Wrote:(2015-10-11, 11:03)Tolriq Wrote: The only status quo is that library needs to be fixed so users can use it.
But there will always be users that does use file mode for many reason, like removable devices, or (most often) a particular organization of their media that they can not have with library.
On use case that I have and many others since asked in Yatse is Folder : Genre\Artist\MediaType(Albums/Single/Compilation\Album\song.
Currently genre is not even in the main confluence screen, and I'm pretty sure many users like me want to listen to a genre depending on their mood.
The thing is as repeated, what are the users needs
I agree, that there are things to do. But doing a battle on two fronts is just stupid to me (excuse my choice of language)
The Genre\Artist\MediaType(Albums/Single/Compilation\Album\song) use case you mentioned, how is it possible to solve with the file view?
I don't think it is. And yes we could do this with the library view.
Basically the file view is only there to check out if there is something that got not picked up correctly by the library view.
The File View is there for when you don't want to import all your music into a single database, or it's not ready to be imported into your main library.
Let's just say: you have music on a USB drive; music on your laptop you've just downloaded; plus a big folder of single tracks you haven't got around to tagging. That's just about everyone, right?
Apple doesn't get this, but Kodi does, or did. That's why we gravitated towards it and not iTunes.
It's always been fine for the almost ten years I've been using it. Stripping that functionality hasn't benefited anyone.
2015-10-11, 11:53
Bad click : Post to delete (Seems I have all the buttons to delete my post but no permission to do it)
2015-10-11, 11:54
(2015-10-11, 11:11)Razze Wrote: I agree, that there are things to do. But doing a battle on two fronts is just stupid to me (excuse my choice of language)
The Genre\Artist\MediaType(Albums/Single/Compilation\Album\song) use case you mentioned, how is it possible to solve with the file view?
I don't think it is. And yes we could do this with the library view.
Basically the file view is only there to check out if there is something that got not picked up correctly by the library view.
File view is a major use of Kodi, I still have stats for you if you want.
And this case is what file mode is made... If you have ordered your media like that (And it's the case of many users).
There's nothing to do, just to display the tags when reaching the last folder to have details on the songs.
So as I said there's nothing to do on File mode just to restore the previous functionnality so that users are not loss and angry after next version.
This is not stupid as I never said fight on 2 things, I said since the beginning fix the Library.
A patch have broken a function too early this needs to be fixed, this have nothing to do with a new front, it's a normal way of acting, there's a unseen regression, let's fix it.