WACUP
General => Wishlist / Feature Requests => Topic started by: usrlocalben on August 17, 2021, 07:41:47 PM
-
I've been using WACUP for a year or so now. Here is one (of only two) frustrating differences I've encountered so far.
In classic WinAmp, if playback is stopped--but file is still selected--it can be e.g. deleted.
WACUP has a lock on the file and it is not available for delete/modify by other applications until playing a different file or closing WACUP.
For myself, it is frustrating when auditioning audio while organizing files since I must play another file (or close WACUP) in order to move/delete something I have just previewed.
-
"Preferences - playlist - file remover"
Is what I use here; can even delete file while song is playing.
As per your use case, I use it to cleanup my "auditioning" folder and quickly move songs to the correct genre folders.
Actually a benefit vs classic Winamp.
-
I may not have your flow quite right, but I tried it out.
I...
- enabled the file-remover,
- loaded some to-be-auditioned files into the playlist, and then
- used Next or Alt+Next to filter the playlist such that it contains a list of the files to remove. Then
- Selected All, and used REM...Remove...Physically Remove.
Building the inverse playlist is not quite intuitive but I agree it seems like you are right that it is better than a mix of winamp + explorer/cli work. Thanks for the tip :)
-
Glad this could help;
Fyi, my approach is actually to set a hotkey in the file remover tab which deletes the currently playing file and another hotkey to move the currently playing file to some "approved" folder.
I then load a playlist/folder of files to be auditioned and simply delete/approve files as they play.
-
In classic WinAmp, if playback is stopped--but file is still selected--it can be e.g. deleted.
WACUP has a lock on the file and it is not available for delete/modify by other applications until playing a different file or closing WACUP.
What file type(s) are you experiencing this with? As I know mp3 can be an issue but that's more down to the 5.666 input plug-in which I can try to nudge it to release it's lock but at the moment I don't have a complete way to control what is going on & it's likely this is related to that.
It also could be related to other plug-ins especially any other 3rd party plug-ins so I'd need a bit more information about the setup (i.e. an Info Tool report - best to pm me a copy than publicly post it) so I can see if there's anything obvious.
-dro
-
What file type(s) are you experiencing this with? As I know mp3 can be an issue but that's more down to the 5.666 input plug-in which
MP3 on an otherwise vanilla install.
Other types I play including in_sid* or in_mod are not locked.
-
Ok, I've made a note & will have to come up with a temporary solution to get that Winamp provided plug-in to play ball. Is probably because I'm not allowing it to be directly used for metadata read requests (since that can be buggy) & it's then doing its own thing once it's been used to play a file.
-dro
-
I've just been having a quick look at this to see if I can replicate it & by sods law I can't. All I've done is load up a playlist with a few mp3s, start one playing, press stop, go into an explorer view & attempt to delete the file which then works.
It's possible this is because I'm using the current beta instead of the preview build & a lot has changed compared to that which might mean the issue is still there but other aspects are now hiding it from what I can see (i.e. no metadata requests hitting the input plug-in responsible).
I'll still give it a go to try forcing the mp3 input plug-in to flush any cached metadata it might have on file completion otherwise until there's a newer preview build to use there's not much more I can do whilst I can't replicate the issue myself (as I was hoping would be a consistent issue from how it's described).
-dro