Skip to main content

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: Foobar UI responsiveness in Play/Pause mode vs Stopped (Read 1232 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Foobar UI responsiveness in Play/Pause mode vs Stopped

Having a general question on my experience on the respronsiveness when browsing through playlists or the library in foobar, where I did not find anything on the web:
I am experiencing a considerably higher respronsiveness in browsing through playlists/library when foobar is in play/pause mode compared to being stopped. In play/pause foobar is reacting almost instantly when e.g. clicking through different tracks of a playlist. When being in stop mode it feels much more delayed taking e.g. a second until track selection is taken.
I am using fb 1.6.7b6 and Columns UI 1.6.0. I am experiencing this behaviour on basically all UI elements I use such as WilBs library tree, the standard CUI playlist view, jsplaylist-mod, etc.
Of course I can always put fb in play/pause mode. I am just curious if I you see that as well and if it can be changed....

Re: Foobar UI responsiveness in Play/Pause mode vs Stopped

Reply #1
Sounds like either a weird quirk of whatever custom layout you might be using or - more likely - your HDD parking while idling. Then taking ~1 second to spin up again.

Re: Foobar UI responsiveness in Play/Pause mode vs Stopped

Reply #2
There is no HDD involved - I am using a MS Surface Go with SDD and SD Card (which of course could cause delays...). I am seeing the reduced responsiveness as well for playlists with youtube links.
Weird quirk of whatever custom layout  - that is possible, I am using numerous 3rd party applications on SMP and JSP via switching through different CUI layout presets....
So the message is: it is not a 'standard' fb/CUI/large application/etc behaviour - thanks for the info!

Re: Foobar UI responsiveness in Play/Pause mode vs Stopped

Reply #3
There should be no difference between the two modes. You could perhaps take a portable installation without any modifications and see if your problem persists.

Re: Foobar UI responsiveness in Play/Pause mode vs Stopped

Reply #4
Clean layout works well - so I have to identify the component causing the issue...

Re: Foobar UI responsiveness in Play/Pause mode vs Stopped

Reply #5
JSP/SMP may be the cause of this but of course it's not the components themselves - it's the nature of the scripts contained within.

One example is the thumbs script that is included with each one. By default, it sticks to the playing track when playing and selecting something else has no effect on it. But when playback is stopped, it will track the playlist selection and may cause delays if loading/resizing many images at once. It's generally not an issue for most people but the more/higher quality images you have, it can become an issue.



 

Re: Foobar UI responsiveness in Play/Pause mode vs Stopped

Reply #6
Just tested it - @marc you are right: the reduced responsiveness on stopped state is connected to SMP (not JSP, no change when included or not on my side).
What is interesting: even in a 'clean' CUI layout preset with only the standard CUI playlist view (but with 10+ 'inactive' CUI layout presets with loads of SMP plugins in the 'background'), the reduced responsiveness on stopped state is occuring. So SMP plugins seem to be active even if they are not part of the currently active layout preset.
Is this a general behaviour of SMP plugins or could this be an issue of any specific SMP plugin?

Re: Foobar UI responsiveness in Play/Pause mode vs Stopped

Reply #7
Pretty sure all panels in other presets are simply saved as part on the configuration. They aren't live and shouldn't respond to anything.

I tested with JSP just now but you can put the same code in SMP if you want...

Code: [Select]
function on_item_focus_change() {
var metadb = fb.GetFocusItem();
if (metadb) console.log(metadb.Path);
}

When the preset is active, it will output the path of any new playlist item you select. Now switch to a new preset not containing this panel and nothing happens.

Re: Foobar UI responsiveness in Play/Pause mode vs Stopped

Reply #8
Wow, great, that solves the issue!! Thanks very much!  No reduced responsiveness on stopped state any more!
Your extension works in all my SMP plugins (mainly yours + WilB), only plugin which does not like it is Biography Text, Album Info, Picture. www.last.fm from @kgena_ua , saying 'no artist selected'. I will take it off.
Thanks again marc for your great help!!

Re: Foobar UI responsiveness in Play/Pause mode vs Stopped

Reply #9
You have not understood my point at all. It was never meant to go in any existing panel as a "fix". It was to illustrate that panels in non-active presets cannot be the cause of any issues you have. As they're not active, they cannot receive messages or do anything.

Have a gif....






Re: Foobar UI responsiveness in Play/Pause mode vs Stopped

Reply #10
In this example, I've modified the C++ to spit out the number of active panels. Because fb2k is playing in this example, it's receiving an "on_playback_time" notification once a second. Even without panels, it churns away in the background but would never use resources in a way that is noticeable.



Again it shows how panels become active/inactive when switching CUI presets.

Re: Foobar UI responsiveness in Play/Pause mode vs Stopped

Reply #11
You are right - I fully misunderstood  ::)  - thanks for clarification!
As you already showed, I as well found with your approach that panels in non-active presets are inactive.
However, I as well saw using your method, that JSP/SMP panels included via Popup Panels are active independant if they are shown or not, and (of course) for all CUI layout presets . Removing above mentioned plugin from Popup Panels solved the issue.
Thanks for your support!