1
General Discussion / Re: Latest update - Errors and Crashes
« on: Yesterday at 07:28:31 PM »
Please look at the known issues section on the preview download page which have suggestions on what to try doing.
-dro
-dro
Latest restricted WACUP beta release is build #19100 (May 10th 2024) (x86 & x64 changelogs) | Latest WACUP public preview is build #19100 (May 10th 2024) (x86 only)
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.
2
General Discussion / Re: Random crashes after recent update (1.99.13.19100)
« on: Yesterday at 07:28:11 PM »
Please look at the known issues section on the preview download page which have suggestions on what to try doing.
-dro
-dro
3
Preview Build Discussion / Re: Genre Tag Issue
« on: May 12, 2024, 04:46:45 PM »
That's good to know it's improved things. Its still a bit of a pain due to how the combobox/dropdown control works but main thing is it works well enough now.
-dro
-dro
4
Preview Build Discussion / Re: native scrobbling fails to scrobble certain songs.
« on: May 12, 2024, 04:45:35 PM »
It was a silly miscalculation on my part when rushing to get the prior build fixed for a different issue with the scrobbling vs pausing playback & I'd missed that I was effectively doing a x1000 on the time to wait when the file was more than 8mins long (due to the scrobbler spec have a 4min max wait time).
Main thing is that it's working ok now with the newer build. As for the update notification, its usually checked for once a week from the prior update check when wacup is next run & as you'd only recently updated to a build it'd have reset that wait to check time which is why it hadn't popped up.
-dro
Main thing is that it's working ok now with the newer build. As for the update notification, its usually checked for once a week from the prior update check when wacup is next run & as you'd only recently updated to a build it'd have reset that wait to check time which is why it hadn't popped up.
-dro
5
Preview Build Discussion / Re: native scrobbling fails to scrobble certain songs.
« on: May 11, 2024, 09:32:59 AM »
What build are you using? As 1.99.13.19100 should've resolved what you're describing where files over 8 minutes weren't being scrobbled despite what the prefs indicated.
-dro
-dro
6
Wishlist / Feature Requests / Re: Bring back waveform seeker able to view waveforms upon clicking (not just play)
« on: May 09, 2024, 10:50:15 AM »
The option to do that has not been removed as it's one I've got enabled & use daily for many years now. If you right-click in the waveform seeker window & there'll be an option to have it show for the selected item. That shouldn't have become un-checked if it was enabled when installing the newer build unless this was a clean install & the prior settings were set to not be maintained.
-dro
-dro
7
Preview Build Discussion / Re: Genre Tag Issue
« on: May 08, 2024, 11:42:48 PM »
The problem is mostly due to how the OS combobox / dropdown control wants to do things & so far I can't find anything obvious that'd allow me to override the matching it's automatically trying to do (isn't something I'm actively doing on the basic info tab nor is in_mp3 doing afaict on the id3v2 tab - also probably affects the id3v1 tab).
The setting of the text in that control which has to be done otherwise you have the alternative issue of losing metadata then appears to automatically trigger the control to search within what's been added & try to match to that. This is also going to affect things like the batch edit dialog (though that doesn't seem to do it until interacting with it - something that mp3tag also seems to do) & any instance of the combobox / dropdown control when user input is enabled vs the string not being already known to it.
What I can do to try to workaround the issue on the basic info dialog is to insert the given genre string if it's not found & that keeps it happy. I still need to work out why it's showing it as selected text when that's not what I'm wanting it to do. I'll have to see about hooking the id3v2 tab & trying to do the same.
-dro
The setting of the text in that control which has to be done otherwise you have the alternative issue of losing metadata then appears to automatically trigger the control to search within what's been added & try to match to that. This is also going to affect things like the batch edit dialog (though that doesn't seem to do it until interacting with it - something that mp3tag also seems to do) & any instance of the combobox / dropdown control when user input is enabled vs the string not being already known to it.
What I can do to try to workaround the issue on the basic info dialog is to insert the given genre string if it's not found & that keeps it happy. I still need to work out why it's showing it as selected text when that's not what I'm wanting it to do. I'll have to see about hooking the id3v2 tab & trying to do the same.
-dro
8
Preview Build Discussion / Re: 1.99.12.18980 M3U Stream sync connection errors
« on: May 07, 2024, 02:00:17 AM »
I'm only looking at ports 80 / 443 in comparison to whether https or http is specified & if they match as expected.
Everything else will be processed as provided by the caller to the networking service & assumes that whatever is providing the stream urls is doing it correctly otherwise I'd have broken the majority of shoutcast/icecast/equivalent based streaming urls (which for shoutcast defaulted to 8000 if memory serves me right from what I vaguely still remember from when I worked on that).
There'll also be a new prefs option (general -> internet) that allows for the new behaviour to be disabled.
-dro
Everything else will be processed as provided by the caller to the networking service & assumes that whatever is providing the stream urls is doing it correctly otherwise I'd have broken the majority of shoutcast/icecast/equivalent based streaming urls (which for shoutcast defaulted to 8000 if memory serves me right from what I vaguely still remember from when I worked on that).
There'll also be a new prefs option (general -> internet) that allows for the new behaviour to be disabled.
-dro
9
Preview Build Discussion / Re: 1.99.12.18980 M3U Stream sync connection errors
« on: May 07, 2024, 01:36:11 AM »That'd be why the old preview worked as the 'https://blah:80" was force changed to 'http://blah:80" which would work. Streams on other ports don't necessarily seem to be hitting these base http vs https assumptions (not sure if that's within in_mp3 or the networking service it uses which I've got some control over) & is something I can look into improving.I've now had a look from a code view point & it appears to be down to in_mp3 doing the url processing before it calls things in the networking service which is then just trying to process the connection against what it's been instructed to use which is what it should be doing but also isn't necessarily ideal when the default http / https port url is trying to be used.
For the next build I've modified the networking service so it'll check what the connection type is vs the port trying to be used. If it's https & port 80 then it'll change it to port 443 & if it's http & port 443 then it'll change it to port 80 which seems reasonable & looks to be something browsers seem to be doing. Doing that allows the provided example playlist to work as-is.
-dro
10
Preview Build Discussion / Re: Bug when switching skins in Preview v1.99.11.18916
« on: May 07, 2024, 12:14:49 AM »
It is & those options won't help as the issue arises before any of that is run. The number & names of the skins found is also what made it more obvious with a default install & no other skins being the reliable way to replicate it against what was shown in the video of the issue.
-dro
-dro
11
Preview Build Discussion / Re: Bug when switching skins in Preview v1.99.11.18916
« on: May 06, 2024, 11:00:01 PM »It's likely how I'm mapping the skin file / folder to a menu item indexIt was that but not quite as I first thought. The problem is that it's adding invalid items (e.g. empty folders or non-skin files) into the internal list which shouldn't have been happening & when there's mostly no other skins than the default skins it ends up using the wrong entry due to it finding them before the default skins when the a/b naming aspect is involved.
The alphabetical order is somewhat involved but the default skins per the skin manager prefs page also note those are excluded from the default alphabetical sorting & with the invalid item in that list it skews the mappings & so the wrong skin gets used.
tl;dr: needed to move 1 line of code to after some skin validation checks were done.
-dro
12
Preview Build Discussion / Re: Genre Tag Issue
« on: May 06, 2024, 10:25:05 AM »
It's most likely down to how the find in the dropdown is done which can be either be an exact match or a first part that matches approach (this being what I assume is happening until I check things out).
-dro
-dro
13
Preview Build Discussion / Re: 1.99.12.18980 M3U Stream sync connection errors
« on: May 05, 2024, 10:20:07 PM »
I'd completely missed the port 80 in the urls. For http, port 80 is typically assumed if not specified whereas for https it's 443. So removing the :80 or changing https to http has the same effect to 'fix' things in that it's allowing the wanted default connection behaviour to work.
So trying to do an https assumed connection against the typical http port would mean there's a connection being established but in_mp3 doesn't know how to cope with the data its getting back since it's very likely expecting an encrypted stream but since it's an http connection it just keeps going until it &/or the connection times out hence the "Error Syncing to Stream" message.
That'd be why the old preview worked as the 'https://blah:80" was force changed to 'http://blah:80" which would work. Streams on other ports don't necessarily seem to be hitting these base http vs https assumptions (not sure if that's within in_mp3 or the networking service it uses which I've got some control over) & is something I can look into improving.
The other aspects need a whole new input plug-in (not only for mp3 / aac streaming but all of WACUP's streaming support overall) & is something I'll keep in mind for when that work is begun as I don't want to do more against the networking service in_mp3 is using as I really don't plan on keeping it around when my replacement is done.
-dro
So trying to do an https assumed connection against the typical http port would mean there's a connection being established but in_mp3 doesn't know how to cope with the data its getting back since it's very likely expecting an encrypted stream but since it's an http connection it just keeps going until it &/or the connection times out hence the "Error Syncing to Stream" message.
That'd be why the old preview worked as the 'https://blah:80" was force changed to 'http://blah:80" which would work. Streams on other ports don't necessarily seem to be hitting these base http vs https assumptions (not sure if that's within in_mp3 or the networking service it uses which I've got some control over) & is something I can look into improving.
The other aspects need a whole new input plug-in (not only for mp3 / aac streaming but all of WACUP's streaming support overall) & is something I'll keep in mind for when that work is begun as I don't want to do more against the networking service in_mp3 is using as I really don't plan on keeping it around when my replacement is done.
-dro
14
Preview Build Discussion / Re: 1.99.12.18980 M3U Stream sync connection errors
« on: May 05, 2024, 12:50:31 PM »
The problem is that whatever provided you with https urls for the streams shouldn't have done that (if it was from shoutcast then that's one more complaint to leverage against them) & it should've only given you http urls as that's only what the provided streams are using.
It worked in the old WACUP preview because I was having to force https -> http to avoid issues with the re-used plug-in that handles such streaming & that masked the playback problem but it then broke legitimate https playback. In hindsight I should never have done that action.
The current build allows both https & http to work but it's now "broken" things for you because it's honouring what the url type is & as those don't support https (again those provided urls should never have been https ones from whatever service was providing them) then until I make my own plug-in for streaming which might attempt to re-try failed https as http it requires you to 'fix' the urls which'll work on both builds.
-dro
It worked in the old WACUP preview because I was having to force https -> http to avoid issues with the re-used plug-in that handles such streaming & that masked the playback problem but it then broke legitimate https playback. In hindsight I should never have done that action.
The current build allows both https & http to work but it's now "broken" things for you because it's honouring what the url type is & as those don't support https (again those provided urls should never have been https ones from whatever service was providing them) then until I make my own plug-in for streaming which might attempt to re-try failed https as http it requires you to 'fix' the urls which'll work on both builds.
-dro
15
Preview Build Discussion / Re: 1.99.12.18980 M3U Stream sync connection errors
« on: May 05, 2024, 01:19:05 AM »
The older preview builds are still referenced on the site by following the prior / last preview build link from near the top of the initial text on the site's main preview build page.
I've tried to play all of the links in the example playlist & as-is none of them are working for me either in the current preview or the very old one (which ended up hanging whilst trying to do anything but that might be to do with whatever I'd last done to that test install a few years ago) nor in other players / browsers.
However the problem seems to be because the old preview build would try to force streams to use http:// when https:// was found as that's what was needed to allow the re-used in_mp3 plug-in dll from 5.666 to be more likely to play things.
The newer build has long since resolved that problem & that re-used in_mp3 is now able to try to play the stream urls as-is which is a problem here because what you've provided doesn't respond on the https:// urls from the server side (ideally there should be an attempt to drop back to http but the connection is also taking an age to timeout it seems).
If you edit the stream urls to use http:// then just the sc1 & sc2 server urls don't seem to be responding from my testing.
-dro
I've tried to play all of the links in the example playlist & as-is none of them are working for me either in the current preview or the very old one (which ended up hanging whilst trying to do anything but that might be to do with whatever I'd last done to that test install a few years ago) nor in other players / browsers.
However the problem seems to be because the old preview build would try to force streams to use http:// when https:// was found as that's what was needed to allow the re-used in_mp3 plug-in dll from 5.666 to be more likely to play things.
The newer build has long since resolved that problem & that re-used in_mp3 is now able to try to play the stream urls as-is which is a problem here because what you've provided doesn't respond on the https:// urls from the server side (ideally there should be an attempt to drop back to http but the connection is also taking an age to timeout it seems).
If you edit the stream urls to use http:// then just the sc1 & sc2 server urls don't seem to be responding from my testing.
-dro