Announce: Material Skin

[Ron F.]

Is this only with the 3.2 branch? Is master ok?

Yup, going back fixed it. I reset local to origin/master, erased the cache, and on both the Android APK and in Firefox on my laptop, the Browse pane is back to working normally! I have not checked for error msgs yet on the refresh, but it is working again.

[cpd73]

Yup, going back fixed it. I reset local to origin/master, erased the cache, and on both the Android APK and in Firefox on my laptop, the Browse pane is back to working normally! I have not checked for error msgs yet on the refresh, but it is working again.

3.2 branch should be fixed now.

[Ron F.]

3.2 branch should be fixed now.

I reset my local to origin/3.2, testing on Melodeon, Android APK, Brave and Firefox browsers, and I think the issue is fixed: the Browse pane is now rendered properly.

[sveninndh]

Material stores the setting in your browser's local storage. There you will find items sic as "lms-material::albums-grid"

Thanks for the tip, I find also:

"lms-material::album-grid"
"lms-material::artists-grid"
"lms-material::local-grid"
"lms-material:: other-grid"
"lms-material::music-grid"
"lms-material::favorites-grid"
"lms-material::browse-library-grid"
"lms-material::qobuz-grid"

Now of course I'm wondering where does the browser get the info from (album, artists, local, other, music, favorites, browse library and qobuz)?
If you compare the default skin with the material skin, you will see that this functionality does not yet exist in the default skin. There it is really a global switch whose current value is stored in a cookie. Local storage is not used at all.
From this I conclude that you also disliked the ugly behavior of a global grid/list switch and that you have therefore built in this distinction according to certain view types (album, artists, other, etc.).
As you yourself have already written, this does not work for plugins, or there is only one global switch per plugin, which is of course unsatisfactory for plugins such as Qobuz, Spotify or Tidal etc.
The question that now arises is whether it would be possible in some way to recognize which view type (album, artists, playlist, other) the currently displayed page is for each plugin.
If this is not evident for Material-Skin from the data it gets from the server, one might think about what the plugin developer can do to change that. For example, one could provide a translation list per plugin from which the material skin can be seen what type of view it is. Or you derive the view type from the icon name of the menu item.
But other methods would also be possible, in the end you choose the one that requires the least effort.
I'd be very interested in allowing what works for the default views in material skin for plugins as well. The operation of the overall system would then also be more consistent.
I'm also happy to help as much as I can.

I know, I used that as an example of an item that is placed there - and when/how this happens.

Ah ok, so it looks pretty bad for me to get an entry into this menu from a plugin.

I read through the item "07 Customization - Custom menu entries and actions" on the GitHub page of Material-Skin in the wiki and tried to conjure up some additional menu according to this guide and the file "material-skin/actions.json", but I'm probably doing something wrong, because nothing changes with or without this file.
Does this feature work at all?

[cpd73]

Now of course I'm wondering where does the browser get the info from (album, artists, local, other, music, favorites, browse library and qobuz)?

Material gets it from the first parameter of the JSONRPC request.

The question that now arises is whether it would be possible in some way to recognize which view type (album, artists, playlist, other) the currently displayed page is for each plugin.

Well if the response could indicate that the current view is a list of albums, artists, tracks, etc. then Material could use this to store the grid/list state.

Ah ok, so it looks pretty bad for me to get an entry into this menu from a plugin.

Well depends on what you want. I'm more than happy to make changes to accommodate plugin specific menu items here.

I read through the item "07 Customization - Custom menu entries and actions" on the GitHub page of Material-Skin in the wiki and tried to conjure up some additional menu according to this guide and the file "material-skin/actions.json", but I'm probably doing something wrong, because nothing changes with or without this file.
Does this feature work at all?

Yes the feature works, I've just checked. However, this is meant for user or system integrators - not really for plugins.

[Ron F.]

New Local Player Support

Looking at LMS-MATERIAL-APP:LocalPlayer.java, I see where the command line args are set for calling Termux/Squeezelite:

String[]{
"-M", "SqueezeLiteAndroid",
"-C", "5",
"-s", current.ip,
"-m", getTermuxMac(),
"-n", Settings.Global.getString(context.getContentResolv er(), "device_name")
}

I have been running squeezelite on my Android phones for quite a while now, starting/stopping it independently in a Termux terminal. I think a provision to do this for me makes the Material app even more ridiculously awesome. I do have a wish however, and that would be to have the option to define an alternate set of squeezelite args, possibly the simplest method would be a text file (maybe named .squeezelite.conf or something of the sort,) in the user's Termux home dir. I have been using a set of args that look like: -n Pixel-6a-Termux -m ab:cd:ef:12:34:57 -b 20480:34460 -r 48000:3000 -s 100.X.X.X. Actually, what I think is most important is to limit the sample rate to 48000.

Note: I have not seen this yet using Material's support for squeezelite, but I have seen a race condition occur occasionally when starting squeezelite myself, where it immediately crashed because the connection to Android audio was not quite ready yet. I solved this by starting pulseaudio myself before then starting squeezelite. I had written a Termux sh script to take care of this.

[cpd73]

what I think is most important is to limit the sample rate to 48000.

Out of curiosity,why is this required? I have no high-sample rate files, so never something I've used.

Note: I have not seen this yet using Material's support for squeezelite, but I have seen a race condition occur occasionally when starting squeezelite myself, where it immediately crashed because the connection to Android audio was not quite ready yet. I solved this by starting pulseaudio myself before then starting squeezelite. I had written a Termux sh script to take care of this.

Would be interested to know if this pulseaudio issue is still present.

[Ron F.]

Out of curiosity,why is this required? I have no high-sample rate files, so never something I've used.

Would be interested to know if this pulseaudio issue is still present.

I don't know if the pulseaudio issue is still present or not; I will have to do some testing over the next day or two to see if it happens.

Regarding the sample rate: I play material at 96000 on my main system, but streaming this to my Android device is a waste, where the native sampling rate is limited to 48000. It also results in dropouts when streaming over my VPN when traveling.

Edit: also, I think it is better to do the resampling to 48000 on my home server, than doing it on my phone!

[cpd73]

Regarding the sample rate: I play material at 96000 on my main system, but streaming this to my Android device is a waste, where the native sampling rate is limited to 48000. It also results in dropouts when streaming over my VPN when traveling.!

OK. Perhaps I'll just add a text box for other options. I've raised an issue on github https://github.com/CDrummond/lms-material-app/issues/7

[Ron F.]

OK. Perhaps I'll just add a text box for other options. I've raised an issue on github https://github.com/CDrummond/lms-material-app/issues/7

Sounds good, I will test whenever you have it ready.

[sveninndh]

Material gets it from the first parameter of the JSONRPC request.

I see the requests, but it feels like there are hundreds per page.
You say it is the first parameter of the JSONRPC request. You mean the response of the JSONRPC request or do I misunderstand something there.
The parameter of a JSONRPC request ultimately has to come from somewhere, so I'm assuming it came from a response to a previously executed request.
Unfortunately, I have to approach it a bit, as I only have rudimentary knowledge of this technology.

Well if the response could indicate that the current view is a list of albums, artists, tracks, etc. then Material could use this to store the grid/list state.

That sounds good.

Yes the feature works, I've just checked. However, this is meant for user or system integrators - not really for plugins.

Of course, I need that more for myself personally.
But I am happy, it works now, the problem was sitting in front of keyboard.
A great feature, thanks, this is exactly what I wanted and more.

[cpd73]

You say it is the first parameter of the JSONRPC request.

Material remembers the command used to build the currently displayed list. If then uses the first parameter of this as the list/grid toggle. Anyhow, that's all implementation specific and should be of no concern to you.

[cpd73]

3.1.4 release, changes:

1. Fix Years browsing on non-touch devices.

[d6jg]

cpd73 mherger I am tagging you both on this I have just discovered a scenario that Material doesn't deal with very well but is fine in Default but which needs addressing as it could cause significant problems to unwary users going forward.

Apologies for the detail here but I need to explain properly.

I am trialling a WiiM Mini with philippe_44 's UPnP Bridge. It works with a recent version 2.1.11.

This morning Material told me that I had plugin updates available - Qobuz 2.8 and UPnP/DLNA Bridge 2.1.13.

I wanted Qobuz but didn't want to apply UPnP/DLNA Bridge 2.1.13 until I had tested it but there is no way to do this inside Material - its all or nothing as far as plugin updates are concerned.

Obviously I know to jump into Default to do what I needed to do but as we move towards Material as the de-facto default skin new users aren't going to be sufficiently savvy.

What I am saying is that I think that within Material there needs to be a way of selecting which Plugins you want to install rather than an all or nothing.

Nothing to do with Material but it would be really helpful if there was a mechanism to roll back to previous plugin version (rathe rthan manual install) when you find that a new version doesn't work which is the case with UPnP/DLNA Bridge 2.1.13!

[slartibartfast]

cpd73 mherger I am tagging you both on this I have just discovered a scenario that Material doesn't deal with very well but is fine in Default but which needs addressing as it could cause significant problems to unwary users going forward.

Apologies for the detail here but I need to explain properly.

I am trialling a WiiM Mini with philippe_44 's UPnP Bridge. It works with a recent version 2.1.11.

This morning Material told me that I had plugin updates available - Qobuz 2.8 and UPnP/DLNA Bridge 2.1.13.

I wanted Qobuz but didn't want to apply UPnP/DLNA Bridge 2.1.13 until I had tested it but there is no way to do this inside Material - its all or nothing as far as plugin updates are concerned.

Obviously I know to jump into Default to do what I needed to do but as we move towards Material as the de-facto default skin new users aren't going to be sufficiently savvy.

What I am saying is that I think that within Material there needs to be a way of selecting which Plugins you want to install rather than an all or nothing.

Nothing to do with Material but it would be really helpful if there was a mechanism to roll back to previous plugin version (rathe rthan manual install) when you find that a new version doesn't work which is the case with UPnP/DLNA Bridge 2.1.13!

There is a way to deselect plugin updates in Material skin but it has to be done via
Settings/Server/Plugins Just uncheck the relevant box.