Fix content types. Fixes #16392

[razzeee]

@phil65 wished for some fixes for content types.

Some of the music problems are oversight of the now infamous #8011
Everything is pretty self explanatory, we're just making sure not to always set "files" and fall back to "" if it really should be "".

[phil65]

Thx.
Quick roundup for @ronie: This makes sure that the music library root for example does not return "files" as a content type. That way it is in line with movie section and can help skinners to choose the proper viewtype for that type of content.

In the long-term I would prefer to set all those paths to content type "nodes" or something similar instead of "", but that´s ofc not related to this PR.

[DaveTBlake]

Might want to check out this ticket too http://trac.kodi.tv/ticket/16392 possibly related.
At least @jeroenpardon may like to know it about this.

[razzeee]

Yep, just seen that. Should also be fixed, by what I did here.

[ronie]

@phil65 thx, haven't tested it yet, but description looks good.

[phil65]

@razzeee I now tested and everything looks fine now. Thx for fixing this.

[phil65]

I think I was too quick here. Content type for library root --> files is correctly set to "files", but library root --> files --> some subfolder switches back to "" instead of "files". It should stay "files" for all subfolders in files section.

[razzeee]

Will look at that later. Can you check if video also has this bug?

Edit: Fixed everything, video was fine all along

[razzeee]

Found another problem with videos, that now should be gone.

[razzeee]

Would like to merge this.

jenkins build this please

[DaveTBlake]

Before we merge this can we be sure it hasn't broken file view of intrinsic tag data again.

I am doing some combined testing of recent changes, so it could be something else, but I have seen some problems. So hold off until I have nailed this down please.

[razzeee]

Sure, that's why we ask before merging.

[DaveTBlake]

My testing has been inconclusive I'm afraid. Frustrating!!

There are times when going back to a music souce in file view, although tags were scanned on first visit, it does not get scanned and is therefore unable to show tag data. But I have been unable to tie the behaviour to this change, nor to repeat it consistently. It could be down to list caching I guess.

I would prefer someone else gives file view a good testing, may be @jjd_uk if he is back, but not going to press if you want to continue.

[phil65]

I would like to have this pulled in since it fixes some obvious bugs.

[MartijnKaijser]

Yep. Get it merged and see what's left to fix.

[guidosarducci]

FYI, this change does not resolve a skin problem I have seen since first running Jarvis, where VideoPlayer.Content() categorizes my library TV shows as "files" instead of "episodes".

Non-library videos identify as "files" and library movies identify as "movies", but I haven't been able to check "livetv" or "musicvideos" content.

This is with a build from recent commit 6bcc4db, which includes this merge, running on android AFTV v1. All my userdata/libraries were copied from Isengard, where this all works fine.