Bug: WACUP keeps handle on folder for recently played file

[OldPaprika]

Hi again, I noticed another minor issue.

Repro:
- In Windows 10, have an MP3 in a folder.
- Play that MP3 with WACUP.
- Stop playing the file.
- Attempt to remove the folder using Windows Explorer.
-> Notice the error message: "The action can't be completed because the folder or file in it is open in another program". I would expect WACUP to not block me from this once I have stopped playing the file.

Closing WACUP resolves the issue.

Using v 1.99.32.21640 (x86), public preview build.

And thank you for a great application. 

[MourningStar]

Hi again, I noticed another minor issue.
...
Closing WACUP resolves the issue.

Not an issue with WACUP. It is standard OS behavior.

[dro]

It sounds similar to the second issue from https://getwacup.com/community/index.php?topic=2206.0 which I've not managed to replicate in the manner detailed in there though that was based on playback having moved to another file / folder instead of just stopping on the current item if I'm following this correctly.

I wouldn't say it's an OS thing & as other file types in wacup are seemingly not affected it's most likely related to the re-used in_mp3 plug-in from the 5.666 installer that the x86 build is using by default for mp3 playback & despite a few attempts to signal it to clear anything it might've cached it doesn't seem like it always works & that might be why there's the problem. I'll try again to replicate it but I don't think the next pending updated preview build is going to make a difference for this or the other thread.

[OldPaprika]

Thanks for looking into this.

I tested with disabling in_mp3.dll and the problem goes away. Enabling it brings the problem back so seems indeed to be the culprit.
Evidently WACUP could play mp3s without it so I keep it disabled for now.

Let me know if you need help testing this as repro is 100% for me.

[dro]

It uses a fallback via in_wave as that was needed to allow the x64 build to be able to play MP3 files since it doesn't have a dedicated in_mp3 replacement (lack of tag editing & some steaming features are the obvious things missing in that mode for either build types without an in_mp3).

[nxho]

Thanks for looking into this.

I tested with disabling in_mp3.dll and the problem goes away. Enabling it brings the problem back so seems indeed to be the culprit.
Evidently WACUP could play mp3s without it so I keep it disabled for now.

Let me know if you need help testing this as repro is 100% for me.

It worked for me too, initially. Then after a few more days it stopped working. Keep testing.

[nxho]

It uses a fallback via in_wave as that was needed to allow the x64 build to be able to play MP3 files since it doesn't have a dedicated in_mp3 replacement (lack of tag editing & some steaming features are the obvious things missing in that mode for either build types without an in_mp3).

dro, I have a new theory. I recently downloaded some registry cleanup tools to see what software traces were left behind and to my shock the tool found more than 1000 winamp traces in the registry. When I discovered WACUP, I simply uninstalled Winamp through the basic Win 11 surface and then proceeded to install WACUP over it. I'm aware that WACUP may use shared registry or other traces with Winamp so I didn't dare to clean the registry, but I figured: What if past Winamp traces are messing with WACUP? Also this would explain why so few people report this problem: Most of your users probably don't come straight from brutally outdated Winamp but other more recent software so there is no conflict. Just a theory of course