Latest WACUP public preview for x86 & x64 is build #21640 (May 11th 2025) (x86 & x64 changelogs)
Latest restricted WACUP beta release is build #21640 (May 11th 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 ... 119
1
The skin only refreshes in that state or is it that WACUP is crashing & then restarting (there'd usually be a dialog popup indicating a crash has happened)?

I'm not seeing such an issue with the noted build so there's got to be something else going on that I'm missing for you to have such a bad experience.

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

3
If you manually stop playback then it doesn't matter as you note. It's doing as it says so if enabled & fading is applicable it'll cause things to wait for the playback handling to complete before everything else is then done as part of stopping which could potentially trigger an unresponsive crash on closing if someone's messed with the buffer sizes but that's a rare potential issue. It's on by default to be equivalent to what out_ds was doing & what afaict seemed to be expected when using fading but whether it should be on or not is really down to how much you like fading vs wanting things to close quickly. It's not necessarily related to what I think is the problem here but I need to get my head around how I want to do fading irrespective of the output plug-in being used so most of these problems then get shifted elsewhere.

4
Someone else reported this recently but I've not yet been able to replicate it. You could try going to preferences -> plug-ins -> output -> directsound -> fading tab -> disable the "on seek" fading item & see if that makes a difference or not. There's other changes I've been working on with the directsound output plug-in to try to resolve some crashes & locking up issues which possibly might be related to this.

5
Making the file read-only only helps avoid the change being saved out but from an interaction stance you can still mess around with things so that wouldn't be doing what you're wanting. If there was a way to know what's a title bar area (though there's the issue of the skins with interactive elements within that area) then something more useful could be attempted but I'm not aware of how to do that against the gen_ff dll as I'm re-using.

With the next dev build if you enable the feature on the classic skin prefs page & then go into winamp.ini & change freeze=1 to freeze=2 then you'll see the crude mode that can be done by it generically blocking the mouse click interactions from being passed on to gen_ff.

6
Not in a manner that currently would be of any use based on what I can try doing. For classic skins as I've got full control over the window handling I can determine what is being clicked on so it can still allow for things to work like clicking on the buttons & all of that whilst blocking titlebars allowing moving. Whereas I'm not aware of a way that'd allow me to block just interactions on titlebars due to how gen_ff does its windows along with not being able to determine what that part of the window might actually be. I can put in something so you can try out what I can do but the experiencing from a quick re-test of code I'd previously tried isn't nice as nothing can properly react to the mouse.

7
Preview Build Discussion / Re: Requesting old Preview Installer
« on: June 03, 2025, 09:19:13 PM »
What output plug-in is being used as well is it the x64 or x86 build that's being used? I really wish more would actually report issues as I don't know how common stutter issues & other problems might be.

As stuttering playback is not common to x86 based on the limited feedback I get & tentatively I might've figured out what's causing it for x64 installs if using notsodirect.

notsoyasapi & the others irrespective of the prefs page loading issue can still be selected to be used via the root output prefs page as a way to try to work around it.

8
Wishlist / Feature Requests / Re: German language
« on: June 03, 2025, 09:12:00 PM »
I have no eta other than when it happens.

9
I wasn't viewing it as a joke & I was just answering things to set any potential expectations from me plus to link to it so its easier for anyone else that might be interested to have a look into it.

10
Visualisations / Re: RealPlayer Visualization Wrapper (vis_rpv)
« on: June 02, 2025, 10:55:33 AM »
This isn't something I'm interested in doing any time soon nor do I really have the time to do it though there's nothing to stop someone else with the time & interest to focus on a specific project like this to try to create such a plug-in.

11
There is a version of the source code available for the plug-in (here) but it's not the last version & is something that the original author cobbled together from a backup iirc so it doesn't even have the winamp plug-in aspects. So if someone wanted to then I'm sure they could try to resurrect it in some form but that's not something I'm currently interested in trying to do.

12
Preview Build Discussion / Re: Bug report
« on: May 31, 2025, 03:34:09 PM »
I've been trying to replicate this for an hour or so now & I just can't seem to get it to misbehave though I've been doing it against my dev build so maybe I've fixed or it's just not an issue I'm currently seeing.

I've tried having the media library completely disabled, it enabled & just the local library disabled, force clearing the playlist file to ensure it's not got any pre-cached metadata in it, tried adding the playlist from the library playlists view, from explorer onto the main playlist along with seeing what happened when dropping it onto the main window (which'll typically trigger playback if the options on the general prefs page hasn't been changed to alter that behaviour).

In all instances once the item is made to play its getting the title I'd expect in both the song ticker & also within the main playlist. What I am however seeing is it generating a title for the current item when playback hasn't been started which afaict is not expected with that setting (am uncertain as of the time of this reply if it's maybe due to what's in my test playlist which also has a CD in it which might be incorrectly triggering the 'current' item to be processed which I'll have a look into shortly).

So I think it might have to be a case of coming back to this once there's a new preview build available to be able to re-test things with this.

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

14
General Discussion / Re: Question about winamp.ini file
« on: May 31, 2025, 02:25:58 PM »
Usually you can probably work out what the sections might relate to which makes removing them a bit easier & if in doubt I can have a look at the file or what sections might relate to what otherwise it likely doesn't make much sense to mess with it when it's otherwise ok. I'd expect a file to be a few KB but with other plug-ins &/or changing the settings including more atf strings would make it grow so I'm not concerned by the file size & it's well below the OS limits so there's nothing to worry about that being a potential issue behind things going wonky.

15
That's how my local library plug-in has been designed to live reflect changes vs what the views query is setup to be & it depends on what the changes were as to how the handling is applied (e.g. if it is deemed to affect the filters or only within the results pane).

The current selections should however be being maintained when the action happens (or can be nudged to do so via preferences -> media library -> local library -> view filters -> checking the remember search option if not already checked) though I know there's some issues with the album related filter not working correctly which has been fixed in my dev build but that doesn't help things for the current 21640 preview build (as of this reply). Maybe that's part of the problem you're having but I don't have any plans at this time to not do live updates.

Pages: [1] 2 3 ... 119