Crash on exit + long playlist loading time

[Abilio_KID]

Since the last 2 preview versions, WACUP always crashes when closing the program. Either by file/close or by pressing the close button.
Another issue I have is the fact that, everytime I start the program the first time (usually after a reboot), WACUP insists on checking my long playlist file by file, making it a lot longer to start playing anything. This doesn't happen if I re-start the program a second time (even if it had crashed again on close).

Crash report for WACUP Preview v1.0.21.7236

winamp.original caused an access violation (0xc0000005) in module ntdll.dll at 22/3/2021 01:17:34 for user "Abilio_KID"
Write to location 0x00000014 caused an access violation.

[dro]

You're the one from my list of recurring crash reports It's because of the out_mixer.dll plug-in (which I assume is just a different variant of the matrix mixer plug-in) & a conflict with wacup's directsound output plug-in. I've yet to get to the bottom of the issue as it seems to happen consistently for some but I struggle to replicate it locally

With the playlist handling, are you loading the playlist externally or just having WACUP use what was already there on closing ? Also have you altered the playlist reading options from the default? As there are some basic checks via OS apis to check for file existence to avoid doing other processing but it could also be a slowness due to external factors like the OS drive cache being built up &/or other programs that are being triggered.

-dro

[Abilio_KID]

Yeah, I'm using Matrix Mixer... I disabled it and it stopped crashing (will see after a reboot tomorrow).

Hmm... the playlist is huge. Can't remember but I think I dragged and dropped the main folder over the program, randomised the list, then started playing it.
Is there a setting that forces WACUP to open the playlist and only check each entry when playing it? Like, not even checking at startup if the files really exist.
Got a feeling that the crash may be corrupting the temp winamp playlist on exit or something (just guessing). I will check tomorrow.
Thanks for the help.

[dro]

There's the options on Preferences -> Playlist -> Titles | ATF to control how reading is done which might work but even then the normal loading of winamp.m3u8 (which is what stores the main playlist editor contents) could be triggering a check especially if there's missing titles due to a missed save from the crash.

How large of a playlist are we talking about & are they only local files without anything might be related to a network drive, etc. I probably will need to do some more investigation on this & luckily (or not) one of my test installs is showing a weirdness on loading but that happens all of the time though might be related (we shall see). As restoring the winamp.m3u8 is meant to be quick irrespective of what might be within it.

-dro

[Abilio_KID]

For now I'm not using Matrix Mixer, to avoid crashing. Its main purpose was to custom configure 5.1 upmix (there was too much centre speaker). For now I'll have to rely on Sound blaster Z "Surround" for that.
In ATF settings I already changed to "Read metadata only when file(s) are played" but the long loading still happens. Mind you, this is only at first time I start WACUP. If I close it and re-open it, then the loading is fast. It didn't happen a few versions ago.
Is 41180 songs too much?

[dro]

It didn't happen a few versions ago.

Each build changes out how much is WACUP vs Winamp doing things & it's a bit tricky at times to really compare what's going on under the hood vs it all visually looking the same.

That's actually a large playlist. I just see a lot claim large & it's a few 100 files. Could you PM me a copy of the playlist file please & I'll have a look over what playlist entries & info is in there to see if anything jumps out (also it'll be useful to see if there's anything I can do to better optimise the loading of such a large file ).

-dro

[Abilio_KID]

Hmm... I decided to compare the playlist in "C:\Users\Abilio_KID\AppData\Roaming\Winamp" with the one saved from WACUP to disc. The Winamp one has the full path to each file entry, the WACUP one doesn't? I mean, WACUP knows where the files are but if I save a new playlist to disk it won't have the full path?

winamp.m3u8:

#EXTM3U
#EXTINF:241,Lali Puna - Awaiting An Accident (Remix Fo
F:\Pedro\sons\Musicas\Lali Puna\2005 - I Thought I Was Over That\CD 1\04 - Awaiting An Accident (Remix For Boom Bip).mp3

WACUP saved playlist to disc:

#EXTM3U
#EXTINF:241,Lali Puna - Awaiting An Accident (Remix Fo
Lali Puna\2005 - I Thought I Was Over That\CD 1\04 - Awaiting An Accident (Remix For Boom Bip).mp3

It's probably un-related but shouldn't the full path be in the entries?

[dro]

Depending on where / what it's being done from, absolute or relative paths will be used. Neither is much better than the other as it also depends on what is done to the file & those referenced in it.

-dro

[dro]

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).

-dro

[dro]

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).

-dro


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

[Abilio_KID]

I will check those 2 options and then test it after a reboot. At the moment I'm doing some important work on PC (I work from home) so I have to do it later. As for the time it takes on the HD... my music library is stored on a 1 TB HDD, not an SSD. It's a big collection that I've been putting together for about 20 years or so^^. I have 3 SSDs but none of them has music.

[dro]

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.

-dro

[Abilio_KID]

Well, here's the log:

[dro]

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

-dro

[Abilio_KID]

After a defrag:

Main Playlist:   40974.785ms