Latest WACUP public preview for x86 & x64 is build #23960 (March 1st 2026) (x86 & x64 changelogs)
Latest restricted WACUP beta release is build #23960 (March 1st 2026) (x86 & x64 changelogs)

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 - toejam119

Pages: [1]
1
Stream titles seem to be working properly with this release. :)

v1.99.39.22656 x86 preview

2
1.99.38.22626 x86 doesn't fetch/print stream titles if ATF is enabled. I tried this with all 5 different stream providers in my bookmarks, it works on none of them. I can get the titles appear if I disable ATF, but then local mp3 files only show the title field (if found) which I find inadequate. I tried using ATF with default settings but no avail.

I have to revert to 1.99.36.22278 x86 to get the stream titles back with ATF.

Example radio stream where titles do not work: http://ice1.somafm.com/groovesalad-64-aac

WACUP_Preview_v1_99_38_22626_x86
Win11 x64 24H2

3
If player is in stopped state, you select a local mp3 or aac/m4a file (with or without artist/title metadata) from WACUP's open file or Windows File explorer it will display path/filename in songticker instead of "artist - title" BUT if the player is in playing state and you do this it will show "artist - title" in songticker.
Titles | ATF -> the first option is selected "Read metadata in the background when file(s) are being loaded or played or viewed (default)",
this doesn't happen if option 2 or 3 is selected.

I tested this with default ATF and my custom ATF, it happens on both.

Also doesn't matter if the song has metadata with artist and title, happens on both.

My custom ATF, it is necessary: $if3(%streamtitle%,[%artist% - ]%title%,[$filepart(%filename%)])
(I did this way because I want Artist - Title before radio station name which was the old way in songticker before one of the July release, I believe before July 22nd 2025.)

WACUP preview 32-bit 1.99.36.22278 (2025.07.28)
Skin = classic 2.x
Windows 11 x64 24H2

4
I've played different streams on beta/dev 1.99.36.22278 32 bit and I cannot get the titles disappear anymore. I think this is fixed.

5
Sure, it's http://ice1.somafm.com/groovesalad-64-aac
I tried to replicate this with a radiotunes.com premium stream and I can't, with it it just removes the title when I press stop.
edit: found another random radio stream where the title gets removed when stop is pressed https://centova5.transmissaodigital.com:20104/

6
No worries, I can use in_mp3 until this is fixed. in_mp3 works just as good as in_url otherwise.

7
The behavior changed, now if I start to stream and then if I press stop within 5 seconds the title remains. However, if I press stop after 6.5 seconds the title disappears. If I press stop between 5.0 - 6.5 seconds the title usually remains but sometimes disappears.

I tried disabling playlist history from settings but this doesn't seem to affect the outcome.

in_url active
Not So Direct active

WACUP 32-bit beta/dev 1.99.36.22268

8
Since in_url is preferred in 1.99.35.22222 x86 (2025.07.22) I noticed that stream title/songname disappears from main window and from playlist window when stop has been pressed. This was not the case with in_mp3.
This does not happen if I disable "Use ATF when possible" but this causes another problem: mp3 files are shown as filenames only (with filepaths), m4a/aac files are not affected.
It would be nice to have the title/songname to remain after stop is pressed so that I can see what the last song played was on the radio channel.

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

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.

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

10
Updated to WACUP_Preview_v1_99_34_22022_x86 (released 2025.6.29)
Now the streaming fails very often with "Read metadata only when files are played", setting the metadata reading to default returns the original problem (rarely fails to start loading streams).
BUT if I disable in_snes.dll from inputs this new problem goes away.

Did not have this issue with in_snes.dll with WACUP preview x86 1.99.32.21640 (released 2025.05.11)

11
Sometimes whilst you're already listening a radio channel (streaming aac) and you try to switch to another channel via Media Library bookmarks link (you double click it), the current channel just stops but new channel doesn't start playing. You click again the same channel you tried before and it starts playing normally. This happens infrequently, but still often enough to annoy you. I couldn't replicate the problem if I select another channel using the playlist window.

The problem persists on WACUP Preview v1.99.12.18980 (April 2024 release), PC = Win10 x64.
I first noticed the problem on WACUP Preview v1.9.20.17040 (September 2023 release), PC = Win10 x64.
I didn't notice the problem on WACUP Preview v1.0.18.6800 (December 2020 release), PC = Win10 x64.
I don't think I used versions in between these. I've only used preview releases, not beta releases.

I can circumvent the problem (the problem goes away) if I go to settings->Playlist->Titles | ATF, select "Read metadata only when file(s) are played" and disable "Use ATF when possible." So the problem is one of those two. This circumvention doesn't cause any negative effects on the usage of WACUP on my part.

Pages: [1]