Home of the Squeezebox™ & Transporter® network music players.
Page 547 of 568 FirstFirst ... 47447497537545546547548549557 ... LastLast
Results 5,461 to 5,470 of 5671
  1. #5461
    Senior Member
    Join Date
    Mar 2017
    Posts
    2,229
    Quote Originally Posted by slartibartfast View Post
    Here are a couple of videos showing what I see. One is OK the other not.

    https://www.dropbox.com/s/zvtoc1kwdh..._Trim.mp4?dl=0
    https://www.dropbox.com/s/ngya4qre0e...82%29.mp4?dl=0
    Wow! Something is really wrong there! Just swiping up and down like that should be the same on both, there should be no delay. Must be a bug somewhere, as that is not how it should be - and not how it works for me. (In fact, what's shown in that view is not working!)
    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.

  2. #5462
    Senior Member
    Join Date
    Mar 2017
    Posts
    2,229

    Thanks for testing

    Thanks to everyone for testing the devel branch. However, for now, I'm going to revert to using the vue-virtual-scroller library. I'm unsure as to why some users are experiencing issues with the new code and I'm not sure if I have the time to debug all issues - especially when I cannot recreate them. For me the code is fast enough, but I'm unwilling to force such a drastic change on others - seems silly for no real benefit. If I was 100% confident in the changes I would not have asked others to test in the first place.

    If you are interested, the devel-lib branch contains the latest devel code but using the vue-virtual-scroller library.
    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.

  3. #5463
    Senior Member
    Join Date
    May 2005
    Location
    In a house
    Posts
    1,796
    Quote Originally Posted by cpd73 View Post
    Thanks to everyone for testing the devel branch. However, for now, I'm going to revert to using the vue-virtual-scroller library. I'm unsure as to why some users are experiencing issues with the new code and I'm not sure if I have the time to debug all issues - especially when I cannot recreate them. For me the code is fast enough, but I'm unwilling to force such a drastic change on others - seems silly for no real benefit. If I was 100% confident in the changes I would not have asked others to test in the first place.

    If you are interested, the devel-lib branch contains the latest devel code but using the vue-virtual-scroller library.
    Thanks for trying. It was probably worth the investigation and testing.

    I too have been frustrated at lack of reply / activity from some code authors for fixes / required features, and ultimately had to either clone or write my own simpler versions for my personal needs (e.g. HTTP error propagation, rate limiting, new REST endpoints in some Perl modules such as the Discogs and TMDB modules).

  4. #5464
    Member
    Join Date
    Feb 2020
    Location
    Seattle
    Posts
    80
    Quote Originally Posted by cpd73 View Post
    ...
    I'm unsure as to why some users are experiencing issues with the new code and I'm not sure if I have the time to debug all issues - especially when I cannot recreate them. For me the code is fast enough.
    On my systems it was not only fast enough, but faster, while providing more feedback, and the first version was faster than the second one. Hmm. Apparently differences between JS performance in different browsers/systems varies widely still [that video clip from slartibartfast was a "wow!". A B&N NOOK HD+, an OMAP 4470 powered 1920x1280 tablet from 2012 runs Material Skin smoother]

  5. #5465
    Senior Member
    Join Date
    Mar 2017
    Posts
    2,229
    Quote Originally Posted by MarSOnEarth View Post
    On my systems it was not only fast enough, but faster, while providing more feedback, and the first version was faster than the second one. Hmm. Apparently differences between JS performance in different browsers/systems varies widely still [that video clip from slartibartfast was a "wow!". A B&N NOOK HD+, an OMAP 4470 powered 1920x1280 tablet from 2012 runs Material Skin smoother]
    The issue on slartibartfast's video must be a bug (in my code), I just have not tried to track it down. But, with it being slower for Michael and others and no easy way of speeding up I just thought it was not worth the hassle. I don't want to downgrade Material's performance for no real benefit (and it seems no one else has seen the mising row I mentioned earlier). I have also managed to locate the issue in the library that was preventing me from using the latest version, and have a hacky fix (in its code) so that Material can now use that.

    As to why the 1st version was faster for you, I can't really explain that. It had a bug where on every scroll it would (internally) refresh the list of items to show - whereas in the 2nd version I fixed this so that it was only refreshed when required (which would use less CPU).
    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.

  6. #5466
    Member
    Join Date
    Feb 2020
    Location
    Seattle
    Posts
    80
    Quote Originally Posted by cpd73 View Post
    ...

    As to why the 1st version was faster for you, I can't really explain that. It had a bug where on every scroll it would (internally) refresh the list of items to show - whereas in the 2nd version I fixed this so that it was only refreshed when required (which would use less CPU).
    This may be perceived vs. absolute speed territory... more feedback -> higher perceived speed even though the actual speed may be objectively slower. Wish I could test that (AutoHotKey script? Maybe, at least on desktop).

  7. #5467
    Senior Member
    Join Date
    May 2006
    Location
    Silicon Valley
    Posts
    594

    devel-lib branch issue

    I am currently on the devel-lib branch which Craig, you plan to continue working on? I am having a problem with the "Show current track information" display. I cannot scroll any of its three panes, (Artist Biography, Album Review, Lyrics) and additionally the ribbon that contains the two buttons, "Update information when song changes" and "More" is being rendered in the wrong place, not at the bottom of these three panes. Otherwise, my experience with the devel effort has been reasonable. I have experienced some of the momentary jerkiness and blankness when browsing huge playlists but for whatever the reason, it was not a problem for me.

    Clearly, you have been working hard on the Material skin for quite some time now. Thanks again for all your work.
    Living Room: SB Touch + DIY PSU > CI Audio VDA.2 DAC + VAC.1 PSU > VRX.1 cables > Emotiva XSP-1 Gen 2 preamp + XPA-DR2 amp > Blue Jeans cables > B&W 804 speakers
    Laptop: System76 Galago + Ubuntu 16.04 + Squeezelite + Vivaldi/Material Skin > Emotiva Little Ego DAC > Grado PS500 headphones
    Bedroom: RPi Zero W + Squeezelite > miniBOSS DAC HAT > Bose SoundLink Revolve
    Phone: Pixel 3a + SB Player + Material APK > Senn IE80 earbuds
    Server: Puget Systems Serenity + Ubuntu 18.04 + LMS 8.0

  8. #5468
    Senior Member
    Join Date
    Mar 2017
    Posts
    2,229
    Quote Originally Posted by Ron F. View Post
    I am currently on the devel-lib branch which Craig, you plan to continue working on?
    Yes, that branch will be the changes for the next non-bug-fix released. I left 'devel' as is so that I could experiment with my scroller.


    Quote Originally Posted by Ron F. View Post
    I am having a problem with the "Show current track information" display. I cannot scroll any of its three panes, (Artist Biography, Album Review, Lyrics) and additionally the ribbon that contains the two buttons, "Update information when song changes" and "More" is being rendered in the wrong place, not at the bottom of these three panes.
    Ah, yes - on mobile only. Silly 1 line CSS fix - will do later.

    Quote Originally Posted by Ron F. View Post
    Otherwise, my experience with the devel effort has been reasonable. I have experienced some of the momentary jerkiness and blankness when browsing huge playlists but for whatever the reason, it was not a problem for me.
    Yeah, it was always going to be slower - as it is a simple solution. However, as stated, I don't want to degrade performance for no real gain - hence switching back to the library.
    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.

  9. #5469
    Senior Member
    Join Date
    May 2006
    Location
    Silicon Valley
    Posts
    594

    Time remaining in queue

    Query...

    Craig, would it be possible to add a feature, where somewhere in the Queue pane, it could be displayed how much time remains to play what is left in the queue, after the current song? My use case is for a large playlist added to the queue, I don't have a good guess - I can't handle the math.

    The question of course ... is where to put it, possibly when hovering over the total queue time? Or, in the top banner, like the way the current time can be displayed in the Now Playing pane? So, I am not sure where, but it would be useful to have such information available.
    Living Room: SB Touch + DIY PSU > CI Audio VDA.2 DAC + VAC.1 PSU > VRX.1 cables > Emotiva XSP-1 Gen 2 preamp + XPA-DR2 amp > Blue Jeans cables > B&W 804 speakers
    Laptop: System76 Galago + Ubuntu 16.04 + Squeezelite + Vivaldi/Material Skin > Emotiva Little Ego DAC > Grado PS500 headphones
    Bedroom: RPi Zero W + Squeezelite > miniBOSS DAC HAT > Bose SoundLink Revolve
    Phone: Pixel 3a + SB Player + Material APK > Senn IE80 earbuds
    Server: Puget Systems Serenity + Ubuntu 18.04 + LMS 8.0

  10. #5470
    Senior Member
    Join Date
    Mar 2017
    Posts
    2,229
    Quote Originally Posted by Ron F. View Post
    Query...

    Craig, would it be possible to add a feature, where somewhere in the Queue pane, it could be displayed how much time remains to play what is left in the queue, after the current song? My use case is for a large playlist added to the queue, I don't have a good guess - I can't handle the math.

    The question of course ... is where to put it, possibly when hovering over the total queue time? Or, in the top banner, like the way the current time can be displayed in the Now Playing pane? So, I am not sure where, but it would be useful to have such information available.
    I've implemented this; clicking on duration in queue will show a brief popup message with number of tracks and duration remaining.
    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.

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •