16
Resolved Issues / Re: [Bug] Searching library with blank space " " returns incorrect/broken files
« on: March 24, 2026, 11:44:37 PM »
Happy to help, thanks for all your work 
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.
17
Resolved Issues / [Bug] Searching library with blank space " " returns incorrect/broken files
« on: March 24, 2026, 02:04:22 PM »
Adding a blank space " " in library search will return a list of incorrect files, pulled from various locations on the computer, including outside of the designated library folders. In my case, Winamp is only set to watch D:/Music but a blank space search returns audio files from my Windows User Desktop & Downloads.
In addition, some library files are displaying broken or missing metadata, but only when returned via a blank space search. If I search those same audio tracks normally, eg. "artist name" in search, then the metadata appears correctly in the library.
Sorry I can't provide a good screenshot of this one, but the results in my Desktop and Downloads are private. It's an easy repro to try yourself tho.
Repro steps:
1. Go to library
2. In the search box, type a blank space with spacebar
3. Observe library results from incorrect locations and broken metadata
The attached screenshot does show a blank space search (obviously invisible) returning 52 tracks missing Genre and 43 tracks missing Artist, but under normal searches and at a default no search state, no item in my library is missing these data. I'm not yet sure what is determining which files appear broken under a blank space search.
In addition, some library files are displaying broken or missing metadata, but only when returned via a blank space search. If I search those same audio tracks normally, eg. "artist name" in search, then the metadata appears correctly in the library.
Sorry I can't provide a good screenshot of this one, but the results in my Desktop and Downloads are private. It's an easy repro to try yourself tho.
Repro steps:
1. Go to library
2. In the search box, type a blank space with spacebar
3. Observe library results from incorrect locations and broken metadata
The attached screenshot does show a blank space search (obviously invisible) returning 52 tracks missing Genre and 43 tracks missing Artist, but under normal searches and at a default no search state, no item in my library is missing these data. I'm not yet sure what is determining which files appear broken under a blank space search.
18
Preview Build Discussion / [Bug?] Context menu "show all by artist" does not work when filters are active
« on: March 24, 2026, 01:46:47 PM »
Hey there,
These one seems like a bug but may be intended behaviour. However if the latter, it's very unintuitive and not great UX.
Filtering by an album and then using the library context menu to "show all by artist NAME" does not override the search filter.
The terminology of "show all by artist NAME" implies I see everything by that artist, with the album filtering removed.
Untested with other filters such as "genre" but I'd expect the same behaviour.
Repro steps:
1. In library, use the "Album" filter to select an album
2. In library panel, while only viewing the selected album, right click any track
3. Select "show all by artist NAME"
Actual result:
The search bar is populated with the string "?artist="ARTIST NAME" " but the results in the library are still filtered by the original album filtering, therefore hiding any results not in the currently selected album.
Expected result:
In repro step 3, the album filtering should be removed, and ALL tracks by artist should be displayed, as implied in "show all by artist NAME"
These one seems like a bug but may be intended behaviour. However if the latter, it's very unintuitive and not great UX.
Filtering by an album and then using the library context menu to "show all by artist NAME" does not override the search filter.
The terminology of "show all by artist NAME" implies I see everything by that artist, with the album filtering removed.
Untested with other filters such as "genre" but I'd expect the same behaviour.
Repro steps:
1. In library, use the "Album" filter to select an album
2. In library panel, while only viewing the selected album, right click any track
3. Select "show all by artist NAME"
Actual result:
The search bar is populated with the string "?artist="ARTIST NAME" " but the results in the library are still filtered by the original album filtering, therefore hiding any results not in the currently selected album.
Expected result:
In repro step 3, the album filtering should be removed, and ALL tracks by artist should be displayed, as implied in "show all by artist NAME"
19
Preview Build Discussion / [Bug] New media items added to library will appear with missing metadata
« on: September 24, 2025, 01:14:17 PM »
New media items added to library via a monitored folder will appear with missing metadata until the metdata is edited. The "missing" metadata actually appears to be in place, but just does not initially appear in the library. This seems to affect some of the newly added files, while some appear with the correct metadata in the library.
Repro steps:
1. Go to Preferences > Media Library > Folder Monitor
2. Ensure a folder is being monitored and all options are enabled, such as real time monitoring
3. Add a new folder to the monitored location, which contains some mp3s with correct metadata
4. Wait for the library to auto-scan, or restart WACUP to trigger a scan
5. SOME of the new media items will appear as blank entries at the top of the library
6. Right click a blank entry, and "Edit metdata"
7. Click in any field and then click "Update" (You don't need to actually change any values)
8. The media will now appear with correct metdata in the library
In the screenshot attached you can see three entries of a folder I added, two of them are missing metadata while one track appears correctly (censored as it's unreleased!). This occurs with every folder I add.
Repro steps:
1. Go to Preferences > Media Library > Folder Monitor
2. Ensure a folder is being monitored and all options are enabled, such as real time monitoring
3. Add a new folder to the monitored location, which contains some mp3s with correct metadata
4. Wait for the library to auto-scan, or restart WACUP to trigger a scan
5. SOME of the new media items will appear as blank entries at the top of the library
6. Right click a blank entry, and "Edit metdata"
7. Click in any field and then click "Update" (You don't need to actually change any values)
8. The media will now appear with correct metdata in the library
In the screenshot attached you can see three entries of a folder I added, two of them are missing metadata while one track appears correctly (censored as it's unreleased!). This occurs with every folder I add.
20
Preview Build Discussion / Re: [Bug] Closing the "Edit metadata" window refreshes the audio library view
« on: September 16, 2025, 01:53:30 PM »
Yeah I have that option enabled.
But I have found an updated repro: you do not need to actually change any metadata. Simply scroll halfway down your library, right click any item, "edit metadata for selection..." and the immediately close the new window without changing any fields and the entire library will refresh back to default view at the top.
EDIT: I'm an idiot and literally had this as the original repro lol
Somewhat conversely, if you have a search active that finds one result, (eg. a specific song title) and then change some metadata that invalidates the search, the library will then refresh but land in the CORRECT location with the changed item highlighted. But I have seen that there was a change regarding this in the latest build which could have helped here.
EDIT: I'm an idiot and literally had this as the original repro lol
Somewhat conversely, if you have a search active that finds one result, (eg. a specific song title) and then change some metadata that invalidates the search, the library will then refresh but land in the CORRECT location with the changed item highlighted. But I have seen that there was a change regarding this in the latest build which could have helped here.
21
Resolved Issues / Re: [Feature Request] Clear Discord rich text presence when music is paused
« on: September 16, 2025, 01:44:58 PM »
The new option works perfectly, thank you so much!
22
Resolved Issues / [Feature Request] Clear Discord rich text presence when music is paused
« on: September 03, 2025, 06:55:03 PM »
Currently if you pause a track while sending RTP info to Discord, Discord will show that the track is continuing to play indefinitely.
The track must be stopped rather than paused. It would be great if pausing a track also cleared the Discord RTP info, or if there was at least an option to toggle this behaviour, similar to the option to toggle the Stop behaviour.
The track must be stopped rather than paused. It would be great if pausing a track also cleared the Discord RTP info, or if there was at least an option to toggle this behaviour, similar to the option to toggle the Stop behaviour.
23
Preview Build Discussion / Re: [Bug] Tags including the Polish character "ł" are randomly regressing to "l"
« on: September 01, 2025, 12:40:24 PM »
I know that these tags have been correct for years, and at *some* point changed to the incorrect character, but unfortunately I can't say when that occurred, but I'm inclined to believe it was recently, as in since changing to WACUP, as one of them was appearing as an incorrect Artist which I'd be surprised if I hadn't noticed until now.
I have now managed to change the tags using the external mp3tag tool, and they appear to be sticking correctly now, so there is definitely a bug with tags changed via WACUP regressing to the incorrect English characters.
I'll keep an eye on them moving forward and see if they change back again.
I have now managed to change the tags using the external mp3tag tool, and they appear to be sticking correctly now, so there is definitely a bug with tags changed via WACUP regressing to the incorrect English characters.
I'll keep an eye on them moving forward and see if they change back again.
24
Preview Build Discussion / Re: [Bug] Tags including the Polish character "ł" are randomly regressing to "l"
« on: August 30, 2025, 09:37:24 AM »
Thanks for helping clarify that!
25
Preview Build Discussion / [Bug] Tags including the Polish character "ł" are randomly regressing to "l"
« on: August 29, 2025, 01:33:33 PM »
Mp3 tags which include the Polish character "ł" are randomly regressing to the English "l", most notable when Polish "ł" is included in more than one tag, eg. song title and album title.
Repro steps:
1. From the library view, open "Edit item metadata" window on an mp3
2. Change the song title to something including "ł" (eg. "hijkłmno")
3. Change any other field to the same title, eg. artist, album artist, album name, etc.
4. Click Update
Expected result:
All fields should maintain the new titles
Actual result:
One of the fields with "ł" will regress to the English character "l"
Repro steps:
1. From the library view, open "Edit item metadata" window on an mp3
2. Change the song title to something including "ł" (eg. "hijkłmno")
3. Change any other field to the same title, eg. artist, album artist, album name, etc.
4. Click Update
Expected result:
All fields should maintain the new titles
Actual result:
One of the fields with "ł" will regress to the English character "l"
26
Preview Build Discussion / Re: Closing the "Edit metadata" window refreshes the audio library view
« on: August 29, 2025, 01:27:08 PM »
Thank you for replying! Apologies I missed it until now. This is definitely a bug in that case, as any current search will not be respected after a metadata update - the library view will always "refresh" back to the top once the Edit Metadata window is closed
27
Skins / Re: Scaling doesn't affect library text
« on: August 24, 2025, 01:37:10 PM »
That's exacty what I was looking for, thank you so much!
28
Skins / Scaling doesn't affect library text
« on: August 21, 2025, 02:35:26 PM »
Hey, sorry if I'm missing something really obvious, but changing the scaling settings on Big Bento & Big bento Modern W10 doesn't actually affect the main text in the library panes. This leaves me with some elements which are scaled, but tiny text in the library which remains difficult to read at smaller resolutions.
I haven't seen any clear instructions on previous posts on how to change the font sizes, or why in my case they are not linekd to the skin scaling. The option in the "Font Rendering" tab aren't clear to me, eg. "sking font mapper" and "truetype replacement" etc.
I haven't seen any clear instructions on previous posts on how to change the font sizes, or why in my case they are not linekd to the skin scaling. The option in the "Font Rendering" tab aren't clear to me, eg. "sking font mapper" and "truetype replacement" etc.
29
Preview Build Discussion / [Bug] Closing the "Edit metadata" window refreshes the audio library view
« on: May 31, 2025, 12:33:43 PM »
As per title, closing the "Edit metadata" window refreshes the audio library view
Reproduction steps:
1. Open audio library
2. Scroll or search to a track in the middle of the library
3. Right click track and "Edit metadata for selection"
4. Click "Cancel" or "Update"
Result: Audio library refreshes and goes back to the top
This is awkward when, for example, editing track titles on multiple files. You need to search/scroll back to the album every time
Preferred result: the audio library window does not refresh when closing "Edit metadata" window
Reproduction steps:
1. Open audio library
2. Scroll or search to a track in the middle of the library
3. Right click track and "Edit metadata for selection"
4. Click "Cancel" or "Update"
Result: Audio library refreshes and goes back to the top
This is awkward when, for example, editing track titles on multiple files. You need to search/scroll back to the album every time
Preferred result: the audio library window does not refresh when closing "Edit metadata" window
30
General Discussion / Re: Importing Local Library .csv
« on: April 19, 2025, 04:30:11 PM »
Gotcha. Thanks for the reply, and for all the work on this!