Announce: Material Skin

[cpd73]

I'll add a work-around for splitting "A, B" - this should resolve the above issue. However, if you do have "A,X, Y and Z" as above then this will not work-around this in that case (as I check the number of (e.g.) "composer" name strings matches the number of "compose_ids" that LMS also sends)

[mherger]

This might partially be an LMS issue. Material asks LMS for the list of composers. In the status message (used for the queue) this is returned as "A,B" (no space) - and this is how Material expects such lists to be composed (so that "A,X, Y and Z" splits into "A" and "X, Y and Z"). But when listing the album tracks LMS returns the composer as "A, B" (so Material does not split). Now if composer==artist then Material does not show this, to prevent duplication. So, in the queue case the fist composer = artist, so is not shown, but in browse composer!=artist so is shown.

Could you please provide query & response, and the file's raw metadata (as reported in the More Info trackinfo menu)? Maybe we can take this to a GitHub issue.

[audiomuze]

Thanks, I can recreate the issue with these tags.

p.s. I notice it looks like you are using KDE/Plasma - same here

I am indeed.

Now if composer==artist then Material does not show this, to prevent duplication. So, in the queue case the fist composer = artist, so is not shown, but in browse composer!=artist so is shown. (Hope that makes sense).

I guess in the case of multiple composers Material should handle the others, as opposed to just looking at the first - hence its only a partial LMS issue.

Personally I'd prefer it if the composers were all shown, even if the same as the artist. If all tracks in the album are composed by the same artist you could add "All tracks composed by %COMPOSER%." to the right of the album name or before the track count and duration in the picture below and then not show any composer info for each individual track. To my mind, it'd declutter the interface nicely

When showing composers for individual tracks I think it'd benefit from changing the text colour to differentiate the track title from composer, and it'd be even better if the font were reduced somewhat and the composer metadata were placed on the line below the track number and title.

Where does the line that shows track duration, vbr, bit depth and sample rate come from - is that configurable. For lossless the VBR is just clutter, and if the bit depth and sampling rate are the same for all tracks I'd display it once, to the right of the album name as 44.1/16 or 16/44/1 - again decluttering.

So in summary, if I may be so bold I'd change the layout as follows:

[cpd73]

Could you please provide query & response, and the file's raw metadata (as reported in the More Info trackinfo menu)? Maybe we can take this to a GitHub issue.

Issue raised on GitHub: https://github.com/Logitech/slimserver/issues/858 I've attached a hacked-up OGG file I used to create the issue to the GitHub report. (Its a royalty-free sample OGG I use for testing issues such as this).

[Edit] And Michael has correctly found the error in Material's request when asking for tracks. Will be fixed in 3.1.1

[slartibartfast]

I am experiencing an issue following the latest update and wonder if other users are seeing this too? When searching under Music Sources, pCP freezes, as if the system has gone into overload. I am curious if I am the only one having this issue? I first noted the issue when I tested a pre-release version of the plugin for Craig. The problem resolved when I reverted to the previous version. The exact issue returned today following the update to the plugin. Craig advised that he couldn't think of any code that would interfere with the search function. Thanks.

Doesn't the same thing happen with the default skin. I find some searches are a lot longer than others with the longer ones causing issues with Material and default skins.

[Shozzer]

I am unsure how to diagnose this issue. A simple search under 3.1.0 really messes with pCP so the extent that it stops play on other devices. Mrs Shozzer was not happy yesterday! I have gone back to 3.0.3 and the same search was completed in a second. This was why I asked if others experienced the same thing or if this is something peculiar to my own set up.

Doesn't the same thing happen with the default skin. I find some searches are a lot longer than others with the longer ones causing issues with Material and default skins.

[slartibartfast]

I am unsure how to diagnose this issue. A simple search under 3.1.0 really messes with pCP so the extent that it stops play on other devices. Mrs Shozzer was not happy yesterday! I have gone back to 3.0.3 and the same search was completed in a second. This was why I asked if others experienced the same thing or if this is something peculiar to my own set up.

If I search for "black" it takes more than 30 seconds in Material and default so I am not sure what is normal.

[Shozzer]

I guess it is what you become used to. A delay in results isn't so much an issue as the actual slowing down / freezing of the system. Library size is probably a factor as well. I just find it odd that there is such a huge difference between the two versions of the plugin.

If I search for "black" it takes more than 30 seconds in Material and default so I am not sure what is normal.

[slartibartfast]

I guess it is what you become used to. A delay in results isn't so much an issue as the actual slowing down / freezing of the system. Library size is probably a factor as well. I just find it odd that there is such a huge difference between the two versions of the plugin.

I think it's the long search that causes issues. If the buffer runs dry during the search it stops playback until the buffer fills again.

[bwaldron]

Personally I'd prefer it if the composers were all shown, even if the same as the artist.

Same here

When showing composers for individual tracks I think it'd benefit from changing the text colour to differentiate the track title from composer, and it'd be even better if the font were reduced somewhat and the composer metadata were placed on the line below the track number and title.

This would be very nice

[cpd73]

I guess it is what you become used to. A delay in results isn't so much an issue as the actual slowing down / freezing of the system. Library size is probably a factor as well. I just find it odd that there is such a huge difference between the two versions of the plugin.

Just did a quick check, and it is indeed the extra meta-data that is massively slowing this down. 3.1.0 asks for genre and all artist vlaues (composer, band, etc). I'll just remove this, and revert to the previous display - so no composers, etc, shown in a tracks search results. The slowdown is just not worth it.

[Shozzer]

Thanks for looking into this Craig.

Just did a quick check, and it is indeed the extra meta-data that is massively slowing this down. 3.1.0 asks for genre and all artist vlaues (composer, band, etc). I'll just remove this, and revert to the previous display - so no composers, etc, shown in a tracks search results. The slowdown is just not worth it.

[cpd73]

Thanks for looking into this Craig.

When i said that there was no changes that would have affected this, I was thinking the slowdown was in the Material Javascript handling - and there was no slowdown there. But I failed to think about LMS taking longer for searches due to asking for more meta-data. The difference in speed is huge!

[Shozzer]

And of course I failed to make the connection when I tested the plugin over Christmas as I was only concerned with the player apps functionality... I wasn't aware of other changes under the hood - not that I would probably have made the connection anyway!

When i said that there was no changes that would have affected this, I was thinking the slowdown was in the Material Javascript handling - and there was no slowdown there. But I failed to think about LMS taking longer for searches due to asking for more meta-data. The difference in speed is huge!

[slartibartfast]

When i said that there was no changes that would have affected this, I was thinking the slowdown was in the Material Javascript handling - and there was no slowdown there. But I failed to think about LMS taking longer for searches due to asking for more meta-data. The difference in speed is huge!

Hmm I wonder why my default skin also takes a long time.