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.

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - dro

Pages: [1] 2 3 ... 107
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.


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.


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.


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.


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.


That one is failing whilst trying to load the Big Bento Modern Windows 10 Edition skin which is just something that can happen with those skins & the re-used plug-in from 5.666 that WACUP tries to support to allow for modern/winamp3 style skins to work under it.

It seems like its having an issue doing something with determining font information for a string in this instance & I've seen other crash reports like it but isn't something I've seen myself nor have anything obvious I can do to try to patch around the plug-in.

If it keeps failing on loading with that skin set under the procdump mode then you're going to have to switch to a classic/2.x style of skin though I'm now wondering if it might just be that the setup doesn't like modern skins as can happen for some even though anything modern should be more than capable of running them when a PIII @500Mhz or so was more than capable.


That crash report seems to be a loading failure due to the stereo tool dsp plug-in possibly trying to use a CPU instruction that doesn't exist (e.g. AVX2) though what it actually was I can't easily determine at the moment. It also seems to be an older version of that plug-in vs what's currently offered though I don't know if that's going to be part of the issue or not & from prior experience the stereo tool dsp is really not friendly when it comes to resource usage & only seems to have gotten worse with time.

Either way you could either try updating the stereo tool plug-in or the simpler option in trying to run wacup with it disabled & then trying the procdump related mode again to see what that might capture.


No crash-reports, unfortunately, it just  hangs for a second or two and then closes.
If you go to preferences -> advanced -> error reporting -> follow the procdump related instructions or you can run wacup.exe /procdump from the command-line within the WACUP program folder to do the same which'll then try to capture what might be going on when the currently unhandled close happens. If it does fail under it, the next time you run wacup it'll then auto-submit the crash report but it'll be helpful in this instance if you can also manually pm me a copy of the first one that is created.

Just discovered this was my fault - I've just forgotten to enable "repeat".
Oh so it was just getting to the end of the playlist then yes that's correct behaviour if repeat is off.

Yes, the files are there, just not selected. I made videos with that problem and the problem with opening multiple files from folder:
That looks like it's how Win11 might be handling things against the OS api call with the second video & I don't see anything obvious from a quick search of the api I'm using that'd explain it not pre-selecting the files. For that I don't have a suggestion on anything else to try out at this time.

With the first of the videos, multiple selections from explorer are a mess across all of the Windows versions that WACUP is supported to run under & also likely relates to the lack of OS file association integration. From my notes, a selection of between 10 & 15 items is the maximum before the OS typically expects a shell extension to be provided even though it could just call WACUP with a multiple list of those files as it does for smaller selections. The newer the OS the lower the limit seems to have become.

I don't remember if there was a registry setting that could be used to change that OS behaviour or not. So this is working in an expected broken manner as the handling currently is solely relying on the OS / Explorer providing the full list of the files & I don't have any direct control over that. Tbh it might be a bit of a handling change but drag+drop is going to be more reliable to do things.


I think I've got a quick change that'll do what's needed & so far seems to behave in keeping the songticker text as expected & not changing the 'current' item from the first item to the first item in the shuffle list by avoiding immediately creating the new shuffle list until after the current item has stopped playing when playback is active. If it's not playing then it'll act like before & live update things as I just prefer that.


If the next button / hotkey isn't working then something is blocking the action from being run which shouldn't be happening & implies to me that either the skin being used is broken (possible if it's a modern/winamp3 style of skin) or that a plug-in is breaking things. What skin are you using & also have you installed any 3rd party plug-ins &/or enabled the built-in streaming mode that WACUP includes?

-Opening multiple files from folder only leads to 1/2/3 files being played and not all of the files selected.
Could probably do with a short video showing this issue then trying to get you to further describe what's going on please.

-Clicking "Explore item(s) in folder opens the folder, but without the song selected.
Which part of the program are you triggering that action? Also are the files actually there or are they missing? Though if it's opening the folder then that probably means the files are there (as there's a change for the next build to deal with opening a folder with passed in missing files) & it might be a Win11ism screwing with the api that's used &/or the OS api isn't working & wacup is reverting to its fallback handling to open the parent folder which via that mode cannot select the files.

-On two underpowered laptops, manually skipping to next song leads to crash if I skip 3-4 songs. Doesn't seem to occur on my everyday PC.
Are those generating crash reports? If they are then I could do with an example copy via pm please. As wacup will try to auto-upload copies to the site server but I don't really have context on who a crash report relates to so for this it'd be easier if it has created some to get a copy. Preferences -> Advanced -> Error Reporting -> that has a link to open into the wacup crash reports folder if there were any generated.


What action(s) are you trying to use for "Refresh Library" aspect? As the options which specifically refer to refreshing only involve metadata & will not add new files into the local library unless you're meaning the folder monitor / import folder actions?

If it's the folder monitor / import folder actions then as long as the file(s) can be seen they should be being added in unless the flac input plug-in is missing &/or preferences -> media library -> local library -> supported files type tab is not showing FLAC as an enabled option.

You've also mentioned "long album title", is that within the file metadata or as part of the actual file path? As I currently only support file paths up to 260 characters & don't really have things in place for super long file paths (though there's an attempt to get the DOS 8.3 filename as a workaround). If it's within the file metadata then I effectively don't have a limit on the string length that can be read so I could do with some clarification on what's actually involved please.


Can confirm it only seems to be causing the visual issue on the first playlist item so that might just be an off-by-one issue in a check or it's part of having tried to avoid other complaints of it re-selecting the current song for some handling issues (i.e. always picking the first playlist item when a new shuffle list is created).

However I do need to clarify that once shuffle is toggled then any prior knowledge of what might've been played so far is essentially lost or if it was already off & then enabled there's nothing to work from. So it is possible for it to replay the current item again though I thought I'd put in some handling to try to account for this which might per my note above be why it's messing up only on the first playlist item. As shuffle is just the current playlist randomised but done in a manner so the playlist's visual order is not modified whilst allowing the playback order to be changed.

Will have a look into this properly before the next build.


That's good to know it's working ok. Will move this into the implemented request sub-forum.

I've still got re-ordering of the bookmark categories to do but that's out of the scope for this request (which did also catch allowing the local library sub-views to be re-ordered as well).


Wishlist / Feature Requests / Re: Toaster plugin
« on: July 13, 2024, 03:53:25 PM »
Can I ask roughly what OS aspects have been disabled as I'd have still expected the notification / action area to still be available though am wondering if there's some setting that effectively hard-disables all of that which could explain why it's not working for the few who've reported an issue (which afaict might be related just to win11 setups).

PS i cant believe whats happend with the orginal winamp right now...  ::)
There is no original winamp & imho as that's been dead for just over a decade now (irrespective of restarting desktop development & then ditching everyone over a year ago & then this "source available" mess they announced a few months prior (nothing that afaict would ever help nor be permissive towards WACUP development).

What now calls itself "winamp" is imho just trying to ride on the remaining good will that some have for the brand when they've still got a fixation on nft / crypto related crap to still go into their mobile apps according some details I've seen reported from a video call made ~ a week ago about their "new" creators platform.


Preview Build Discussion / Re: Issues playing Hi-Res WAV
« on: July 08, 2024, 06:22:13 PM »
Try Preferences -> Plug-ins -> Input -> WAV -> check the option at the bottom of that to see if it helps.


Pages: [1] 2 3 ... 107