A persistent bug that continues to show in ml_ll.dll when enabled

[xVincentx]

Hello, I've been noticing a strange behavior of the Local Library plugin that, according to patch notes, was found and fixed? It's been going on since the first version it was noticed by others in, but for me, every single other version after, including current, all seem to be afflicted by the same bug. This is even after manually ripping the EXE of the latest installer to pull the ml_ll.dll file and manually copy it into WACUP. Should I try the same idea, but with an older version to see if it's just an ml_ll.dll regression that is causing it still? I don't have a screenshot of it right now, as it seems to occur rather randomly, but it most often occurs on track change. It'll just start spinning a circle with the number 1 in parentheses and eating some CPU, like it got caught in an infinite loop trying to do something. Canceling the operation states it's trying to edit the DB in some form, and that cancelling now would mean it needs to happen later (usually it states it's trying to do a deletion).

[xVincentx]

Update: I have screenshots of what I'm talking about available in this comment. I'm also gonna try to catch the behaviour with the procdump flag on, but that will have to occur later, as it doesn't cause WACUP to crash.

[dro]

I don't know what version this issue first appeared in as I don't have a note of when it was first seen plus there is a disparity in when I get reports of issues vs the build that is available to be tested so it could be anywhere from the last few months to potentially a few years due to how ml_ll vs it's availability in builds was handled.

I've also only have a handful of reports of the problem so I don't know how common it actually is nor what the common factor things might be other than it seems to be able to occur when the folder monitor isn't used (which is the only obvious thing that'd otherwise be trying to do background removals).

I'd also advise not trying to mis-match dlls between different builds (the exe doesn't matter but makes any crash reports generated likely be reported to the wrong version) as there is a reliance on the core which is often changing between the builds & it can easily then cause other stability issues to occur from not having things in the manner that's expected.


For the issue itself, the only time I've managed to replicate it was due to a file metadata edit going massively awry & breaking numerous unrelated aspects & trashing the process's running memory causing things to run that shouldn't have been. Until I can somehow replicate it normally, I've made a change that does some extra checking of what's going on with the node animation handling to try to avoid the background thread that handles things not knowing it needs to try to finish process things e.g. due to another action having occurred that halted the background processing.

Whether that will actually help or is even related to things I don't know until I can somehow replicate the issue directly as I can't count the instance where it did happen as that wasn't seemingly reflective of what I've seen from those that also reported it. Maybe I'm just missing something about what's being done that's triggering the action but so far I don't have a proper solution.

-dro

[xVincentx]

Wait, you said that the times it was occurring was for those who weren't using the folder monitor? For me, it hitches itself into this infinite loop and I AM (and have been) using the folder monitor the entire time. Should I try catching the problem during a /procdump run of WACUP?

[dro]

Yes the 2 definite reports I've got tracked were without the folder monitor. The procdump mode only possibly helps if a crash occurs & due to how it all works, it can be incorrectly triggered for things that aren't a crash (aka it's messy). Using task manager to get a dmp from the running process would be the alternative way but that can make a large dmp file (which often compresses will but might still be a few 100MB) & there's no guarantee that it'd capture things in a manner that'd allow me to inspect the state of the processing thread & related variables. Hence it'd be simpler if I could replicate it vs trying to get large dmp files that may or may not be of any use vs time to upload, etc.

-dro

[xVincentx]

Makes sense. One thing I did notice, however, while using procdump, is that there is a lot of "Exception: 80000003.BREAKPOINT" messages popping up during playback. It spams a TON of these anytime an OGG or Opus file (at least most of them from my library do this, not all, I have found a few that just operate normally) gets opened by WACUP for playback (on play or track change). The address listed in the message never changes, it's always as shown for me. I also tested with multiple other popular audio formats, and it does not occur with them. This testing included AC3 stereo (which didn't work at all in Winamp), MP3, MP2, FLAC, WAV, WMA, and AAC.

Edit: I also noticed that WACUP will retain file handles on Opus and OGG media after changing playback to a different track, yet it won't retain handles on any other format after a track change. Maybe the Vorbis and Opus decoders are both bugged?
Also, the method I tried testing the AC3 files with was to use Nullsoft's DirectShow plugin to allow playback of AC3 content, but all it did was garble the output thinking it was a 5.1 surround sound track, when all it contained was stereo audio. Given the format was intended for surround sound, this was not out of expectations of what could happen.

[dro]

Opus / Ogg should be releasing the file handles when playback stops & was something that was fixed quite a few builds back (either January or March iirc) so I'll re-check but that shouldn't have regressed & there was even something related to an OS extension pack that seemed to cause such problems so might not even be wacup directly at fault. Dunno about the exception breakpoint stuff without looking into it.

What I have now found is if the thread ml_ll uses to do most of its processing on terminates unexpectedly (e.g. in_mp3 or in_dshow throwing runtime related errors) then that can cause other parts to act like there's still something happening when there isn't & would match to the node icon staying stuck along with why non folder monitor instances have shown the issue & for those it'd be an add event that's likely being indicated.

I'm working on getting some checks into the timer to test the validity of the processing thread & reset things if that's found to be no longer matching with the handle I've got for it which should help with the failure. If that's what happening for you I don't know but it seems the most likely thing for what I've now observed.

-dro

[xVincentx]

That would probably be it, since my entire library is OGG, and I noticed that exception getting thrown like 50 times each time a new file was played, only skipping over a very select few in my library. The kicker is, they're all encoded using ffmpeg locally on my PC, so shouldn't be throwing errors from a file that doesn't match standards. As for my Windows install, I'm just running the same Windows 11 23H2 everyone else should be running, Enterprise edition. I haven't touched any binary system files beyond just updating them through Windows' own mechanisms, and I'm up-to-date according to Settings (without going to Insider versions).

[dro]

Exceptions don't necessarily mean something is actually wrong & there's things that I know of which get signalled via exceptions so maybe there's something with how the decoders are working but I won't know until I actually look into it. Without trying to go back through emails from last years, I might be mis-remembering the OS vs Ogg thing & if it was an optional install or something that was pushed via OS updates or it's a Win11ism or I have regressed things despite not having actively touched those plug-ins since having fixed them as I thought. I'm also not 100% certain that it is a failing library processing thread but it seems like it's the most likely thing but I don't think procdump reporting playback exceptions is what's causing the thread to fail (if it was then you'd also have no playback working for those files). Will reply back once I've done more checking on all of this.

-dro