WACUP is almost perfect, 2 minor issues

[nxho]

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

[dro]

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.

[nxho]

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

[MarkRH]

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.



I know not the same as doing it from Explorer but thought I'd mention it.

[nxho]

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.



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:)

[dro]

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?

[nxho]

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.

[nxho]

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!

[dro]

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.

[nxho]

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!

[nxho]

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

[dro]

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.

[nxho]

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!

[dro]

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.