Latest restricted WACUP beta release is build #18916 (April 18th 2024) (x86 & x64 changelogs) | Latest WACUP public preview is build #18916 (April 18th 2024) (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.

Author Topic: 1 minute startup with 145000 tunes  (Read 3365 times)

zikmen

  • Newbie
  • *
  • Posts: 1
    • View Profile
1 minute startup with 145000 tunes
« on: December 09, 2021, 03:36:27 AM »
Hi there,
New user to wacup and to the forum, I tried to search for that issue and did find some stuff saying it was resolved but it seems i'm using the last downloadeable preview and it isn't?

Well
Windows 10
Wacup Build 7236
Files sotred on a raid 5 hdd
When starting up, I notice from the Ressource Monitor that, during those 60-70 seconds, winamp.original process is accessing EVERY audio files i got and then, the UI shows up.

I had some slowdowns with the classic winamp... but they were not at startup but when clicking on "audio" from the media library... and it wasn't disk access but instead single thread operation taking a little time to compute as the media library didn't seem to be multithread coded... but i was fine with that.

If you could let me know what's going on, if you ever experienced the issue...
Thanks for your great work. Long life to Winamp
Tommy
Montreal, Quebec, Canada

dro

  • Admin / WACUP Developer
  • Administrator
  • Hero Member
  • *****
  • Posts: 4492
    • View Profile
    • WACUP (Winamp Community Update Project)
Re: 1 minute startup with 145000 tunes
« Reply #1 on: December 09, 2021, 04:03:46 AM »
It's a resolved issue within the betas based on some feedback I've gotten (alas around half of those having the issue who were given beta access to the fixed builds never gave me feedback to confirm if it worked or not for them) & relates to how the main playlist is read in on loading. The issue is due to it using some OS provided methods to check the validity & type of the path that is being processed & that call can be super slow on any network / shared drives.

-dro