File access not possible after pressed stop

[neralex]

Hi!

If I played a file and pressed stop, I can't rename or delete the played file. I have to close WACUP or I have to load another before I get the File access the file. This happend only in WACUP. In WINAMP 5.666 I don't get this behavior. I'm using the preview-build 1.0.21.7236.

Cheers

[dro]

What file type? Though doing things on the currently playing file has always been funky even against a plain Winamp & I know there's things that still need to be finished as part of my code replacement so it's probably going to get worse for the near term.

-dro

[MourningStar]

This would be similar to trying to rename or delete an open document. Windows will not allow it, ... wacup should not as well.

[neralex]

Ok I tested it again. Rename a file works (sorry) but after pressed stop I can't delete it. I have to close WACUP before. It affects AIF, AIFF, WAV, mp3. Reproduce: Play a file, press stop and try to delete it.

[MourningStar]

... Play a file, press stop and try to delete it.

The file is open/locked in the 'stop' condition and should not be able to delete. As it should be. If you must delete with the app still running simply load/play a new file. How is this an issue?

[neralex]

The file is open/locked in the 'stop' condition and should not be able to delete. As it should be. If you must delete with the app still running simply load/play a new file. How is this an issue?

Maybe you are going completely wrong here because this is not true. Let me give you another example for Windows. Create a txt-File, open it with the editor and try to delete - it works. I can also use each other app in Windows like Adobe Audition, which is more in context to the issue. If I loaded a file into Adobe Audition and the playpack is stopped, I can delete it. Only if the file is on pause or while Adobe Audition is saving this file, then it is locked. The same fore Windows Media Player, VLC etc... 

[MourningStar]

The file is open/locked in the 'stop' condition and should not be able to delete. As it should be. If you must delete with the app still running simply load/play a new file. How is this an issue?

Maybe you are going completely wrong here because this is not true. Let me give you another example for Windows. Create a txt-File, open it with the editor and try to delete - it works.

I am on Windows 10. Following your example, yes, a 'New Text Document.txt' is created. Once opened for editing you can delete the file 'New Text Document.txt'. Howvever, the open document remains. Nothing accomplished. Back to topic, answer my previous question : How is this an issue?

[neralex]

Its a usability-issue because this is not a normal behaviour off apps on Windows 10.

While preparing new tracks for my traktor-collection, I'm skipping fast with Winamp through the new tracks of a EP or a VA before. This is very handy because Winamp can handle it very easy with a single click on a audio-file. if I dislike a single track inside a package, then I can simply press stop, delete the file before I start listening to the next track. This is really annoying when you skip through more than 10 tracks and you stuck erytime while you have to load another track and the playback starts before you can delete the current one.

[MourningStar]

^
this issue does not seem to be a wacup defect. as you say, winamp does not have this issue, only dro can validate it a bug or not. there are winamp behavior (not many, but few) that does not apply to wacup.

if not a bug, perhaps it moves into the enhancement request forum. i am curious to know what percentage of the wacup community consider this an issue. imo, little-to-nobody, based on lack of any other users contributing to this topic (thus far). Perhaps there is a great deal of this issue being reported in the beta forum, of which we 'commoners' can have no knowledge of.

[dro]

Winamp has & had similar issues over the years & I know WACUP does when it comes to dealing with certain actions on the current file which are all related. So this is a different manifestation of the issue when trying to update metadata in the currently playing item which is something I've mentioned before is messed up (whether you fake it by quickly stopping playback, making the change & then resuming playback or if you do it after playback completes).

As such my code really shouldn't be permanently locking things but as it depends on the input plug-in (hence asking for what file types are affected) & if these are changes being made externally of WACUP then it's something I need to better account for vs doing things within WACUP where it's a bit easier to try to force things into a state where any access locks are removed.

As for the importance of this as an issue, the number of reports I've got logged against issues with modifying things that are currently playing actually amazes me that it's such a commonly used action & is something that will be addressed sooner rather than later (subject to some of the plug-ins that are causing the issues).

tl;dr - I know it's an issue & it's far from intended behaviour.

-dro