Current File Remains Locked when Stopped (Regression vs. WinAmp)

[usrlocalben]

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.

[etsaman]

"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.

[usrlocalben]

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

[etsaman]

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.

[dro]

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

[usrlocalben]

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.

[dro]

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

[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