Latest WACUP beta release is build #8282 (July 23rd 2021)

Latest WACUP public preview is build #7236 (March 11th 2021)

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 ... 3 4 [5] 6 7 ... 79
That's odd as there's checks made on the ytdl exe to avoid such situations. I'll have to recheck what's going on though the main thing is your sorted.


The modern skin colour editor like most things modern skin related is hit & miss in how well it works. So it'll either crash always for some or it'll be fine for others. Its included as it can work at times & having it present avoided the issue of going to winamp's forum to try & find it.

File association / shell integration isn't a provided mode (it should be in the notes shown during installation) with WACUP because trying to have the WACUP & Winamp cores interact nicely with each other isn't happening & so I've basically blocked the winamp core from offering associations until I've written my code to be able to handle things.

However it might still work depending on what action has been done & some find manually associating files works but it's not something I officially support & won't until I no longer rely upon bits of winamp to be running.

The other reason is WACUP is still only available in a beta / preview state & having something that is essentially always installed as a portable install is safer for testing between it & winamp & other WACUP builds.

Most of WACUP is more than useable & should function better vs Winamp's offerings of plug-ins but if explorer integration is a must then the plain patched 5.666 is probably a better option for you for now.

So until I've got a means to control the whole process from initial loading to parsing the command line / COM interaction & getting it into the main playlist, external integration isn't on my officially supported list of WACUP features & I'm ok if that puts people off from using it for now.

Hope that clarifies things in their current state.


General Discussion / Re: Seek bar during playback
« on: April 05, 2021, 10:12:44 PM »
Not needed as you're static image is already showing how it'll appear all the time.


General Discussion / Re: Seek bar during playback
« on: April 05, 2021, 07:13:36 PM »
Have you done as per my suggestion of the file to remove to see if that helps ?

As its not meant to be doing that nor can I replicate & am going on what fixed it for the one other user that I know had that issue. Unless there's something going on with mouse drivers / some other software that's on your machine which is triggering the action in the modern skin engine.


Skins / Re: Installing Quinto v3.6 for WACUP
« on: April 03, 2021, 01:14:52 AM »
Well that completely explains why some have been having issues getting it installed even with normal winamp installs if it's assuming a fixed path which would also break things on 32-bit versions of Windows (i.e. XP for those running retro setups).


Preview Build Discussion / Re: CrystalControl plugin issue
« on: April 02, 2021, 06:04:04 AM »
This is going to be interesting to try to resolve if it's related to hardware.

In reverse order, are you playing mp3s with replaygain enabled by any chance? As the vis plug-ins just get given what's been provided so it's more likely to be related to the plug-in for the audio being played as I don't mess with the audio itself.

With the title issue, I'm assuming this is an older plug-in (hadn't heard of it until now) so it's likely getting the non-unicode title. From looking at the OS apis it might be trying to use, it's possible that it's either not finding the window it's wanting (it's got a hard-coded check for the main window from a quick look at the info in the dll which shouldn't be an issue but it can be at times) or there's a difference in the title formatting string that's confusing it (though afaict I've got the default string to be the same to maintain winamp compatibility).

I'll probably have to have a proper look at what's going on under a debugger & try hooking the obvious OS calls I can see that might be related to determine if those are wrong or not.


That's only a 4 second variation & I've now messaged you with something to try out.

What it comes down to is when accessing an HDD or an SSD for the first time after a reboot, the OS hasn't yet got an in-memory cache about the files & folders on the drive which means it's going to be slow until that information is cached which will make it faster the next time around things need to be accessed.

So I'd say it's normal but an HDD makes it more noticeable & your setup vs the size of the playlist & what I'm doing is triggering a worst case response which I'm hoping what I've messed will help to improve the reported situation as well as subsequent loads once the OS cache has been built.


Preview Build Discussion / Re: horrifically mangled metadata issues
« on: April 01, 2021, 04:52:42 AM »
I'm going to have to chalk this up as an ml_local weirdness for now especially if it can work on a small refresh. You could try to use ml_ll & see what that does (preferences -> media library -> local library -> switching option at the top) but it'd need it's initial import nuked if that's triggered to then allow it to attempt it's own import & see what that does (which would then help to better determine where the issue might be coming from & ml_local's time is running out anyway).


So around 1ms per entry which seems high though I don't have an HDD in this machine to check against. From my SSD testing it's usually around 0.01ms on average & there's always going to be some variation but even still ~41s is still too long.

I'll message you something to try out once I've had some sleep.


That's over 3 minutes. That's worse than I was expecting.


When you can is fine :) Also the files all being on an HDD would make sense with what I think is going on as that is going to be much slower for the directory checks especially if there's no existing OS cache as a post-reboot would experience.


As a follow-up on this, I've made a change for the next build that hopefully won't break the behaviour I need to maintain (auto expanding a folder in s playlist) but also remove that check where it's reasonably certain the entry is a file (which should also help with offline / slow UNC paths).

From testing the change dropped a 1200 item main playlist from 33ms to 6ms (*) & a 300 item main playlist from 6ms to 2ms. If that does roughly hold true then it should drop things down to the 1-2 second range whilst also avoiding hitting the drive (assuming all titles have been read).


(*) The overall effect of the change since the playlist had some offline UNC paths was going from 4.6s to 6ms.

I've been having a bit of a look into this & as long as there's title information for the entry on reading then it does basically the minimum (i.e. accepts that & doesn't try to generate a title depending on the settings). However because of the things that can be put into a playlist &/or done externally, those items are checked to see if they're a directory or a file & I think that's the step that might be causing the slowness for you.

If you can do this it'll be helpful for me to get an idea of the time that it is taking. As a 41180 playlist on a reasonable ssd I calculate should be up to 5 seconds to be processed with the overhead of the checks that are being done. So if you go to Preferences -> Advanced -> Options Page 2 -> check the first 2 plug-in profiling options which also will profile the time to load the main playlist file.

Then do the process that you do to show the issue & attach or dm me a copy of the profiling_load.txt from your WACUP settings folder. That should hopefully give me a better idea of the timescale we're looking at & I'm also looking into adding a means to have the playlist items reported to make it easier to track down ones that are relatively slow (e.g. missing connections on unc paths).


General Discussion / Re: Seek bar during playback
« on: March 29, 2021, 11:52:30 PM »
I'm probably getting confused here. The ghost action as per the screenshots is absolutely correct unless that's being triggered by _not_ first having to have clicked on the seekbar. Best to wait for the OP to hopefully reply back to clarify things.


Pages: 1 ... 3 4 [5] 6 7 ... 79