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: Slow foobar2000 v2.0 startup [split] (Read 1878 times) previous topic - next topic - Topic derived from [Suggestions / Wishli...
0 Members and 1 Guest are viewing this topic.

Slow foobar2000 v2.0 startup [split]

Hi. I compared the startup speed of version 1.6 and 2.0 (32-bit). Well I have over 225,000 tracks and a lot of information in the tags. 1.6 starts in 1 minute and 2.0 takes up to 8 minutes! It runs on a Lenovo W520 with i7 and 32GB RAM.
I think the Album List integration (which I deleted in version 1.6 and still never need) is to blame.
I urgently wish to be able to delete the album list as a component (deleting the preferences for the album list is not enough)
Thanks
LG Frank

Re: Slow foobar2000 v2.0 startup [split]

Reply #1 –
Thank you for your bug report.

In the future, please do not use "wish list" topics for reporting bugs.

Album List does not do anything by itself if it is not embedded in your layout. Removing its settings is utterly pointless.

foobar2000 v2.0 may have performance issues with some add-on components so please post a full list of your components, from Preferences / Components [Copy report], when asking for help with such scenarios.

Finally, it could help if you could make an archive of your foobar2000 profile folder and send to me at peter[at]hydrogenaud.io . 8 minutes is outright unacceptable, I'm sure this scan be fixed.
Thanks.
Microsoft Windows: We can't script here, this is bat country.

Re: Slow foobar2000 v2.0 startup [split]

Reply #2 –
Thanks for your reply...my profile folder is 3.3 GB...i use bio panel with spider-monkey...
ok i test it...is it not the album list...
The strange thing is that version 1.6 starts in just over a minute and 2.0 takes 8 minutes. It's the exact same configuration. I copied the old folder completely once and then installed version 2.0 over it.

Re: Slow foobar2000 v2.0 startup [split]

Reply #3 –
It's not strange at all. It's already mentioned in Peter's post that 3rd party components not designed for fb2k v2 can be slower. That's why you were asked to provide a list of your installed components. If you're not going to provide any useful information, this will never get resolved.

Re: Slow foobar2000 v2.0 startup [split]

Reply #4 –
OK. I deactivate the plugins one by one and Test IT.
Thanks

Re: Slow foobar2000 v2.0 startup [split]

Reply #5 –
It's original Facets by Frank Bicking and the SpiderMonkey Panels. Without both it Starts in 45 sec.

Re: Slow foobar2000 v2.0 startup [split]

Reply #6 –
...
then I'll probably have to stay true to the old version. I can't do without facets and the esplaylist. I could get over spider monkey...that's a shame

Re: Slow foobar2000 v2.0 startup [split]

Reply #7 –
Please stick with old foobar2000 and wait for the affected components to be updated. I understand that many people will not want to switch to foobar2000 v2.x. I plan to release bug fix updates for the old version for as long as people care.

Also, foobar2000 v2.0 comes with a reimplementation of Facets (ReFacets) which doesn't have these issues.

The original Facets components was solid technology. But like many existing components it relies on all track info having been loaded into program memory on app startup and being essentially available "for free". New foobar2000 no longer works this way - components should query info in batches & avoid repeatedly asking for the same info.
Microsoft Windows: We can't script here, this is bat country.

Re: Slow foobar2000 v2.0 startup [split]

Reply #8 –
Quote from: Peter on
Please stick with old foobar2000 and wait for the affected components to be updated. I understand that many people will not want to switch to foobar2000 v2.x. I plan to release bug fix updates for the old version for as long as people care.

Also, foobar2000 v2.0 comes with a reimplementation of Facets (ReFacets) which doesn't have these issues.

The original Facets components was solid technology. But like many existing components it relies on all track info having been loaded into program memory on app startup and being essentially available "for free". New foobar2000 no longer works this way - components should query info in batches & avoid repeatedly asking for the same info.
Still not getting why we jump to 64 bits if track info is not cached in memory.

It's like the current behavior should have been the one on 32 bits, with ram limits, and the old behavior should be the new one.
I mean, foobar devs may continue repeating the problem is the non-updated components, but I see no rationale for this self-imposed design limit. Like hey, there are 2 reasons why things are slower, not one. One is the old component not being updated for v2 ok, but the other is the v2 design itself.  ::)

Even if components are updated, there are still use-cases where you need the entire library's tags. And there is no workaround for that. I have tested it here:
https://hydrogenaud.io/index.php/topic,123044.0.html
It makes no sense to make an ad-hoc tag cache in JS to reduce processing from 10 secs to 2 secs, when it should be in the main program.

And it's realy great that you, Peter, will continue updating foobar v1.6.

But I see the current forum ambient a bit shady... I mean, we are constantly pushing users to use fb v2 on forums, even when it's in beta some devs here are recommending it with their life... and people is being told that components are not going to be updated anymore for v1.6. All these while there are clearly basic problems with fb 2 like playback statistics now linked to paths, and the performance... I don't get it.