If installing the 32-bit / x86 build of wacup (i.e. the version from https://getwacup.com/preview/) & don't change the install settings then you should already be getting the winamp modern skin as long as the installer is able to pull down the skin files needed & either having chosen it from the skin selection prompt on the first install of wacup or by going to the skins submenu or skins preference page to select it.

If you installed the 64-bit / x64 build of wacup then per the notes on the download page & in the installer it can only support classic / 2.x style skins (which is what the left part of the screenshot looks like with it being the 'classified' version of the winamp modern skin (on the right). This is where you need to use the 32-bit / x86 build of wacup & just getting & running it's installer should get what's needed without having to uninstall as they can share the same settings folder to avoid losing anything that might've already been done (e.g. local library imports &/or custom metadata having been entered into it).

---

As for the sizing of things, wacup tells Windows to not try to apply dpi scaling so if using a classic / 2.x style of skin then you've got 1x/2x/3x scaling modes. If using a modern / winamp3 style of skin (as the shown 'winamp modern' skin falls under) then you can change the window scaling either from the main right-click -> window settings -> scaling menu or by going to preferences -> skins -> modern skins & changing the scaling option from there.

---

The final thing about dual instances & things going to a different one, firstly you can run multiple wacup instances using the new instance (via ctrl+alt+n) option & following the prompt to make it duplicate the settings folder to allow for a better dual instance setup.

If you do want to run wacup + winamp at the same time then you're going to have to change the window class that wacup reports for plug-in / external tool compatibility to be different from what winamp reports so the running winamp instance isn't then going to know about the wacup one.

That can be changed by going to preferences -> advanced -> portable mode -> use the open paths.ini editor, change the 'wacup winamp classname' to something (e.g. WACUP not Winamp), save & then restart the wacup instance. That will then make the winamp instance not find the wacup instance & hand off things to whatever is found to be the first 'winamp' instance which is how external file loading works when the option to prevent multiple instances in either program is enabled. It can alternatively be done via wacup command-line options when applied to the shortcut used to start it which is also something that can be used to run dual wacup instances against different settings folders without having to manually do the new instance action mentioned earlier.

Sort of is the simple answer. 1.99.36.22278 is the last build that attempted to install & apply the patches needed on the various files from the 5.666 installer (i.e. a build from over a year ago which isn't supported at this point) along with when it is installed it'll usually be set to be disabled by default which can be changed via preferences -> plug-ins -> input if in_nsv is in the plug-in list.

The problem is that the recent installers remove some of those files even if the intent from the user side is to keep them around along with me doing no testing against in_nsv as I either rely on the directshow filters for local files or I'm ok with the audio-only playback of the streams that my in_url plug-in provides.

The simplest option vs trying to piece files together & missing on them being patched as needed would be for me to not remove the files the installer is removing & change how the plug-in is flagged as not to be loaded by default to avoid the problems I was having with in_nsv that led to it being removed. That would then allow installing 1.99.36.22278 & then installing the next preview build back over it & if needed manually enabling in_nsv (since the core still has the handling to enable the other dlls it needs) vs the handling that is now in place per the prior paragraph). Or use an old build that supports it & hope the build picked behaves.

It's just that time of the year where the prior year's "oh I forgot to pay it again' payment is up for the vBulletin hosting. As for the other aspect, it's not the OP's fault what is or isn't going on when it comes to spam on that forum nor how some mods are too ban happy vs maybe applying some nuance but hey they can do whatever they want with that forum as I'll do with what I'm providing.

Ok, thanks for letting me know it's ok now for you.

I cannot replicate it with the post-release updates applied against the current build 25346 per the instructions on how to get it from my initial reply.

The new in_url plug-in has now been put up as a post-release update for the 25346 build which should make that stream play correctly along with a fix for shoutcast style stream metadata not being handled correctly if it's too long which should resolve a number of streams previously not being able to play or would briefly play & then it'd end up doing nothing due to it not correctly adjusting the output buffers.

The local library plug-in currently only supports importing supported files / playlists / folders / existing local library db file imports. If you don't have the existing local library db to use (typically in the settings folder of a prior wacup install) then any custom metadata from it isn't going to be able to be re-added via the other options that otherwise exist for import.

At some point I need to add a means to support importing the exported csv file that the export action is able to generate which would then fill the gap that exists from not having an equivalent to what winamp did with it's xml based import / export feature.

Testing with the current 1.99.56.25346 build there's a small mismatch between what the stream is reporting as it's channel count from the connection header vs what the aac decoder is reporting with some of the initial frames. That's causing it to do some output setup based on it being a stereo stream whereas those initial frames are making it treat things as mono which is why the playback rate isn't correct for it.

I need to do a bit more testing but I'm planning on providing a post-release update for the in_url plug-in which should resolve this problem (it'll either appear as an OS toast prompt or can be manually triggered via Preferences -> About|Updates -> About tab once it's available).