Announce: Material Skin

[slartibartfast]

Sorry, where do you add it from? Were you adding it from Material skin? I'm not sure what the above is in reference to. How do you have no way of knowing what a track is?

Can you use a command-line? Do you have curl installed? If so, what does the following return (replace lms-server-address with the IP or hostname of your LMS server):

curl http://lms-server-address:9000/jsonrpc.js --data '{"id":1,"method":"slim.request","params":["",["artists",0,100,"role_id:COMPOSER"]]}'

This is the command that Material will send for "artists" using the "COMPOSER" tag.

I was adding the track from the composer list in Material Skin. Since clicking on the composer produces no results I don't know what is listed under that composer. If I click on the three dots at the right of the composer name and choose play next then the tracks are added to the queue at which point I can see what they are. I'll try the command and report back.

Sent from my SM-G900F using Tapatalk

[slartibartfast]

Sorry, where do you add it from? Were you adding it from Material skin? I'm not sure what the above is in reference to. How do you have no way of knowing what a track is?

Can you use a command-line? Do you have curl installed? If so, what does the following return (replace lms-server-address with the IP or hostname of your LMS server):

curl http://lms-server-address:9000/jsonrpc.js --data '{"id":1,"method":"slim.request","params":["",["artists",0,100,"role_id:COMPOSER"]]}'

This is the command that Material will send for "artists" using the "COMPOSER" tag.

That command produces a list of composers which I assume is correct and I do see a list of composers. The issue is that clicking on a composer in that list does not drill down to the albums that feature that composer.

Sent from my SM-G900F using Tapatalk

[cpd73]

That command produces a list of composers which I assume is correct and I do see a list of composers. The issue is that clicking on a composer in that list does not drill down to the albums that feature that composer.

Ah! I can see this now! Well for some entries, the browsing works, other not. Looks liker where artist=composer it works, otherwise not. I look into this. Sorry, I was under the impression that nothing was showing under the list of Composers.

[slartibartfast]

Ah! I can see this now! Well for some entries, the browsing works, other not. Looks liker where artist=composer it works, otherwise not. I look into this. Sorry, I was under the impression that nothing was showing under the list of Composers.

Yes I can confirm this. The vast majority of composers in my list are not the same as the artist. The first one I tried where the name is exactly the same I do get a list of albums. Good detective work.

Sent from my SM-G900F using Tapatalk

[cpd73]

Yes I can confirm this. The vast majority of composers in my list are not the same as the artist. The first one I tried where the name is exactly the same I do get a list of albums. Good detective work.

Yeah, I know the cause. When listing composers there's a "role_id:COMPOSER" set, but this is not the used when asking for albums by a 'composer' - so the location fails. I've fixed this for the next release. The fix for this also make it so that if you have an album artist that has 1 track on another album (e.g. a Various Artists) album, then only that 1 track is shown. This mirrors what I see in the default web UI. However, I like seeing all tracks - so I'll make this bit optional (or use a server setting, if I find a corresponding one - [EDIT] In fact there is a setting in the server for this, so I'll use and respect that).

0.0.8 will have this fixed.

[mherger]

Announce: Material Skin

> But you see the same music. Its just the modes of browsing that would be
> different.

No, it's not the same music. I implemented library views because I
didn't want to see my kids' music, and they only wanted to see theirs.

> To filter the music would mean changing the library - and the skin does
> support virtual libraries.

You can expose a browse menu which is limited to a library view without
switching the library. Right now (0.0.7) I'm getting the kids music
right at the top of my "More" menu. Definitely what I had in mind when I
implemented this :-).

But this skin is your baby, not mine. I'm just trying to show the way I
am using LMS. And many users might have become accustomed to the way LMS
does things.

--

Michael

[cpd73]

> But you see the same music. Its just the modes of browsing that would be
> different.

No, it's not the same music. I implemented library views because I
didn't want to see my kids' music, and they only wanted to see theirs.

> To filter the music would mean changing the library - and the skin does
> support virtual libraries.

You can expose a browse menu which is limited to a library view without
switching the library. Right now (0.0.7) I'm getting the kids music
right at the top of my "More" menu. Definitely what I had in mind when I
implemented this :-)

The current 'Additional Browse Modes" ignores the library_id setting - I'll fix this for the next release. (And, yes, I know that if I'd used SlimBrowse for this, this would all come for free :-) ...but then I lose sorts, and meta-data...)

I can see your point of view. And I assume for your usage scenario you have (e.g.) "Michael's Music" mode, which is only shown on certain players. And, I can see why this would be nice on a hardware player - so as to limit the number of choices. But for a web UI I'm not 100% convinced on the need for separate views per player. This would mean that when your son, is in another room they cannot see their selection of music, only what is shown for the player in that room.

IMHO, the idea of a global library view makes more sense. Then your son simply sets that in his controller, and whichever room he's in / player he's using, he gets the same list of choices.

[mherger]

Announce: Material Skin

> IMHO, the idea of a global library view makes more sense. Then your son
> simply sets that in his controller, and whichever room he's in / player
> he's using, he gets the same list of choices.

I think we have two different use modes: in our household the kids have
their Radio. I have mine. They don't touch mine (dare you! :-)).
Therefore I am in favor of a menu being tied to a player rather than the
controller.

Your model is different (from what I understand): you want the library
to move with the controller from player to player. In that case I would
admit your approach makes more sense. It's like a user-profile, rather
than a device profile.

--

Michael

[bakker_be]

Just to add my 2 cents to the discussion regarding Player/Controller menus: to me it makes no sense to not have a per player implementation of the menus when you have more than one player!. There's only 1 URL for the LMS web GUI, be it material (http://LMS:9000/material) or default (http://LMS:9000), so what you see should always be defined on a player level.
Doing it this way in no way hinders the person with only one player, but adds enormous flexibility for the multi-player household.

[cpd73]

Just to add my 2 cents to the discussion regarding Player/Controller menus: to me it makes no sense to not have a per player implementation of the menus when you have more than one player!. There's only 1 URL for the LMS web GUI, be it material (http://LMS:9000/material) or default (http://LMS:9000), so what you see should always be defined on a player level.
Doing it this way in no way hinders the person with only one player, but adds enormous flexibility for the multi-player household.

First of all, let me state I am coming round to the idea that the list of browse modes should be fetched from the server - so this would be per player (as that's the way it works).

However, I fail to see why I would want different browse modes. I have 2 players, but with these I still want the same views (on the material UI). I can see the need for virtual libraries (so, my music, kids music, etc). But why would I want "Artists" upstairs, but not downstairs?

[bakker_be]

First of all, let me state I am coming round to the idea that the list of browse modes should be fetched from the server - so this would be per player (as that's the way it works).

However, I fail to see why I would want different browse modes. I have 2 players, but with these I still want the same views (on the material UI). I can see the need for virtual libraries (so, my music, kids music, etc). But why would I want "Artists" upstairs, but not downstairs?

For 1 person, you'd be absolutely right, but my daughter has her preferences for the player she uses most, which is in her room without any additional interface than either web GUI, my wife likewise for the player in her workshop, myself I quite often use "Random Album", whereas they never do. Limiting the GUI to each person's preferences makes it cleaner and clearer IMO, and since there are no real user profiles in LMS, that's only feasible when taking into account the individual players.

[mherger]

Announce: Material Skin

> kids music, etc). But why would I want "Artists" upstairs, but not
> downstairs?
Because my kids don't care about artists, they only care about the album
art :-)

--
--

Michael

[cpd73]

For 1 person, you'd be absolutely right, but my daughter has her preferences for the player she uses most, which is in her room without any additional interface than either web GUI, my wife likewise for the player in her workshop, myself I quite often use "Random Album", whereas they never do. Limiting the GUI to each person's preferences makes it cleaner and clearer IMO, and since there are no real user profiles in LMS, that's only feasible when taking into account the individual players.

But even here, its really per-person, not per-player. Its only per-player at the moment as this is what LMS supports, and (I assume) people use a specific player. But, in reality, what you want is a per-user setting. This could be accomplished by the material UI having a selection for the enabled views.

I still think for a device's UI - per player makes sense. For a multi-device controller (such as the web UI) then it should be per-user.

I'm torn between reading LMS's settings (which would be consistent with others, be per-player, but means changes when changing payer), or making the list of modes selectable in the material settings dialog (which would make them per-user)...

[cpd73]

> kids music, etc). But why would I want "Artists" upstairs, but not
> downstairs?
Because my kids don't care about artists, they only care about the album
art :-)

Yeah - your kids care, but the player does not => per-user setting, not per device.

[bakker_be]

But even here, its really per-person, not per-player. Its only per-player at the moment as this is what LMS supports, and (I assume) people use a specific player. But, in reality, what you want is a per-user setting. This could be accomplished by the material UI having a selection for the enabled views.

I still think for a device's UI - per player makes sense. For a multi-device controller (such as the web UI) then it should be per-user.

I'm torn between reading LMS's settings (which would be consistent with others, be per-player, but means changes when changing payer), or making the list of modes selectable in the material settings dialog (which would make them per-user)...

True, the need is per person, but as that's impossible in LMS, and generally speaking most players are single user (at least in my household), per player does the trick