Latest WACUP public preview for x86 & x64 is build #22022 (June 29th 2025) (x86 & x64 changelogs)
Latest restricted WACUP beta release is build #22022 (June 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 ... 121
1
Preview Build Discussion / Re: Bug report
« on: Today at 09:18:09 AM »
I dunno then nor can I currently replicate & maybe its somehow related to the other failures of metadata handling that you've reported.

2
The local library if enabled is used as the cache for metadata & that is used over metadata coming from the file itself unless it's not known in the local library at the time of the request & then for mp3 files it goes via a different implementation to try read metadata from such files to avoid even hitting the likes of in_mp3 to avoid the problems crappy plug-ins like that have with not being thread safe or their known bugs. Or I'm just not testing things correctly or am completely missing something else as the code on my side is meant to trigger a re-read in the local library & then a title refresh in the main playlist as long as a valid 'save' response is signalled from the plug-in as in_mp3 seems to do.

3
I've been told numerous things that triggered it for other previously but can't replicate it so just chalk it up as never-ending shit coding my part.

4
All of the crashes that have been generated by you (which weren't flagged as coming from a beta install so haven't be prioritised) are all due to the history db & the backups being corrupted as the message in the view was shown so why you took it mean the local library (different files) I do not know. It's history.dat/.idx with the matching .backup named files for the history (not the 'library' files) that need to be removed which can be found from preferences -> advanced -> diagnostics -> settings locations tab. There's also a crash report collector shortcut to run things from the wacup start menu entry or via preferences -> advanced -> error reporting.

5
Preview Build Discussion / Re: Bug report
« on: July 06, 2025, 05:16:14 PM »
Disable in_mp3 via prefs -> plug-ins -> input as I still can't replicate this failing nor the other issues with things not reading metadata on changing so once again there's something wrong with how I seem to be either following the steps to replicate or my setup just doesn't manage to trigger it & in_mp3 is known to f things up when it comes to metadata despite trying to do everything I can to not have anything query it but that doesn't help if it's being used for playback.

6
Preview Build Discussion / Re: changing ID3 tag can cause issues
« on: July 06, 2025, 05:12:31 PM »
Edits are meant to signal to the local library & also the main playlist to trigger a metadata refresh which then drives other parts of the player to update. I however can't control the input plug-in handling the metadata action screwing up / breaking what's going on / blocking metadata from being read from the file by those actions as is commonly going to happen with the re-used in_mp3 plug-in (per file locking issues as well also noted when using that plug-in). Other than not editing metadata in wacup & triggering metadata refreshes manually I don't have a fix for what is mostly down to that damn input plug-in.

7
Preview Build Discussion / Re: Main window can stop rendering
« on: July 06, 2025, 05:09:13 PM »
It just does that & despite numerous attempts I've never managed to find a solution to resolve it since I thought it was maybe resolved but you reporting it means I need to re-add it to my todo list. Doing a skin refresh (F5) might trigger it to update again but doesn't fix the cause of something that shouldn't be happening.

8
Quote
Have you applied the post-release crash fixes to the 22022 install (via prefs -> about | updates -> about tab -> button that appears in the build info section or should've been prompted if you've had the build trigger a crash) ?
I haven't. I didn't even know this existed until now.
It's a new thing to this preview build.

Quote
I don't see how in_snes should be involved at any point in all of this as it doesn't handle streams.
I was also confused what in_snes has to do with playing aac streams.
That's the thing in that it doesn't unless I've broken something else with the way input plug-ins are matched to the input plug-in to use but I'd then expect to be seeing that with my own testing. Unless it's something about the style of urls that you're trying to play which I'm missing from the ones I'm testing.

Quote
What skin are you using as a modern skin can entirely screw the assumptions up.
I use Big Bento (modern skin). I switched to classic default skin (so tiny on 2K screen) and problem2 went away but problem1 still persisted. Then I uninstalled in_mp3 and both problem1 and problem2 are gone. At least right now I cannot reproduce either while using Big Bento skin and default metadata read mode, tried restarting the app few times too.
Modern skins like the Bento based ones with their file info pane will try to get metadata & in_mp3 has concurrency issues with some of the requests vs things I've tried to put in place to avoid other metadata requests from the modern skin engine blocking things (something that will never be properly fixed without a replacement gen_ff / modern skin engine plug-in so that none of the metadata requests are done on the main ui thread which is just not a good thing to be ever doing).

From a user view point it just makes it look like wacup is always at fault when imho it's just that I'm doing things differently to what winamp did & trying to fudge that plug-in to work outside of winamp sadly shows up those problems which under a classic skin is generally not going to happen (excluding what 3rd party plug-ins might be trying to do).

Seems not using in_mp3 was key. Thanks! I'll keep posted if problem persists later on.
Does in_url also handle local mp3, aac and m4a files? Or is it some other input plugin? They seem to play just fine without in_mp3.
in_mp3 was only there for mp3, aac, related streams & tag editing on mp3 files (something that isn't provided when in_mp3 is disabled / removed). m4a/mp4 are handled via the in_mp4 plug-in & local .aac files are also sent to that plug-in instead of in_mp3 but that doesn't provide seeking support since that's not something .aac natively provides & I've yet to implement a brute force mode seeking to enable that.

in_url can do mp3 & aac streams along with recently trying to pass ogg+vorbis streams onto in_vorbis but I need to do more work so in_url becomes the general handler for streams so the other input plug-ins can then just focus on local file playback (which'll make determining what to do for other ogg / opus based streams simpler once it's been coded).

in_wave is used for local mp3 playback if there's not anything else claiming mp3 files which is a crude way to allow the x64 build to offer mp3 playback whilst allowing the x86 build to have a fallback mode if in_mp3 cannot be obtained during install.

edit: Seems not using in_mp3 crashes the player quite often especially when launching local files via the open file button but also sometimes when I launch stream url. Reinstalled in_mp3 but the problem2 (fails often to initially start internet radio stream) comes back. Switched to classic skin seemed to get rid of this problem but classic skins are not good on 2K screens. So I just uninstalled in_snes and the problem went away, and kept using Big Bento modern skin.
Classic skins offer 2x & 3x scaling modes but I get that doesn't look nice for some & when I'm using scaling on the modern skins I'm not the best person to suggest such options it seems. Is wacup's crash reporter being shown as I've not seen any crash reports that appear to relate to the open file dialog or having in_snes involved with things.

If you can try to replicate it, running wacup via the crash collector shortcut from the start menu or using the /procdump command-line mode or using the mode from prefs -> advanced -> error reporting would be useful to help try to determine what might be going on so it can try to be resolved. Then when it crashes, restart it normally & that will try to auto-submit it to the site - best to post here when that is done so I can try to match up the report to you or pm / email me a copy of what's generated as can be found via the link to open into the crash reports folder from prefs -> advanced -> error reporting.

About | updates -> about tab crash update fix button disappeared after the latest crash so I'm guessing the player automatically applied it? But it still kept crashing quite often.
If all of the currently available patched plug-ins / dlls are found to be present then it will no longer show the button. There is also an attempt to update things after a crash happens which depending on how things have been run might mean it gets applied without a prompt (e.g. if it's in a portable install) or it'll trigger a UAC / copying prompt (normally needed with a non-portable install in the "program files" folder).

9
Skins / Re: Winamp Modern Updated for WACUP
« on: July 04, 2025, 10:19:30 PM »
This skin is already provided with the x86 build of wacup (unless wanting one of the small tweaked versions which isn't much different to what's provided vs the initial aspects of this thread). So it's just a matter of either selecting it from the first run dialog or going to prefs -> skins or main right-click menu -> skins & selecting it or other skins from there. Other skins need to be put into the <wacup_program_folder>\Skins & then use the prefs or menu to select it to be used.

10
What wacup build? Though there's never been a guarantee of the order that the file list explorer gives to wacup (I assume it's explorer to wacup or are you doing all of this from within wacup?). Removing the studio.xnf wasn't needed as that's purely for modern skin configuration stuff which is unrelated to what you're doing.

11
Stream playback with the noted changed setting for title reading shouldn't have any active effect when it comes to urls as they're effectively ignored anyway.

Have you applied the post-release crash fixes to the 22022 install (via prefs -> about | updates -> about tab -> button that appears in the build info section or should've been prompted if you've had the build trigger a crash) ?

I don't see how in_snes should be involved at any point in all of this as it doesn't handle streams.

However you can try going to prefs -> plug-ins -> input -> find in_mp3, un-check it & allow wacup to restart to then see what happens from that. As that makes it not be able to try to use the re-used plug-in from 5.666 & instead use my in_url plug-in which can do mp3 + aac based urls which is something I've got code control over (not that it seems to help with weird failures the builds keep happening).

[edit]
What skin are you using as a modern skin can entirely screw the assumptions up.

12
Skins / Re: [CHANGES MADE] CPro MMD3 won't load
« on: July 03, 2025, 06:12:07 PM »
It's not a skin specific fix & is a flaw with my handling around getting gen_ff to work outside of winamp. I'd seen it from the first test once I got the skin loading but didn't know if that was correct or not since I'm not going to mess around with trying to get the 5.666 test install loading cpro skins (I want to uninstall it but keeping it for the odd bit of comparison testing still makes sense for now) but thankfully it was simpler to fix purely due to seeing what the related element in the skin related to which is often not the case with other skin rendering issues.

13
It's not a bug. It was a choice I made many years ago to disable what was a big hack via my jtfe plug-in (which is how 5.666 has such a generic window windowshade mode) that I no longer felt was right to have in wacup. It was skin specific since it only worked with classic / 2.x skins unless modern skins were specifically coded to do it. I currently don't have any intent to re-implement it natively in the wacup core classic skin handling.

14
Skins / Re: [CHANGES MADE] CPro MMD3 won't load
« on: July 03, 2025, 12:11:25 PM »
Its something that's wrong my handling to try to fudge gen_ff to work outside of winamp due to there not being a 'color' value specified in the skin for the "$solid" part used to generate the background of those led elements. Afaict that's meant to be treated as color="0,0,0" & adding that into the appropriate line in the groups.xml file in the skin seems to fix it (the pink seems like it might be an error colour to help identify possible problems but gen_ff seemed to gracefully handle this). There'll be change in the next build which should do all of that without having to edit the skin which isn't imho the right fix even it's the quick way to do it.

15
General Discussion / Re: Last.fm scrobbler info
« on: July 03, 2025, 09:23:58 AM »
I broke plug-in loading, wonderful.

Pages: [1] 2 3 ... 121