[BatterPudding]

Hooray, some progress. My thoughts:

1. Now sorting by the basic file properties (File, name, Date, Size). I'm struggling to think of an instance Size would useful.
2. Can't sort by Track, Artist, Title. The useful fields.
3. Still displaying the literal file name and extension.
4. Not obeying the Track Naming Template in Settings/Music/File Lists

I understand this way would the literal interpretation of "File View" if by that you meant how it would be displayed if viewed from a command prompt or Windows 3.1, but I think given this is the Swiss army knife of media players we might err towards being useful to music lovers rather than simply placate some kind of programming autism.

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.

It would also avoid many of the screams you will cause otherwise...

[Fist]

Hooray, some progress. My thoughts:

1. Now sorting by the basic file properties (File, name, Date, Size). I'm struggling to think of an instance Size would useful.
2. Can't sort by Track, Artist, Title. The useful fields.
3. Still displaying the literal file name and extension.
4. Not obeying the Track Naming Template in Settings/Music/File Lists

I understand this way would the literal interpretation of "File View" if by that you meant how it would be displayed if viewed from a command prompt or Windows 3.1, but I think given this is the Swiss army knife of media players we might err towards being useful to music lovers rather than simply placate some kind of programming autism.

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.

It would also avoid many of the screams you will cause otherwise...

Exactly. Displaying only the least useful file properties because that's what typing DIR would give you seems like being belligerent for the sake of it.

[Fist]

No change in today's build. Was the rollback meant to have happened?

[DaveBlake]

No change in today's build. Was the rollback meant to have happened?

No, there will be no "rollback" as there are reasons to keep many aspects of PR8011.

But there will be changes made to restore the file view functionality (maybe even improve it a bit at the same time). I have changed the code and raised a pull request (PR8205) to have that merged into Javis master. Now it is down to the dev team members to check and approve what I have done, or ask me to change it some more. When they are happy one of them will merge it. Before that there may be a Jenkins build that you can test, but again that needs someone from the dev team to build that.

I would love you to test out my work, but I'm afraid I don't have the authority to facilitate it.

[Fist]

No change in today's build. Was the rollback meant to have happened?

No, there will be no "rollback" as there are reasons to keep many aspects of PR8011.

But there will be changes made to restore the file view functionality (maybe even improve it a bit at the same time). I have changed the code and raised a pull request (PR8205) to have that merged into Javis master. Now it is down to the dev team members to check and approve what I have done, or ask me to change it some more. When they are happy one of them will merge it. Before that there may be a Jenkins build that you can test, but again that needs someone from the dev team to build that.

I would love you to test out my work, but I'm afraid I don't have the authority to facilitate it.

Good on you for doing all this. I know it's something of a thankless task. I feel a bit like a whinging freeloader here but for what it's worth, I for one, appreciate you donating your time, and I'm sure when the masses arrive there'll be many more who'll prefer it your way than how it is currently.

I'll keep an eye on the nightlies and wait for the pull to come through before chiming in again!

Thanks

[jjd-uk]

No change in today's build. Was the rollback meant to have happened?

Was that your comment on the github PR? If so then did you compile your own build?

[ironic_monkey]

revert revert revert. eventually we will reach nirvana - square 1. oh wouldn't it be awesome…

[DaveBlake]

Fist, and any other interested people, PR8205 has now been merged so my attempt to restore the file view functionality (lost with PR8011) should be in the nightlies. Feedback welcome.

On a related topic: PR8159 has changed the format of what is displayed in the music library view. There is post merge discussion of ways this could be modified futher, a few of us are not happy with some of the consequences. In particular when you sort album view by album (with default settings and Confluence) you get album title on both sides of this list. Could be good to review these format changes - both file and library - together.

[Fist]

Fist, and any other interested people, PR8205 has now been merged so my attempt to restore the file view functionality (lost with PR8011) should be in the nightlies. Feedback welcome.

On a related topic: PR8159 has changed the format of what is displayed in the music library view. There is post merge discussion of ways this could be modified futher, a few of us are not happy with some of the consequences. In particular when you sort album view by album (with default settings and Confluence) you get album title on both sides of this list. Could be good to review these format changes - both file and library - together.

Great work, Dave.

Had a quick look just now. I tested it with two skins: Confluence and Mimic.

Here are my initial thoughts:

1. In terms of restoring the annoyance of not being able to sort by ascending track order: fixed. It appears tags are being read and interpreted correctly. The rest is a bonus.

2. Mimic skin can only sort in Ascending order, but that's a problem with the skin. Confluence is fine.

3. Haven't had a chance to check how Isengard did it, but I notice the default sort is by name, and this is inherited through the folders to the track listing. If you want albums sorted by track order, you have to sort them individually. I would be inclined, if it's not a pain, to get this down to a granular level, to default to name for folders, and track for files. I think that would be a logical improvement.

Edit: seems to do this now. Either a change in the next nightly or I was doing something wrong.

4. Some of the more esoteric file sorts now disregard the File Naming Template specified in the System/Music/File Lists, with the bias towards the basis of the sort. I don't know how I feel about this. Probably a good thing, but it is breaking consistency. If you were to leave out the details in the sort, I guess it might be confusing. It's not something I'd complain about either way.

Edit: Had a bit more of a play around. Further thoughts on 4. above

Fine with breaking the Settings/File Naming Template but it would be more visually appealing if:

1. In Artist/Year needs a space between Artist and opening bracket. Should sort by Artist, then year, then title. Track number would be irrelevant.

2. In Title, for the sake of symmetry, preferable on the eyes to list Artist first. Obviously, doesn't matter in compilations...

3. In Album, same again. List Album, Artist, then title or Album, Artist, Track Number, Title. Sort order should be Album, then track number.

4. In Artist, display track number. Obey file naming template, so default display would be Track, Artist, Title.

5. In Duration, as above.

6. In Year, display Artist, then title.

Once again, many thanks!

[scott967]

PR:8191

With respect to this PR which seems to be going nowhere:

1. It seems to me the logical concept is that [artists] should be a tuple of [str_artistname:MBID] with the possibility of a null entry for MBID. I guess there is no way to do that with current tag specs so we have the problem of 2 tags, [artists] and [artists_MBID] with an implied one to one correspondence between the two tags. This can work if there is defined a null MBID, which I think is the best solution. Another possibility is to allow MBID to be non-unique. Of course that causes a problem if the setting "prefer online information" is used. If the artists - artists_MBID relation is handled this way the logic would result in an error case when the cardinality of [artists] <> [artists_MBID] (and the same can be said for [album_artists] obviously). I don't have a particular idea of how the error should be resolved (would be nice at least to log it to Kodi.log).

2. Now as to why there is a possible need for the null/non-unique MBID besides the logic, you are right that it is an alias problem. For many East Asian performers, there can be four or more common ways the performer is referenced. I know Musicbrainz has a style guide for the primary name, but in practical terms it is only sometimes followed. And for other scrapers which aren't MBID-driven, using the correct name string is needed (for example, add-on "artist slideshow" uses artist name string to query Last.FM api). There also is a problem when the performer uses names written in various scripts, other than Latin-1. Trying to edit data or enter search strings in Kodi when keyboard is set to eg Latin-1 is difficult. Plus the user has to be able to mentally translate the performer name. So in my use case, I need Kodi to be able to display and treat alias names in an analogous manner as the MB preferred name.

scott s.
.

[Martijn]

@DaveBlake
Since a while my log is filled with error while scanning music files. Any chance you could take a look at it and maybe have an idea where it fails?
http://xbmclogs.com/pc8apt2xz

[DaveBlake]

@DaveBlake
Since a while my log is filled with error while scanning music files. Any chance you could take a look at it and maybe have an idea where it fails?
http://xbmclogs.com/pc8apt2xz

Had a quick look. You are getting unrecognised tag messages because your files have ID3 tags that Kodi doesn't process. That makes sense but isn't a scanning problem. The rest including the error seems to be scraper related, and sorry that is not my field. Things like "Could not find scraper function CreateArtistSearchUrl", I suggest you ask someone that works on the Universal scraper.

Edit: well it seems that the scraper errors could have been my fault! PR8287 should fix if one of the dev team will build it.

[jjd-uk]

I think I've been able to prove that the CreateArtistSearchUrl errors seem to date back to at least Helix.

Dave if you are willing to dig deeper then you need a bunch of singles to replicate with the files only tagged with the Artist and Track title, so:

1. There is no album artist
2. There is no album set
3. There is no track info

I have no idea how this works in code, but it seems strange to me that if there is no album info in the tags then why would the universal album scraper even be called?

[Razze]

It might also be a new scraper version or did you test Isengard with the old scraper? We should check that first, just to be sure. https://github.com/xbmc/repo-scrapers/bl...versal.xml
I think it's unlikely, but who know.

[jjd-uk]

I did a clean Isengard install, so everything was done from scratch, and I think I saw the scraper updating when first starting the new 15.2 install, the same with the 14.2 Helix install as well, and again I think I saw the scraper update.