Latest restricted WACUP beta release is build #19516 (June 27th 2024) (x86 & x64 changelogs) | Latest WACUP public preview is build #19516 (June 27th 2024) (x86 only)

NOTE: Beta testers are added in a limited & subjective manner as I can only support so many people as part of the beta test program to keep it useful for my needs.

Unless I think you're going to be helpful, not all requests will be accepted but might still be later on. Remember that beta testing is to help me & the limitations currently works for my needs for this project.

Recent Posts

Pages: [1] 2 3 ... 10
Wishlist / Feature Requests / Re: Better Playlist Changes Management
« Last post by dro on Yesterday at 09:40:15 AM »
If a library playlist has been modified via wacup then in the playlists root node list or on the right-click for the specific playlist node if set to show the playlists as children of it, a revert to last backup playlist option exists as a one-level undo for such instances.

The save button showing is to nudge things otherwise closing wacup / changing to another view is going to trigger that save automatically otherwise the changes would be lost. There's a debate over should it prompt or not but when it did prompt, that then triggered crashes from the user not responding to the prompt & so auto-save + the one level backup was introduced to avoid the prompt issue.

Some actions also will do a hard-save immediately as that's just how the actions have been implemented from the playlist core vs being done by the view itself (which the likes of sorting falls under which I get is visually confusing) & really the save probably shouldn't be there to make it more like the main playlist & is from how I started out trying to make some of the plug-ins fully mimic the winamp one that they were trying to replace.

Should I have multi-level undo &/or adding the undo action to the view like the main playlist, yes. Should the save button be removed, probably yes. Should there be a prompt / forcing the user to interact, am probably going to say no as that often can't be relied upon to be responded to in a timely manner.

Wishlist / Feature Requests / Better Playlist Changes Management
« Last post by thisisbbc on Yesterday at 07:38:23 AM »
Original thread title: Remember Playlist Custom Order



Today I have encountered something rather frustrating and hopefully this can be addressed so my clumsy fingers aren't causing me any more headaches lol...

I was ordering songs in a pretty big playlist and had been working on it for some time, then I misclicked on the 'Title' header and the playlist was automatically ordered alphabetically. I tried 'Alt + Z' but unfortunately this had no effect. All my work evaporated 😅 (EDIT: Actually realized since I did not load a different playlist I still had the correct order in the Playlist Editor pane. I was able to save it again with the proper song order. Still, I think some improvements can be made to how playlist changes are handled.)

Would it be possible to implement a 'Sort list by hand' or something that Wacup could remember so that if we change sorting it can be reverted to our custom sorting?

The above seems overly complex and there may be a simpler approach...

Alternatively, and maybe a simpler solution, an undo button - or better yet a functional 'Alt + Z' - could work so that we can restore the playlist to a previous state in case of changes.

I noticed that if I go into a playlist, then change the position of a song, a 'Save' button appears indicating that the change(s) are not (yet) permanent and have to be saved. This is not the case when you re-order the playlist by clicking on the 'Title' header (probably something that should also trigger the 'Save' button to be displayed). Also, if you don't click on the 'Save' button and move to a different playlist, the changes are automatically saved. This is a bit clunky, I like the 'Save' button idea but it seems redundant if you don't need to click on it to save your changes.

I'm not sure what would be the best solution. I may prefer to be forced to click the 'Save' button to confirm changes. Maybe moving to a different playlist after making changes that are not saved would display a popup 'Your playlist order has changed, what would you like to do?' Save/Cancel. Maybe a checkbox 'Don't ask me again' for users that don't want to bother with this every time. Just thinking out loud.

Let me know what you think :)

Skins / Re: Looking for skin that can be docked to side
« Last post by ariszlo on July 21, 2024, 10:43:16 AM »
Vortex is docked to the left in Dashboard mode.
Exceptions don't necessarily mean something is actually wrong & there's things that I know of which get signalled via exceptions so maybe there's something with how the decoders are working but I won't know until I actually look into it. Without trying to go back through emails from last years, I might be mis-remembering the OS vs Ogg thing & if it was an optional install or something that was pushed via OS updates or it's a Win11ism or I have regressed things despite not having actively touched those plug-ins since having fixed them as I thought. I'm also not 100% certain that it is a failing library processing thread but it seems like it's the most likely thing but I don't think procdump reporting playback exceptions is what's causing the thread to fail (if it was then you'd also have no playback working for those files). Will reply back once I've done more checking on all of this.

That would probably be it, since my entire library is OGG, and I noticed that exception getting thrown like 50 times each time a new file was played, only skipping over a very select few in my library. The kicker is, they're all encoded using ffmpeg locally on my PC, so shouldn't be throwing errors from a file that doesn't match standards. As for my Windows install, I'm just running the same Windows 11 23H2 everyone else should be running, Enterprise edition. I haven't touched any binary system files beyond just updating them through Windows' own mechanisms, and I'm up-to-date according to Settings (without going to Insider versions).
Opus / Ogg should be releasing the file handles when playback stops & was something that was fixed quite a few builds back (either January or March iirc) so I'll re-check but that shouldn't have regressed & there was even something related to an OS extension pack that seemed to cause such problems so might not even be wacup directly at fault. Dunno about the exception breakpoint stuff without looking into it.

What I have now found is if the thread ml_ll uses to do most of its processing on terminates unexpectedly (e.g. in_mp3 or in_dshow throwing runtime related errors) then that can cause other parts to act like there's still something happening when there isn't & would match to the node icon staying stuck along with why non folder monitor instances have shown the issue & for those it'd be an add event that's likely being indicated.

I'm working on getting some checks into the timer to test the validity of the processing thread & reset things if that's found to be no longer matching with the handle I've got for it which should help with the failure. If that's what happening for you I don't know but it seems the most likely thing for what I've now observed.

Makes sense. One thing I did notice, however, while using procdump, is that there is a lot of "Exception: 80000003.BREAKPOINT" messages popping up during playback. It spams a TON of these anytime an OGG or Opus file (at least most of them from my library do this, not all, I have found a few that just operate normally) gets opened by WACUP for playback (on play or track change). The address listed in the message never changes, it's always as shown for me. I also tested with multiple other popular audio formats, and it does not occur with them. This testing included AC3 stereo (which didn't work at all in Winamp), MP3, MP2, FLAC, WAV, WMA, and AAC.

Edit: I also noticed that WACUP will retain file handles on Opus and OGG media after changing playback to a different track, yet it won't retain handles on any other format after a track change. Maybe the Vorbis and Opus decoders are both bugged?
Also, the method I tried testing the AC3 files with was to use Nullsoft's DirectShow plugin to allow playback of AC3 content, but all it did was garble the output thinking it was a 5.1 surround sound track, when all it contained was stereo audio. Given the format was intended for surround sound, this was not out of expectations of what could happen.
Yes the 2 definite reports I've got tracked were without the folder monitor. The procdump mode only possibly helps if a crash occurs & due to how it all works, it can be incorrectly triggered for things that aren't a crash (aka it's messy). Using task manager to get a dmp from the running process would be the alternative way but that can make a large dmp file (which often compresses will but might still be a few 100MB) & there's no guarantee that it'd capture things in a manner that'd allow me to inspect the state of the processing thread & related variables. Hence it'd be simpler if I could replicate it vs trying to get large dmp files that may or may not be of any use vs time to upload, etc.

Wait, you said that the times it was occurring was for those who weren't using the folder monitor? For me, it hitches itself into this infinite loop and I AM (and have been) using the folder monitor the entire time. Should I try catching the problem during a /procdump run of WACUP?
I don't know what version this issue first appeared in as I don't have a note of when it was first seen plus there is a disparity in when I get reports of issues vs the build that is available to be tested so it could be anywhere from the last few months to potentially a few years due to how ml_ll vs it's availability in builds was handled.

I've also only have a handful of reports of the problem so I don't know how common it actually is nor what the common factor things might be other than it seems to be able to occur when the folder monitor isn't used (which is the only obvious thing that'd otherwise be trying to do background removals).

I'd also advise not trying to mis-match dlls between different builds (the exe doesn't matter but makes any crash reports generated likely be reported to the wrong version) as there is a reliance on the core which is often changing between the builds & it can easily then cause other stability issues to occur from not having things in the manner that's expected.

For the issue itself, the only time I've managed to replicate it was due to a file metadata edit going massively awry & breaking numerous unrelated aspects & trashing the process's running memory causing things to run that shouldn't have been. Until I can somehow replicate it normally, I've made a change that does some extra checking of what's going on with the node animation handling to try to avoid the background thread that handles things not knowing it needs to try to finish process things e.g. due to another action having occurred that halted the background processing.

Whether that will actually help or is even related to things I don't know until I can somehow replicate the issue directly as I can't count the instance where it did happen as that wasn't seemingly reflective of what I've seen from those that also reported it. Maybe I'm just missing something about what's being done that's triggering the action but so far I don't have a proper solution.

Pages: [1] 2 3 ... 10