I'd recently moved to a new computer running Windows 10 when I started having this problem: despite closing foobar, the task manager shows the process still seems to be running at full speed preventing me from reopening it later unless I kill the task manually.
I've updated all the system files, am using the latest version, and even briefly tried an older version just to see if that might be the issue. Nothing's worked so far.
You need to post more information. A list of components and information from Appendix B – How to debug a deadlock (https://hydrogenaud.io/index.php/topic,67779.0.html) should be helpful.
Thanks for the reply. I hope this is everything.
Components:
Core (2019-01-21 12:12:58 UTC)
foobar2000 core 1.4.2
foo_albumlist.dll (2019-01-21 12:11:38 UTC)
Album List 4.6
foo_cdda.dll (2019-01-21 12:11:40 UTC)
CD Audio Decoder 3.0
foo_converter.dll (2019-01-21 12:12:28 UTC)
Converter 1.5.3
foo_dsp_eq.dll (2019-01-21 12:12:10 UTC)
Equalizer 1.2.1
foo_dsp_multiresampler.dll (2019-02-07 14:46:45 UTC)
MultiResampler 1.1.2
foo_dsp_std.dll (2019-01-21 12:11:32 UTC)
Standard DSP Array 1.3.2
foo_fileops.dll (2019-01-21 12:11:38 UTC)
File Operations 2.3
foo_freedb2.dll (2019-01-21 12:11:44 UTC)
Online Tagger 0.7
foo_gep.dll (2018-11-29 13:45:03 UTC)
Game Emu Player 1.213
foo_input_gsf.dll (2019-01-31 14:16:03 UTC)
GSF Decoder 3.0.12
foo_input_std.dll (2019-01-21 12:11:52 UTC)
FFmpeg Decoders 3.2.4
Standard Input Array 1.0
foo_input_usf.dll (2019-01-29 14:58:00 UTC)
LazyUSF 2.3.3
foo_input_vgmstream.dll (2019-02-07 14:56:09 UTC)
vgmstream plugin r1050-2051-gc9d997f3
foo_input_vio2sf.dll (2019-01-29 14:58:00 UTC)
2SF Decoder 0.24.15
foo_midi.dll (2019-01-29 14:58:00 UTC)
MIDI Player 2.1.8
foo_psf.dll (2018-11-29 13:46:33 UTC)
Highly Experimental 2.2.3
foo_rgscan.dll (2019-01-21 12:11:38 UTC)
ReplayGain Scanner 2.3
foo_sid.dll (2018-11-29 13:47:11 UTC)
sidplay2 1.43
foo_ui_std.dll (2019-01-21 12:12:08 UTC)
Default User Interface 0.9.5
foo_unpack.dll (2019-01-21 12:11:40 UTC)
ZIP/GZIP/RAR Reader 1.8
Stack threads:
Thread 7580
0x0000000000000000
wow64cpu.dll!TurboDispatchJumpAddressEnd+0x544
wow64cpu.dll!TurboDispatchJumpAddressEnd+0x3a5
wow64cpu.dll!BTCpuSimulate+0x9
wow64.dll!Wow64LdrpInitialize+0x236
wow64.dll!Wow64LdrpInitialize+0x120
ntdll.dll!LdrInitShimEngineDynamic+0x3047
ntdll.dll!memset+0x1e4c5
ntdll.dll!LdrInitializeThunk+0x5b
ntdll.dll!LdrInitializeThunk+0xe
Thread 14664
0x0000000000000000
wow64cpu.dll!TurboDispatchJumpAddressEnd+0x544
wow64cpu.dll!TurboDispatchJumpAddressEnd+0x9e
wow64cpu.dll!BTCpuSimulate+0x9
wow64.dll!Wow64LdrpInitialize+0x236
wow64.dll!Wow64LdrpInitialize+0x120
ntdll.dll!LdrInitializeThunk+0x179
ntdll.dll!LdrInitializeThunk+0x5b
ntdll.dll!LdrInitializeThunk+0xe
0x0000000000000000
Thread 17616
0x0000000000000000
wow64cpu.dll!TurboDispatchJumpAddressEnd+0x544
wow64cpu.dll!TurboDispatchJumpAddressEnd+0x9e
wow64cpu.dll!BTCpuSimulate+0x9
wow64.dll!Wow64LdrpInitialize+0x236
wow64.dll!Wow64LdrpInitialize+0x120
ntdll.dll!LdrInitializeThunk+0x179
ntdll.dll!LdrInitializeThunk+0x5b
ntdll.dll!LdrInitializeThunk+0xe
Thread 18100
0x0000000000000000
wow64cpu.dll!TurboDispatchJumpAddressEnd+0x544
wow64cpu.dll!TurboDispatchJumpAddressEnd+0x9e
wow64cpu.dll!BTCpuSimulate+0x9
wow64.dll!Wow64LdrpInitialize+0x236
wow64.dll!Wow64LdrpInitialize+0x120
ntdll.dll!LdrInitializeThunk+0x179
ntdll.dll!LdrInitializeThunk+0x5b
ntdll.dll!LdrInitializeThunk+0xe
Thread 19116
0x0000000000000000
wow64cpu.dll!TurboDispatchJumpAddressEnd+0x544
wow64cpu.dll!TurboDispatchJumpAddressEnd+0x9e
wow64cpu.dll!BTCpuSimulate+0x9
wow64.dll!Wow64LdrpInitialize+0x236
wow64.dll!Wow64LdrpInitialize+0x120
ntdll.dll!LdrInitializeThunk+0x179
ntdll.dll!LdrInitializeThunk+0x5b
ntdll.dll!LdrInitializeThunk+0xe
Thread 26248
0x0000000000000000
ntdll.dll!NtWaitForWorkViaWorkerFactory+0x14
wow64.dll!Wow64LogPrint+0xf44
wow64.dll!Wow64SystemServiceEx+0x153
wow64cpu.dll!TurboDispatchJumpAddressEnd+0xb
wow64cpu.dll!BTCpuSimulate+0x9
wow64.dll!Wow64LdrpInitialize+0x236
wow64.dll!Wow64LdrpInitialize+0x120
ntdll.dll!LdrInitializeThunk+0x179
ntdll.dll!LdrInitializeThunk+0x5b
ntdll.dll!LdrInitializeThunk+0xe
Thread 30264 (the culprit apparently. basically all the cpu cycles are working here)
0x0000000000000000
foo_midi.dll+0x332e1
0x0000000000000000
ntdll.dll!RtlAllocateHeap+0x3e
Thread 31228
0x0000000000000000
ntdll.dll!NtWaitForWorkViaWorkerFactory+0x14
wow64.dll!Wow64LogPrint+0xf44
wow64.dll!Wow64SystemServiceEx+0x153
wow64cpu.dll!TurboDispatchJumpAddressEnd+0xb
wow64cpu.dll!BTCpuSimulate+0x9
wow64.dll!Wow64LdrpInitialize+0x236
wow64.dll!Wow64LdrpInitialize+0x120
ntdll.dll!LdrInitializeThunk+0x179
ntdll.dll!LdrInitializeThunk+0x5b
ntdll.dll!LdrInitializeThunk+0xe
0x0000000000000000
I'm not sure how much I should have shared, but I hope this helps.
It appears foo_midi is the cause. Try uninstalling that component and see if the issue is fixed. Assumedly it helps,
@kode54 needs to look into it.
Looks like that did it! Thanks!
Please log all file activity with Process Monitor so we may locate why foo_midi is looping on your system. Apparently, you have literally thousands of MIDI files in your media library?
I don't think that's the case. Anyways, I tried using the newest version of foo_midi (2.1.9) and the problem persists.
I did make a log of the incident with process monitor. I hope I did it right, at least.
That tells me nothing. I'll need a log, preferably filtered to just the foobar2000.exe process, starting from before foobar2000 is launched.
Your stuck thread appears to be parsing a RIFF MIDI file (.rmi) and that's not a recursive process, so it's either parsing a lot of MIDI files, or it somehow got stuck on exactly one bad file.
E: Please try this instead, otherwise report back again:
https://kode54.net/fb2k/foo_midi.fb2k-component
So this time I tried specifically filtering out everything but foobar2000.exe and started logging it before opening the program. Using the version of foo_midi you linked, I was able to close and open it a few times without trouble, however once I actually started playing a file, (with a completely different plugin), the problem returned.
Also the file size of the log is significantly larger this time, which I don't understand.
You appear to have downloaded the World's Largest Chiptune and Streamed Video Game Music collection, or the equivalent thereof, and configured the player's Media Library to scan it all. And it faithfully scans it all, every time you restart it. It was still scanning through it all by the time you tried to terminate it.
From what I've gathered, the Media Library and playlists have some trouble when you start to approach a hundred thousand files. You may have started to hit that mark here.
Disabling one component doesn't guarantee it will fix the problem, as you have a lot of files in a lot of obscure formats. Not all of them require total processing on every open like MIDI files do, though. And my MIDI processor used to be a lot slower, too.
You can also configure individual Media Library paths to not scan every time you start the player. Of course, then they could miss anything you added while it wasn't running.
So I go to check this out and... wow. 100,000+ files in my chiptune folder. Then again that's also where I keep my renders so it's likely there's a couple duplicates in there lol.
Also it looks like I may have moved my ENTIRE collection over to one of the 'default' folders foobar scans for library purposes (the generic "Music" folder) when I moved over to my new computer, which may have caused this to begin with. I moved it to a place foobar doesn't automatically scan and the problem's completely gone away!
Thanks, and sorry for the trouble.
Yeah, if you have a lot of heavy to scan files in your media library scanning process, a single core will be using 100% until the entire scan job finishes, and it will only use less CPU time if the process is more disk IO limited instead of processing time limited.
A heavy media library should not stall shutdown. The scanning process is aborted when fb2k window is closed and should exit gracefully without a noticeable delay.
It may be impacted momentarily if the scan process is temporarily stalled on something. I do wish I knew which MIDI file was stalling the scanning process, since it would be helpful to fix a possible bug in my own processing code.
Perhaps media library needs some kind of error log - information about files that took too long to process or failed to process. I just added this to foobar2000 mobile, I'll implement it in classic foobar2000 as well.