Latest restricted WACUP beta release is build #16956 (September 23rd 2023) (x86 & x64 changelogs) | Latest WACUP public preview is build #16956 (September 23rd 2023) (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 ... 97
1
What skin specifically are you trying to use & get working as you want ?

-dro

2
Hmm, that doesn't however determine what is actually going on to cause such a leak & would normally need to be adding in millions of files un-checked which shouldn't be possible to do (unless something else has gone awry). At least I can probably discard dsp_wc / audioscrobbler being part of the problem as I'd just been looking into.

So what is it about the setup that's triggering the issue... as the most obvious things are either albumart handling issues (e.g. massive images) whilst trying to determine what is present for the files or that I'm just missing a dumb bug somewhere in freeing a value (or multiple values) &/or is related to a specific type of file &/or an internal api failure which I'm not seeing going wrong.

As I've just tried re-scanning my 320k test db & that's not showing an obvious memory leak (just the duplicated db copy that's expected when processing things causing my install go from ~0.6GB used to ~1.2GB used). I'll have to try out some things with the folder monitor tomorrow as I need to get some :zzz: now.

-dro

3
Ah you're likely the one with the out of memory issues for which you win the unenviable honour of having the first beta preview build crash report.

Can you detail what steps you're doing or had done please as the crash reports sadly don't give me that information, just that something has caused a full process memory leak (not something that's been seen in such a manner during any of the beta testing). As I can't see anything at the time of the crash indicating the local library is doing an import but it might be due to the memory exhaustion issue that it's masking what's actually going on.

-dro

4
Preview Build Discussion / Re: Latest preview #16956 crashes on close
« on: September 24, 2023, 11:45:12 PM »
Do you have gen_g15_ray.dll present in your install ?

-dro

5
General Discussion / Re: Separators?
« on: September 21, 2023, 01:07:52 PM »
The separator option could get close to achieving it but it'd act as a whole playlist entry & isn't an integrated element per the image which'd cause the playlist item position to look wrong.

At some point I do want to make for opt-in richer playlist items with multi-line support & even possibly getting albumart into them but I don't have an eta for getting that done.

-dro

6
Wishlist / Feature Requests / Re: Winamp DSP Spectrum Tool
« on: August 28, 2023, 12:24:22 PM »
It's probably due to the non-english character in the plug-in filename. If I change it to just be dsp_tool.dll then it will work in the above example install. It however doesn't avoid the issue that if it's run under a process that's got DEP/NX-bit enabled it's going to mess-up & I'm not going to change how WACUP is built to disable that. I did mention that there are things that can be done but it's not something I've got the time to commit to doing when I've got so many other things already on my todo list including trying to get WACUP to the point of being able to offer a new preview build. I appreciate that it's a plug-in you like & I can see it's usefulness, this is just one of those things were very old winamp plug-ins can be a headache to try to keep going.

-dro

7
Wishlist / Feature Requests / Re: Winamp DSP Spectrum Tool
« on: August 27, 2023, 11:54:54 PM »
I'm guessing the serial key is stored in the registry or somewhere else then as when I do see the plug-in loading it always nags & then kindly wipes my main playlist to play it's mp3 file (good thing WACUP has a playlist undo feature enabled by default). I quickly tried the above (it's not super portable imho vs what I'd deem to be truly portable) & that won't ever get the plug-in to load.

However, the reason that Winamp after a time & why WACUP out right won't load it is because the plug-in dll due to it's need to unpack itself doesn't work well if DEP/NX-bit handling being applied (aka something that XP SP2 introduced). So it's not something that can be easily fixed as the way the plug-in dll works when being loaded is not compatible with how Windows has been working for the past 19 yrs or so. There might be tools out there that can try to get the decoded dll & then reconstruct it into a dll that could then be patched, etc but that's not something I'm going to try to do nor am I certain if that'd be able to generate a reliably working DEP compatible dll after any additional tweaking (would be more useful using that time to make something equivalent imho).

So that would by why it's not happy in being loaded & it's given me a few things to refine in how I'm dealing with misbehaving plug-in dll loading.

-dro

8
Wishlist / Feature Requests / Re: Winamp DSP Spectrum Tool
« on: August 26, 2023, 02:30:01 PM »
From a quick check, the provided dll from the 7z never loads for me even when trying it in non-WACUP installs. Is that meant to be a cracked version of the dll ?

I found the installer version of it (where it's called dsp_tool & not the dsp_tcool though the c is a non-english character from what I could tell) & even with that I can only get it to load in a 2.95 install & it refuses to be loaded by a plain 5.666 or a number of WACUP installs. Under a quick debugger check its

The plug-in dll itself seems to be compressed in some format I've not come across before (not upx but that sort of thing) which might be part of the problem especially with the age of the dll. From what I've seen so far, it might that it's expecting something specific but right now I don't know what especially as the dll loading failure is happening before the WACUP core has even had a chance to try to call it's plug-in instance which makes me have to assume it's likely related to the dll unpacking process that's being attempted.

I will have to come back to this at another time but right now I can't really give a reason for why the dll won't load. I would however like to have WACUP offer some form of spectrogram type of view natively which seems to be how you're using it but it's not a top priority for me to implement for now.

-dro

9
General Discussion / Re: Main window - ghost bar
« on: August 20, 2023, 01:49:16 AM »
The window visible states aren't typically down to the studio.xnf file & setting winamp.ini (where most of the plug-ins responsible for the windows save into) to read-only would not be a good idea. I've also now added a /FIXWAMODSHADE command-line option that'll check & fix as needed the bad value for any identifiable winamp modern based skins whose config is present in the current studio.xnf file.

-dro

10
General Discussion / Re: Main window - ghost bar
« on: August 19, 2023, 09:40:13 PM »
I've now had a look at the xnf files & have found the line that caused it - specifically the height was being incorrectly stored (the value should've been 25 whereas 38 was in the file) & it seems like a random modern skin engine failure. As I can't see anything in the skin script files nor the xml files that define things which would allow the skin to override it as it's defined in one of the xml files to 25 so a weird skin engine issue seems to be likely.

-dro

11
General Discussion / Re: Main window - ghost bar
« on: August 17, 2023, 10:21:19 AM »
The additionally reported issues are all down to the modern skin engine plug-in though it's not something I'm seeing considering how I abuse my setup (maybe it's a problem related to using minilyrics?). Alas I don't have a proper solution to offer you for those problems other than trying to set the file to be read-only _but_ that is then going to break things if you change certain skin related settings & I'm not 100% certain that the skin engine is even going to adhere to that. So if that's attempted, you need to setup everything correctly, allow it to fully close & then apply the read-only state on the file & then start things again. The other option would be to make a backup of the studio.xnf file once it's good & if things mess-up then just restore that copy back.

-dro

12
General Discussion / Re: Main window - ghost bar
« on: August 16, 2023, 09:25:35 PM »
Go into the WACUP settings folder (found via preferences -> advanced -> diagnostics -> settings locations tab) & move the studio.xnf out of that folder & then try running things again. That'll reset _all_ modern skin related layouts but might fix the issue. If it does, can you then pm me a copy of the removed & the new studio.xnf files so I can at least try to figure out if there's anything within the xml that might be causing the skin engine plug-in to act up like it's doing (even if it's maybe allowing me to implement a helper mode to parse & fix the studio.xnf file without having to wipe it when things go wrong).

-dro

13
At some point it should happen but other things need to finish being replaced before that'll be started on (i.e. I need to get WACUP to no longer be re-using the in_mp3 plug-in from 5.666 which is the one that is responsible for MP3 & AAC based stream playback as the old BBC urls were provided over).

-dro

14
If you've installed WACUP as a portable install then you'll need to go to Preferences -> Advanced -> Portable Mode -> check the option to allow 3rd party plug-ins & allow it to restart which should then allow those DSP plug-ins to be used. Because so many 3rd party Winamp plug-ins never followed nor got updated to follow the common settings file location apis (e.g. storing in the registry), WACUP's portable mode won't allow those to be used unless opting in as I can't guarantee that the portable install is then truely portable.

-dro

15
I didn't expect it to be actually fixed because it's something fundamentally wrong with the skin / it's scripts vs timings / metadata interactions along with the problem that gen_ff has in using a shared buffer for metadata requests which is not thread-safe i.e. different things can go on & overwrite that memory whilst another action is already trying to get the info - that's why whichever script it was that got changed in this/another skin fixed the metadata being wrong as it's altering when those metadata calls are made & avoids the gen_ff core implementation design failure.

-dro

Pages: [1] 2 3 ... 97