WACUP
Preview Build Discussion => Preview Build Discussion => Resolved Issues => Topic started by: DJay on May 15, 2025, 06:40:18 PM
-
I have another problem related to launching after updating to the latest version. The first start of the WACUP after logging into Windows takes me over 30 seconds from clicking the program icon. After closing it starts quickly every time.
-
I'd not seen this within the other thread it had been posted in which afaict isn't related to what was being reported in that thread (likely 3rd party plug-in issue). Assuming it is happening with the current preview build (21640 as of this reply which I've taken from the other thread this was posted into) then there shouldn't be anything obvious going on from my handling that'd have it waiting for so long unless there's something within the main playlist / aspects in use that might be trying to access a slow to respond device or network share & even that seems less likely as I'd changed things a while back to avoid on loading aspects to happen which might be able to hard block (unless you're using a modern skin, no local library & it's designed to show metadata from the currently playing item & then maybe that can be slow / block on the OS waiting to respond).
Basically I need a better idea of the setup involved though when the OS is first starting there's nothing cached & that's been seen in some aspects to be slow but not to the point where it's going to hard block until starting it over again during that OS instance.
-
in my opinion it works and starts faster up, than the commercial winamp version
;)
.
-
A few days ago the problem disappeared, just like that. I didn't change anything in the config or anything at all. I run WACUP every morning and get to work, usually it starts on the Bookmarks screen, then I start one of my favorite radio streams. The system and the program start from a fast NVMe drive, I have the media library on another large HDD drive. Folders with files are added to "Folder Monitor", but monitoring is inactive. I prefer adding folders via Local library>Import folder... That's all I can say, at the moment I am unable to reproduce the problem, previously it was as above, the first start after logging into Windows took ~30 seconds, the program hung in the "Not responding" state at that time.
-
Maybe there was a Windows update or something else updated that wasn't obvious. As it's no longer doing it I'm going to move this to the resolved issue state as there's little else I can do. If it does come back then you could try to use the create dmp file option from task manager, compress the dmp file & try to send a copy of it to me so I can see if that maybe gives a hint on why it's acting up otherwise fingers crossed it doesn't come back for you.
-
Unfortunately, the problem returned right after updating to 22022. I have a ProcDump dump, I will send you the file via PM.
-
It's showing as being stuck in an OS api call used to pre-load a supporting dll the wacup core needs though I'm not sure if I still need to be doing that any more or not for which I'll have to do some testing to see if it can be dropped now. I don't however see why the OS api call is just sitting there other than maybe it's something with an a/v scan check or something else which isn't showing up in the dmp callstack info.
-
I was wondering if it had something to do with dual monitor desktop, but the problem occurs when running on both primary and secondary.
-
I use a dual monitor setup daily so I'd like to think I'd catch that being a problem & with what the dmp showed the ui aspects hadn't yet been created & is just that something is causing the loading of the needed dll to just take far too long which a first run after an OS restart makes some sense from A/V software needing to update definitions / start scanning vs drive caches still waiting to be built-up. So far not doing the pre-loading of the dll doesn't seem to break things from what I can see with testing but I suspect you're still going to have issues since I can't really determine why the OS call to load the dll was just sitting there & it's just me guessing on a few things for the time being.
-
I mentioned dual monitor desktop because I run WACUP on a secondary monitor, and when this problem occurs during startup, I often see a black media library background (!?) on the primary monitor for a moment, and then nothing, because it stops responding. After half a minute, it reappears on the secondary monitor, but often in stages, because, for example, everything appears except the contents of the media library window.
I did a few OS restarts and it seems that when I run WACUP in safe mode, the problem doesn't occur. It takes a bit longer to start, taking ~3 seconds, but it doesn't go to not responding state.
-
Did the recent build 22222 make any difference for you or not?
-
As before, about a week ago, the problem resolved itself. Unfortunately, it returned immediately after updating to 22222 the day before yesterday, if I remember correctly. It also started crashing while streaming the radio. I have some dumps from the crash report, which I'll send you.
-
The one dmp in there that resolved correctly is related to the known issues for the build (not that it's necessarily new to it) & it appears what'll be the next preview build is likely to resolve the streaming related problems. None of the dmps provided or ones I've seen on the server appear to relate to what I'd seen in the prior one so I still think there's likely some sort of OS / external scanning going on that's out of my control which is causing the initial slow load during the first run but the stream / playback crashing issue is on me & hopefully is fixed.
-
Up until version 22222, I never had a problem with streaming. The way my radio playlists from bookmarks are displayed has changed. Now, they seem to display part of the URLs after the last slash.
The top is as it looks now, and the bottom is as it was before.
(https://kilos.pl/pub/wacup-playlist.jpg)
-
Just for the record, latest build fixed my loading problem and the previous one fixed the streaming issue.
-
Thanks for the confirmation that things appear to be behaving now. Will move this into the resolved issues section.