Latest WACUP public preview for x86 & x64 is build #21136 (March 9th 2025) (x86 & x64 changelogs)
Latest restricted WACUP beta release is build #21254 (March 29th 2025) (x86 & x64 changelogs)


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.

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] 2 3 ... 116
1
Maybe you could try using either the global hotkey (configured via that preferences page) or using the notification area icon (if enabled) that can be setup to remove the current main playlist item to see I that'll work without going into explorer to try todo it. As that should also force clear any internal handles that I know about.

2
The x86 installer should've installed the re-used in_mp3 as needed unless that went wrong & the 5.666 installer couldn't be obtained so copying dlls shouldn't have been needed. The x64 build doesn't have tagging support for mp3's nor does it have a proper plug-in to handle those files which is why it's different to the x86 build for now.

3
If you're doing it whilst the file info dialog is still open then that is usually going to have the file in an open state because it might be trying to make edits. Tbqh I've still to actually look into this myself so I don't know why it'd be keeping a handle on the file vs how I've tried to code things.

4
General Discussion / Re: Importing Local Library .csv
« on: Yesterday at 10:06:07 AM »
There isn't an equivalent to the ml_impex plug-in & it's xml file handling in wacup nor have I gotten around to coding a csv reader to match.

5
Preview Build Discussion / Re: [Issue] Local Library completely blank
« on: April 14, 2025, 06:24:53 PM »
It means the local library db & the backups are basically borked. You'll have to go into <wacup_settings folder>\plugins\ml & find all of the library.dat & library.idx files along with any with the .backup name & move them out of that folder & then you'll have re-import the files you want in the local library as I can't re-create the db files if it's staying in the above state since it's already automatically trying to use the backups in that scenario.

6
Preview Build Discussion / Re: WACUP is almost perfect, 2 minor issues
« on: April 14, 2025, 06:22:25 PM »
Try going to Preferences -> Plug-ins -> Input -> find in_mp3 in the list & un-check it & then close wacup. Then try replicating your issue again as that's the simplest way to try to determine if it's that input plug-in or not.

7
Preview Build Discussion / Re: WACUP is almost perfect, 2 minor issues
« on: April 12, 2025, 09:51:13 AM »
Does this mean it's not getting added in the future since I'm the only soul who is still using it or are you guys busy with much more important stuff and It will eventually come?
The aim of the preview build was to not screw around with existing settings especially when it was starting out as a plug-in pack for 5.666. As such I don't have any code in the builds that can register what file types WACUP can handle but there are things in place to allow for manually associating it if that's wanted (e.g. the open with option the OS provides & then the options on preferences -> general can be changed to adjust what the default behaviour in response to command-line actions is using). At some point I'll get around to completing the feature along with having to look into implementing a shell extension to resolve other problems with trying to process many files which the basic command-line behaviour doesn't cope well with in recent Windows versions.

I only play mp3 files, no idea if it happens with other formats.I'm using the latest build (1.99.27.21136 (x86))
Are you also looking at the metadata &/or making changes to the metadata of those MP3 files?

8
Preview Build Discussion / Re: WACUP is almost perfect, 2 minor issues
« on: April 11, 2025, 06:50:02 PM »
1) This is noted as not being a thing in the build related information shown during install of the preview build.

2) That shouldn't be happening & I'd need to know what file type(s) it's happening with as I'd resolved all instances of files being held onto that I could replicate (there's still a window of a few seconds after a file is accessed due to me caching access to them to make repeated metadata queries not have to take as long again during that time) otherwise the access to the file especially if playback has stopped shouldn't leave anything in a held open state (unless it's maybe a bug with the re-used in_mp3 again). Would also need to know what build of WACUP you're having this issue with.

9
General Discussion / Re: Wacup in IDLE uses up performance
« on: April 10, 2025, 06:24:06 PM »
winamp.ini isn't used to store the modern skin settings, they mainly go into the studio.xnf (I could do with a copy of that file if possible please) & if the WMC skin main window has gotten into that state then it trying to potentially fill so much of the screen many times a second would likely explain the high cpu load & not being able to dock windows to it since the bottom is however far off the screen bottom.

It's not something I'm seeing from a quick re-test but iirc it's been reported a few times over the years along with happening to some of the other modern skins due to the gen_ff plug-in randomly screwing up yet I've still to start on trying to make my own replacement plug-in.

10
General Discussion / Re: URL/Podcast streaming difficulties
« on: April 10, 2025, 04:47:32 PM »
The lack of seekbar on the direct url is because I've not yet implemented http seeking support into my streaming playback support which is why there's no seekbar shown. Comparing to "winamp" isn't fair in this instance as I'm slowly making my own in_mp3 replacement & what the x64 wacup build offers is what I've currently got. Using the x86 wacup build which can re-use the in_mp3 from 5.666 might be better suited for your needs for the time being as the x64 build isn't fully feature comparable to the x86 build. As for playback stopping, I've probably got more to do on how the buffering vs keeping the connection alive needs to work.

11
General Discussion / Re: Wacup in IDLE uses up performance
« on: April 10, 2025, 04:41:04 PM »
At least the ui code I've got direct control over seems to be working ok based on your numbers.

Something else you could try out when a modern skin is being used is to go to preferences -> skins -> modern skins -> general tab -> try using either the 30fps or 15fps option in the settings block at the bottom of that preference page tab. It'll make some aspects of the modern skin feel a laggy but unless you're really looking for it you might not notice it & if that does help to reduce whatever conflict is going on for your setup then I think it seems to point towards a painting related issue (am wondering if it's the way the skin updates its main vis area).

12
Skins / Re: Quinto Black CT
« on: April 10, 2025, 03:32:57 PM »
Line breaks in the file shouldn't have changed as that's not something I can see my hooking is touching. As all that does is hook the call used to open the file, see if it's the studio.xnf file, make a backup of the current file & then let things continue as if I wasn't there . Nor should a line break change be affecting things in usage as the xml library afaict doesn't care if they're \r or \n or \r\n & just loads the file. So no I don't think I need to see a copy of the file & depending on what you're using to compare file differences, there probably is an option to change things to ignore line break differences (e.g. winmerge has such an option).

13
Wishlist / Feature Requests / Re: Options for the Lyrics Plug-in
« on: April 09, 2025, 05:22:11 PM »
I don't need to prune the entire cache, I just wanted to prevent the empty files. What would be considered too large a cache?
I don't focus much on the size of the cache folder though the changes made are based on the lifetime of the files instead of basing it on the size which should under normal playback not cause things to grow too large whilst avoiding re-querying things too often if there's been no changes.

I have been deleting the empty files to force re-querying for lyrics in case they may be found later, when the same files are played again. I understand why you don't want to trigger multiple online look-ups. I think it would be worth the resources used if lyrics are found later. I will stop deleting the empty files, if you think the re-querying will lead to crashes or other processing errors in WACUP. Wasting directory name space is worth it if it prevents WACUP processing errors, imo.
You can remove the files as you need to & my code shouldn't be crashing. I was just trying to explain why it does things like it does for the moment especially since it's also quicker to check vs storing things in db files (which have their whole set of downsides which is why I also use a folder cache instead of db for artwork as ml_local did).

14
Wishlist / Feature Requests / Re: Portables Support
« on: April 09, 2025, 05:07:52 PM »
Thank you for your help I have been able to get the portables plugin working (at least as well as it can), but have found that it has terrible support for parsing metadata from flac files for some reason. Since this plugin is outside the purview of WACUP support I'm just leaving information here in case anyone in the future runs into a similar problem. The flac files on my thumb drive (even when pmp_usb is given the added configuration to read flac files) are all given the WACUP metadata of a single flac file in the outermost directory of my music folder in the thumbdrive. Even when I delete said flac, the rest of the flacs that are further nested in the USB drive are left with their WACUP metadata blank. It's quite frustrating! I have tested the same plugin on Winamp however and it does properly read my flac metadata there (v 1.6 on Winamp, 1.61 on WACUP so I don't expect the version difference is to blame but maybe?)
I don't remember enough about the portables plug-in but it rings a vague bell with some of the files processed via it not being tagged correctly which afaict shouldn't be down to WACUP doing something wrong otherwise getting metadata from FLAC's into the local library, etc would always be wrong. It might even be something that's down to how the portables plug-in copies things over that's at fault but I really don't know & this just mounts up as another reason to ditch that whole set of plug-ins.

P.S. My previous post stating that the 32 bit installation includes the portables plugin only on the portable installation seems to have been erroneous. I've reinstalled and it is now there on the main release. I swear it wasn't when I tried earlier but I couldn't tell you why. Perhaps when I looked I had accidentally opened the 64 bit release.
That is likely because of trying with the newer WACUP build & it had some changes with how it tries to get some of the installer files to resolve issues where it wasn't able to download them previously. That's the only obvious thing that I can think of to explain them appearing.

15
Skins / Re: Quinto Black CT
« on: April 09, 2025, 04:56:29 PM »
Eh? I've not changed the format of that file afaict since it's still being written out by the gen_ff plug-in (which is the part I hook into to be able to make a backup of the file but it's format shouldn't be different otherwise things wouldn't be able to be read back in correctly). I would like to change the format so per-skin aspects are stored in their own files (but that brings problems with some that re-use the same values for some of the switching modes like bento to big bento) but that's not something I'm going to try to hack around whilst still using gen_ff.

Peter's stance on the studio.xnf removal requirement has always been at the detriment of any other modern skins which is somewhat selfish for those that do swap & change their skins or like to customise them from default which ironically imho also impedes using his skin vs any customisations that may have been made by the user.

If it's a key requirement when installing that skin, why isn't the installer force removing it? Since that's what an installer can help facilitate even if from numerous experience, people don't like their settings being screwed around with but if it's an install requirement then so be it.

Pages: [1] 2 3 ... 116