WACUP
Preview Build Discussion => Preview Build Discussion => Topic started by: nxho on April 11, 2025, 06:32:38 PM
-
Recently switched from decades of Winamp abuse,I have 2 issues for which the solution may be hidden somewhere in the settings but I'm unable to locate them:
1: Winamp used to add "enqueue" to the Windows context menu after install. With it I used to add mp3 files directly to the playlist. Any way to bring it back? I really miss it. Used to be somewhere in the top part in the context menu for mp3's
2: Can't delete the folder (in Windows Explorer) where the last played track is located, even when playback is stopped. Need to exit Wacup to delete the folder. Why is it using hooking a folder with no playback? Any solution?
I'm on Win 11 22H2
-
1) This is noted as not being a thing in the build related information shown during install of the preview build.
2) That shouldn't be happening & I'd need to know what file type(s) it's happening with as I'd resolved all instances of files being held onto that I could replicate (there's still a window of a few seconds after a file is accessed due to me caching access to them to make repeated metadata queries not have to take as long again during that time) otherwise the access to the file especially if playback has stopped shouldn't leave anything in a held open state (unless it's maybe a bug with the re-used in_mp3 again). Would also need to know what build of WACUP you're having this issue with.
-
1) This is noted as not being a thing in the build related information shown during install of the preview build.
Sorry I didn't read that one. Does this mean it's not getting added in the future since I'm the only soul who is still using it or are you guys busy with much more important stuff and It will eventually come?
2) That shouldn't be happening & I'd need to know what file type(s) it's happening with as I'd resolved all instances of files being held onto that I could replicate (there's still a window of a few seconds after a file is accessed due to me caching access to them to make repeated metadata queries not have to take as long again during that time) otherwise the access to the file especially if playback has stopped shouldn't leave anything in a held open state (unless it's maybe a bug with the re-used in_mp3 again). Would also need to know what build of WACUP you're having this issue with.
I only play mp3 files, no idea if it happens with other formats.I'm using the latest build (1.99.27.21136 (x86))
Thanks for your response! Let me know if you need more information
-
As a sort of work-around for the Enqueue option, you can Right-Click on a file in WACUP's Media Library and choose the Enqueue option there to add it to the current playlist.
(https://i.imgur.com/lYWLL1V.png)
I know not the same as doing it from Explorer but thought I'd mention it.
-
As a sort of work-around for the Enqueue option, you can Right-Click on a file in WACUP's Media Library and choose the Enqueue option there to add it to the current playlist.
(https://i.imgur.com/lYWLL1V.png)
I know not the same as doing it from Explorer but thought I'd mention it.
ahh you got me excited for a moment:) I have a unique habit of downloading a lot of mp3's and deleting about 95% of them. I never used the media library for this kind of work. But thanks for mentioning it, good to know it's there in some form:)
-
Does this mean it's not getting added in the future since I'm the only soul who is still using it or are you guys busy with much more important stuff and It will eventually come?
The aim of the preview build was to not screw around with existing settings especially when it was starting out as a plug-in pack for 5.666. As such I don't have any code in the builds that can register what file types WACUP can handle but there are things in place to allow for manually associating it if that's wanted (e.g. the open with option the OS provides & then the options on preferences -> general can be changed to adjust what the default behaviour in response to command-line actions is using). At some point I'll get around to completing the feature along with having to look into implementing a shell extension to resolve other problems with trying to process many files which the basic command-line behaviour doesn't cope well with in recent Windows versions.
I only play mp3 files, no idea if it happens with other formats.I'm using the latest build (1.99.27.21136 (x86))
Are you also looking at the metadata &/or making changes to the metadata of those MP3 files?
-
Does this mean it's not getting added in the future since I'm the only soul who is still using it or are you guys busy with much more important stuff and It will eventually come?
The aim of the preview build was to not screw around with existing settings especially when it was starting out as a plug-in pack for 5.666. As such I don't have any code in the builds that can register what file types WACUP can handle but there are things in place to allow for manually associating it if that's wanted (e.g. the open with option the OS provides & then the options on preferences -> general can be changed to adjust what the default behaviour in response to command-line actions is using). At some point I'll get around to completing the feature along with having to look into implementing a shell extension to resolve other problems with trying to process many files which the basic command-line behaviour doesn't cope well with in recent Windows versions.
I only play mp3 files, no idea if it happens with other formats.I'm using the latest build (1.99.27.21136 (x86))
Are you also looking at the metadata &/or making changes to the metadata of those MP3 files?
Very interesting. And thanks for the insight! To answer your question: No metadata changes on my behalf, just simple playback.
Also I have further feedback which may be of use to you:
Today I noticed a different hooking behaviour: I listened to File 1 in folder 1. Then I doubleclicked and listened to File 2 from Folder 2. After the track ended and playback stopped, I deleted Folder 1 and was suprised that it couldn't be deleted. File 2 from Folder 2 was still in the playlist and WACUP was open, and to my surprise windows allowed me to delete Folder 2, but in order to delete Folder 1 I had to close WACUP. To summarize, it's as if the second to last file got hooked. Weird erratic behaviour. File 1 was 58 minutes and File 2 was 7 or so minutes, and I waited the whole 7 minutes and once it stopped I attempted to delete File 1 with WACUP still open.
-
dro, I just noticed that it's not using the files, it's using the FOLDER. I can delete all the files within the folder with no issues, but the folder itself can only be deleted when WACUP is closed
please help it's driving me mad that I have to close it before every delete!
-
Try going to Preferences -> Plug-ins -> Input -> find in_mp3 in the list & un-check it & then close wacup. Then try replicating your issue again as that's the simplest way to try to determine if it's that input plug-in or not.
-
Try going to Preferences -> Plug-ins -> Input -> find in_mp3 in the list & un-check it & then close wacup. Then try replicating your issue again as that's the simplest way to try to determine if it's that input plug-in or not.
I have done extensive testing and it works flawlessly so far! Thank you! Can I leave this unticked with no further issues?
ps: I'm really sorry for not discovering its folder related nature earlier!
-
Back to square one. This time no folder involved, I attempted to delete a file after playback stopped, to no avail. I opened PowerToys File Locksmith to see what is using the file, and it's wacup.exe only. see in the attachment below:
and with the next deleted track: no problems. this makes absolutely no sense
-
If you're doing it whilst the file info dialog is still open then that is usually going to have the file in an open state because it might be trying to make edits. Tbqh I've still to actually look into this myself so I don't know why it'd be keeping a handle on the file vs how I've tried to code things.
-
If you're doing it whilst the file info dialog is still open then that is usually going to have the file in an open state because it might be trying to make edits. Tbqh I've still to actually look into this myself so I don't know why it'd be keeping a handle on the file vs how I've tried to code things.
I only opened the file info dialog to provide as much info as possible, but it's the same with or without it, wacup.exe is still using the file or folder.
I appreciate you trying to help, I understand that this is no top issue so I will try to get used to it. Thank you for your time and thanks for your amazing work on wacup, you really dragged winamp into the 21st century!
-
Maybe you could try using either the global hotkey (configured via that preferences page) or using the notification area icon (if enabled) that can be setup to remove the current main playlist item to see I that'll work without going into explorer to try todo it. As that should also force clear any internal handles that I know about.
-
I just couldn't get used to this problem and I decided to give it another shot and investigate further to help you find a possible fix. I used ProcMon to reveal what is happening exactly on a folder level and used AI to analyze the results. This is what AI came up with. Are these results plausible?
The CreateFile log entry you shared reveals:
WACUP opens the folder with Execute/Traverse (not aggressive, but it keeps the handle).
ShareMode allows deletion (Read, Write), but the folder still locks → Likely a handle leak in WACUP’s directory monitoring.
No CloseFile event → Confirms WACUP isn’t releasing the handle properly.
Steps to reproduce:
Play FileA from FolderA.
Play FileB from FolderB.
Try deleting FolderA → Fails until WACUP is closed.
Your theory:
"WACUP holds a folder handle (for scanning/monitoring) but doesn’t close it, blocking deletion until the app exits."
What the Developer Should Fix
Ensure CloseHandle() is called after folder scans.
Add a timeout to release idle directory handles.
Make folder monitoring optional in settings.
I attached the The ProcMon screenshot below
AI results in more detail:
Breaking Down Your CreateFile Log Entry
Here’s what each field tells us:
Field / Your Value / What It Means
Desired Access / Execute/Traverse, Synchronize / WACUP is only browsing the folder (not reading/writing files).
ShareMode / Read, Write / Other apps can delete/modify files in this folder (so WACUP isn’t locking it).
Options / Directory, Synchronous IO Non-Alert / WACUP opened the folder as a directory (not a file) and waits for responses.
Why the Folder is Locked (Despite These Permissions)
Synchronize Flag
This allows WACUP to hold the folder handle open while it checks for changes (e.g., new files).
Even though ShareMode allows deletion, Windows may still block it if the handle isn’t closed properly.
WACUP’s Behavior
The player likely scans the folder periodically (e.g., for playlist updates) but fails to release the handle afterward.
-
I know the reasons why things can appear as locked be it via CreateFile or via the *open equivalents which often can then drill down to using that OS api call.
What I however need is a means to replicate & determine _what_ is actually causing it to happen which I still can't replicate or I'm just missing something. As the input plug-ins & anything looking for metadata from files should only be working on the file & I'm not sure how the folder itself would be locked unless maybe that folder is listed on Preferences -> Media Library -> Folder Monitor?
I'm also assuming that you're still having this problem with the current 1.99.32.21640 preview build?
-
Thanks for the response dro. I'm using the latest build, and yes, I still have the problem.
You really can't recreate it? This is so weird.
Regarding Media Library
I don't have a Folder Monitor submenu, weird. See attachment below. But I'm sure the folder is not listed in it.
-
Have you tried the Playlist File Remover v3.4.3 (gen_play_remove.dll) plug-in? It has several configuration options for controlling how it functions.
-
No, never tried it. I can't locate it in the Plug-in menu... Where is it exactly?
found it. Untick only or delete?
-
From the screenshot it seems like you've not installed most of the media library features & have stripped out a load of things which is why you're not seeing the folder monitor & doing so is fine but it means I've not be doing anything comparative with my testing.
The suggestion is the File Remover prefs page but I honestly don't think that's going to help as it'll be affected by the same potential issue if something is holding onto a handle when MP3s are involved & there's nothing in place to cache the metadata from the files causing either my metadata reader or the input plug-ins to be used for every metadata request (am still suspecting in_mp3 is involved though I can't remember if you'd disabled wacup from using it or not).
-
Aminifu: I unticked gen_play_remove.dll, restarted wacup played fileA in folderA, then doubleclicked fileB in FolderB and deleted folderA, and it worked! I tested 3 times! I can't currently restart my PC but let's see if this state remains after a restart. Looking good so far! Thank you!
dro: you were always directing me towards plug-ins and you may have been right!
-
When gen_play_remove was being loaded (ticked in the listing), was it also enabled (in it's configuration options)? If it wasn't enabled, then I don't understand why not loading it would make a difference. I assume dro would have the answer.
-
I don't see how / why PLFR would ever have been involved (which isn't enabled by default) unless it was being used to try to remove the playlist items (I don't see that having been mentioned previously & was under the impression it was external file removal being done) & then it shouldn't be the cause of such issues since it's actions work only on file path of the playlist item.
So I still don't think whatever is causing issues for nxho is actually resolved & still would view it to be some other plug-in (wacup uses a load of plug-ins so often plug-ins will be the reason behind things when there's an issue).
Tbqh I think it needs to be re-detailed on what exactly is being done. As right now I don't think I've done any testing that matches what's being reported when I was under the impression it related to the last file that was being played not being able to removed & not the one prior to what's now playing as the last post seems to be implying :confused:
-
Aminifu It wasn't enabled, but wacup required me to restart when unticking it.
dro: Files are not removed through the playlist, but in Windows Explorer.
Play FileA from FolderA.
Play FileB from FolderB.
Try deleting FolderA → Fails until WACUP is closed. (Deletion is attempted while having FileB play, and also while it's stopped. Only closing or restarting wacup helps
Additionally: FileA can be deleted while running FileB. But empty FolderA can't be deleted unless wacup is closed or restarted.
I run wacup barebone. No visualization, timer, media library or anything fancy running.Even the equalizer window is closed
-
Disabling a plug-in will require a process restart as that's the simpler way to ensure it's been removed & the state change is applied vs trying to live unload which complicates what the plug-ins have to do without it generally being worth the potential complications from doing it.
As we're talking about plug-ins, Preferences -> Plug-ins -> Input -> is in_mp3 shown in there & if it is, is it enabled or disabled?
-
dro: you mentioned in_mp3 couple weeks ago when we first tried troubleshooting. I remember it briefly working but after a restart it stopped working. I re-enabled in_mp3. Yesterday, with the newest version I attempted unticking the in_mp3 trick again, but it resulted in a new bug: Doubleclicking an mp3 in Windows enqueued it, but didn't start playback. I had to doubleclick again in wacup to start playback. So I quickly re-ticked in_mp3
-
Disabling in_mp3 shouldn't be causing playback to require that sort of interaction to get it to then work & as in_mp3 is the plug-in that I strongly suspect is causing you these locking issues to start with we're now back to using something that is known to be buggy & was why I'd said to disable it as then I'm at least potentially comparing with code that I've control over which is not the case with the re-used in_mp3 dll. Then again I don't even know if the fallback in_wave plug-in is now present & enabled in that install if other aspects have been stripped out which wasn't indicated to start with. I'm now done for the day.
-
dro: Sorry mate I hope I'm not annoying you too much. It was a while back when I first installed wacup, and I may have done a unique install with lots of stuff crossed out, yes... Forgot about this aspect sorry!
in_wave.dll is ticked and enabled
should I reinstall with everything enabled as offered in the installer?
or should I disable "Media Library support"? perhaps?
-
I would try a full removal and reinstall with all the defaults enabled, to see if that makes a difference. dro may have another recommendation later.
You can remove (disable) selected stuff one by one later and test to see if/how each removal changes things. Keep notes, until you learn how WACUP works for you. WACUP can look simple on the surface, but there is a lot to it.
-
Doing the above isn't ideal if the installation is showing a consistent issue but another portable install would be better for comparison testing with the suggestion made. Alternatively I'd need a copy of the install.ini from the program folder to see what is potentially installed in the misbehaving install.
-
Update: After a complete shutdown of the PC the problem is back the next day.
install.ini file contents
[StartMenu]
Name=WACUP (32-bit)
[sections]
decoderMp3=1
decoderMp4=1
decoderFlac=1
decoderOpus=1
decoderCdda=1
decoderCapture=1
decoderAPE=1
decoderMPC=1
decoderOgg=1
decoderTTA=1
decoderWav=1
decoderWMA=1
decoderWV=1
decoderDSD=1
decoderZIP=1
decoderADLIB=1
decoderASAP=1
decoderQsf=1
decoderSid=1
decoderNCSF=1
decoder2SF=1
decoderGSF=1
decoderHively=1
decoderMidi=1
decoderMod=1
decoderMSX=1
decoderNSF=1
decoderORG=1
decoderPsf=1
decoderPxTone=1
decoderSC68=1
decoderSNSF=1
decoderSPC=1
decoderVGM=1
decoderVGMStream=1
ReplayGain=1
decoderURL=1
decoderAudio=1
centercut=1
enhancer=1
decoderM4v=0
decoderDirectShow=0
decoderNsv=0
winampMp3Encoder=1
encoderAac=1
encoderFlac=1
encoderOgg=1
encoderOpus=1
encoderTTA=1
winampWavEncoder=1
outputNotSoDirect=1
outputWavey=1
outputASIO=1
outputWASAPI=1
outputDisk=1
outputNeo=1
mediaLibraryLocalLibrary=1
mediaLibraryPlaylists=1
mediaLibraryHistory=1
mediaLibraryBookmarks=1
mediaLibraryPodcast=1
mediaLibraryRadio=1
mediaLibraryPortable=1
portableDeviceP4S=1
portableDeviceUsb=1
portableDeviceCreative=1
portableDeviceIPod=1
mediaLibraryExporter=1
FreeformSkins=1
Crystal=1
JTFE=1
Undo=1
PLFR=1
PlaylistExclude=1
Repeater=1
TipTop=1
Yar=1
ClassicArt=1
Lyrics=1
BigClock=1
WaveSeek=1
Thinger=1
GlobalHotkeys=1
Taskbar=1
Windows=1
TRAP=1
YuleLog=1
secGenWC=1
secDspWC=1
secMilk2=0
secMilk2Presets=0
secCSA=0
secGeiss=0
visAVS=0
-
I did a complete reinstall of WACUP. It worked normally after that. Then another win reboot and... I'm back to square one.
unticking in_mp3 didn't help this time either.
-
I didn't expect it would from other things you've mentioned & as you've already confirmed that disabling in_mp3 still has the issue occur then there's got to be something else going on which I'm just missing at this time for which I'll have to try to replicate again using your install.ini once I've cleared out some other build issues that are affecting more users from their reports (not what you want to hear but I'm going to have to find a larger window of time to be able to just waste a day or so in trying to replicate this which can't afford to do currently).
-
dro, I appreciate the effort! And I understand that you have to focus on more popular issues. In the meantime, I will experiment with disabling plug-ins.
My issues started with the second to last update. I'm wondering if there were any plug-ins that were added or enabled with that update... this could be a good lead