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: foobar2000 problem: high CPU usage, nonresponsiveness and crashes with (Read 12828 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

foobar2000 problem: high CPU usage, nonresponsiveness and crashes with

Reply #25 –
I reduced the lookup patterns to only

folder.*
front.*
artworks.*
thumb.*
cover.*
album.*
%album%*.*
%artist% - %album%*.*
%filename%*.*

and now the performance and stability problem is almost gone  (I know previous patterns were somehow overkill but didnot ever think this could lead up to worst case scenario ie. 80000*240 file lookups). Anyway foobar now loads/unloads the whole library significantly faster even with albumart view ON.

foobar2000 problem: high CPU usage, nonresponsiveness and crashes with

Reply #26 –
Quote from: Peter on
Anyway, relevant code has been fixed to quit early where appropriate instead of evaluating album art lookup patterns for thousands of tracks each time; the next fb2k update will contain the fix.


This is great to hear, Peter! I've been scared of selecting the root in my Album List for a while because it freezes the interface (not audio playback though) for a good few secs each time - and it's definitely the album art. And I have a much simpler set of lookups for my album art:
Code: [Select]
cover.*
front.*
folder.*
%filename%.*
%album%.*
%artist% - %album%.*

foobar2000 problem: high CPU usage, nonresponsiveness and crashes with

Reply #27 –
BTW, please do not hesitate to post on the forum about such issues (even after you've already autosubmitted reports), they can be helped one way or another most of the time.
While autosubmitted crash/deadlock reports give me all the telemetry I need most of the time, there's too many of them and about 90% of them are issues that I have no power against (popular: DirectSound stuck, HDD reading stuck for several minutes - even though we use async reads? WTF?) and there's no automated way to filter these out (contrary to regular non-deadlock crash reports - recurring crash patterns show up on my radar very fast).
Microsoft Windows: We can't script here, this is bat country.

foobar2000 problem: high CPU usage, nonresponsiveness and crashes with

Reply #28 –
Try with 1.1.16 beta 2 please: http://www.foobar2000.org/download
Microsoft Windows: We can't script here, this is bat country.
 

foobar2000 problem: high CPU usage, nonresponsiveness and crashes with

Reply #29 –
Thank you for the update. The most part of the problem already was eliminated by reducing significantly the lookup patterns. Beta 2 seems to work without any extensive delays (loading the whole database takes about 8 seconds and CPU load drops down then to idle state which is fine  )
Load time with exhaustive patterns set was similar (about 11 seconds, then idle instantly)