Recent Posts

31

Preview Build Discussion / Re: Genre Tag Issue

« Last post by musicf8 on May 09, 2024, 12:13:44 AM »

Thanks dro for looking into this. 

Yes, the behavior of mp3tag and winamp 5.666 is normally what I would expect, where the genre text is unaltered and is unselected until the dropdown box is selected.

32

Preview Build Discussion / Re: Genre Tag Issue

« Last post by dro 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

33

Preview Build Discussion / Re: Bug when switching skins in Preview v1.99.11.18916

« Last post by Darkhell on May 08, 2024, 07:10:24 PM »

Thanks to both for taking the time to look into this, best wishes for both, have a good day

34

Preview Build Discussion / Re: Bug when switching skins in Preview v1.99.11.18916

« Last post by Aminifu on May 07, 2024, 03:37:55 AM »

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.

35

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.

36

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

37

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.

38

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

39

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

40

Preview Build Discussion / Re: Bug when switching skins in Preview v1.99.11.18916

« Last post by Aminifu on May 06, 2024, 11:57:58 PM »

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.