Announcement

Collapse
No announcement yet.

Announce: Material Skin

Collapse
X
 
  • Time
  • Show
Clear All
new posts

  • 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)
    Material debug: 1. Launch via http: //SERVER:9000/material/?debug=json (Use http: //SERVER:9000/material/?debug=json,cometd to also see update messages, e.g. play queue) 2. Open browser's developer tools 3. Open console tab in developer tools 4. REQ/RESP messages sent to/from LMS will be logged here.

    Comment


    • Originally posted by cpd73

      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.
      Michael

      "It doesn't work - what shall I do?" - "Please check your server.log and/or scanner.log file!"
      (LMS: Settings/Information)

      Comment


      • Originally posted by cpd73

        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.


        Originally posted by cpd73
        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:

        Click image for larger version

Name:	image.png
Views:	196
Size:	192.4 KB
ID:	1627856​​Click image for larger version

Name:	image.png
Views:	187
Size:	28.4 KB
ID:	1627858
        Attached Files
        puddletag - now packaged in most Linux distributions.

        Comment


        • Originally posted by mherger

          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
          Last edited by cpd73; 2023-01-23, 10:35.
          Material debug: 1. Launch via http: //SERVER:9000/material/?debug=json (Use http: //SERVER:9000/material/?debug=json,cometd to also see update messages, e.g. play queue) 2. Open browser's developer tools 3. Open console tab in developer tools 4. REQ/RESP messages sent to/from LMS will be logged here.

          Comment


          • Originally posted by Shozzer
            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.
            Living Room: Touch or Squeezelite (Pi3B) > Topping E30 > Audiolab 8000A > Monitor Audio S5 + BK200-XLS DF
            Bedroom: Radio
            Bathroom: Radio

            Comment


            • 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.

              Originally posted by slartibartfast

              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.

              Comment


              • Originally posted by 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.


                If I search for "black" it takes more than 30 seconds in Material and default so I am not sure what is normal.
                Living Room: Touch or Squeezelite (Pi3B) > Topping E30 > Audiolab 8000A > Monitor Audio S5 + BK200-XLS DF
                Bedroom: Radio
                Bathroom: Radio

                Comment


                • 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.

                  Originally posted by slartibartfast

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

                  Comment


                  • Originally posted by 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.


                    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.
                    Living Room: Touch or Squeezelite (Pi3B) > Topping E30 > Audiolab 8000A > Monitor Audio S5 + BK200-XLS DF
                    Bedroom: Radio
                    Bathroom: Radio

                    Comment


                    • Originally posted by audiomuze
                      Personally I'd prefer it if the composers were all shown, even if the same as the artist.
                      Same here

                      Originally posted by audiomuze
                      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



                      Comment


                      • Originally posted by 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.
                        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.
                        Material debug: 1. Launch via http: //SERVER:9000/material/?debug=json (Use http: //SERVER:9000/material/?debug=json,cometd to also see update messages, e.g. play queue) 2. Open browser's developer tools 3. Open console tab in developer tools 4. REQ/RESP messages sent to/from LMS will be logged here.

                        Comment


                        • Thanks for looking into this Craig.

                          Originally posted by cpd73

                          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.

                          Comment


                          • Originally posted by Shozzer
                            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!
                            Material debug: 1. Launch via http: //SERVER:9000/material/?debug=json (Use http: //SERVER:9000/material/?debug=json,cometd to also see update messages, e.g. play queue) 2. Open browser's developer tools 3. Open console tab in developer tools 4. REQ/RESP messages sent to/from LMS will be logged here.

                            Comment


                            • 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!

                              Originally posted by cpd73

                              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!

                              Comment


                              • Originally posted by cpd73

                                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.
                                Living Room: Touch or Squeezelite (Pi3B) > Topping E30 > Audiolab 8000A > Monitor Audio S5 + BK200-XLS DF
                                Bedroom: Radio
                                Bathroom: Radio

                                Comment

                                Working...
                                X
                                😀
                                🥰
                                🤢
                                😎
                                😡
                                👍
                                👎