Experiencing frequent crashes trying to play songs on startup

[SuperVGBoy]

A new bug that I have been encountering is that WACUP frequently crashes when I try to play a song after I start it up.
Sometimes, the songs play fine after the restart, or it just crashes again when I attempt to play the songs again.
Something I found fixes it consistently is that refreshing metadata will make the songs safe to play, but I have to do it each time there's consecutive crashes from attempting to play songs.
Version: v1.99.49.24360
Platform: Windows 11

[dro]

Is wacup's crash reporter being triggered when this is happening?

[SuperVGBoy]

No, it hasn't triggered when it crashes like this

[dro]

Other than running it always with the crash report collector mode (start menu shortcut or manually running the /procdump command-line mode or trying to get a process dump from task manager if it manages to stay running long enough) until I've got a crash report to work with the only obvious thing would be trying a different output plug-in (e.g. if it's set to use notsodirect try using notsoyasapi & vice versa depending on what's already set to be used).

[SuperVGBoy]

Changing the output plugin doesn't really help.
Strangely, running in procdump mode doesn't immediately crash anything when I play a song. It only happens outside of that mode. it also shows an empty crash.log file sometimes when I attempt to run it in that mode. Where do I sent the process dump Task manager produces?

[dro]

You can use the email from the site homepage (if it's a smallish file) or pm a link if uploading it. Compressing any dmp file collected is needed as they compress quite well. Also the build has been updated so it'd be better to try to replicate with that vs the now prior one.

[yeacark]

I am experiencing the exact same issue since the last update (1.99.49.24360). However, after the new May 4th update nothing changed, and instead of happening only shortly after launch, it happens with a new playlist, so when I open a file from my media library with a 50% chance.

No error reporting gets triggered and running with /procdump or in safe mode still causes issues. Switching from Not So Direct to the WASAPI output did fix this issue, though, so I'd suggest looking into that, also because it's the best output you can choose at the moment.

[dro]

What about using the /procdump mode is still causing issues for you as that should be able to catch failures otherwise good or bad behaviours shouldn't be altered whether that debugging mode is being used or not.

The OP has also mentioned that changing the output plug-in makes no difference to them.

As for the comment about WASAPI being better, imho that's not true when all of the output plug-ins can & do have issues for some setups & as I'm currently working on debugging a stuttering issue related to a crash fix that was introduced with the notsodirect plug-in for 24472 (something that 24360 didn't have but instead would cause it to crash) could be behind your problem. It's also way there are other output plug-ins provided & yes for some setups wasapi might be the better solution but directsound is generally a more compatible fix for what is being targetted sans the problems with it which have been being worked through.

[yeacark]

I think I didn't express myself clearly, so I'll use a translator this time. What I meant was that Not So Direct is my preferred output option given the lack of logarithmic volume in the WASAPI output. In any case, this is a matter of personal preference. As you said, every output option has its pros and cons.

Actually, I also didn't mention earlier that I experienced stuttering, especially when I lowered the buffer from the default of 2000 to about 1000 to see if it would make a difference with the crashes. In fact, before it crashed, I noticed significant stuttering. Maybe check if it has something to do with buffering