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.

Recent Posts

Pages: 1 2 [3] 4 5 ... 10
21
Thanks to both for taking the time to look into this, best wishes for both, have a good day
22
Hi Darkhell,

JFI, I'm using the same OS files as you except my OS Build is 22631.3447. Anyway the OS has nothing to do with the bug. Dro has explained why I didn't replicate the issue. I'm glad you found that needle in the haystack.  :)

Observations like yours are making WACUP more and more robust.

23
Preview Build Discussion / Re: 1.99.12.18980 M3U Stream sync connection errors
« Last post by JamminR on May 07, 2024, 02:13:36 AM »
Great options. Thanks for the continued excellence in keeping the app alive.
24
Preview Build Discussion / Re: 1.99.12.18980 M3U Stream sync connection errors
« Last post by dro 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
25
Preview Build Discussion / Re: 1.99.12.18980 M3U Stream sync connection errors
« Last post by JamminR on May 07, 2024, 01:49:13 AM »
Thanks - that's great for 'bad' links.
I'd say a majority of 'commercial' services (shoutcast/icecast/...) would use proper http 80 vs https 443 ports, however, I hate to be a pain, would it still allow for custom https though?

Though I don't run any streaming audio servers myself, I do occasionally host SSL web sites on my home lab using non standard ports
https://blah:8080 or any other number of port numbers.
I could imagine a person using different ports for different streams.

I know, devils advocate here, but don't over-fix the code, considering the old version seemed more a bug handling broken files vs new one doing proper.
I was just hoping it could be made to fail faster.
26
Preview Build Discussion / Re: 1.99.12.18980 M3U Stream sync connection errors
« Last post by dro 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
27
Preview Build Discussion / Re: Bug when switching skins in Preview v1.99.11.18916
« Last post by dro 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
28
So it is a real bug in the code. I assume selecting one or both of the "Ignore the information WACUP provides ..." and "Do not show empty / invalid skins ..." options protects me from the error.
29
Preview Build Discussion / Re: Bug when switching skins in Preview v1.99.11.18916
« Last post by dro on May 06, 2024, 11:00:01 PM »
It's likely how I'm mapping the skin file / folder to a menu item index
It 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
30
Preview Build Discussion / Re: Genre Tag Issue
« Last post by musicf8 on May 06, 2024, 05:24:46 PM »
Check the preferences - advanced - options page 2 tab. If the "Only show genres from the genres.txt ..." option is enabled, try disabling it.

checked and it is disabled

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

Let me know if it is indeed a bug or an issue on my end.  Like I mentioned, it seems the genre is automatically selected and changed just by opening the file info which is a concerning issue for me as I sometimes do edit info that way.

I tried opening other genre songs and it seems that if it is an original unmatching genre (i.e. the genre lists 'chillout' but I labeled the genre as 'Chill Out') then the file info opens normally with no change in genre nor is the genre highlighted.
If I tried opening the file info on a song that has a genre that is in the genre list (i.e. Trance), then the genre field is highlighted right when opening.

My guess is it seems that the drop down matches the genre (or attempts to match) right when opening the file info which is causing the issue.  I would think it shouldn't be doing that until the dropdown is actually selected, but you would know best dro.

thanks.
Pages: 1 2 [3] 4 5 ... 10