in_url makes stream title disappear if stop is pressed

[toejam119]

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.

[dro]

From a quick look it appears it might be an x86 build issue as I'm not seeing it happen with the x64 build despite them both using in_url for stream playback. Until I look into it properly this is a bit weird that they'd behave differently & feels like I've left some compatibility hack in place that's incorrectly causing things to be refreshed when it shouldn't be.

[dro]

It was in_url as part of trying to prevent it sitting on connecting but it also could be triggered by ml_history if the media library is presnet. The 22268 dev build makes some changes to try to refine things but it'll need more work to have it account for the current ATF strings so if they've got playback related items in them then they'd be expected to trigger an update imho along with possibly seeing about trying to cache some of the metadata from the last played stream when it's no longer active but that's for later on & this quick set of changes should suffice for now.

[toejam119]

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

[dro]

I'm not seeing it change whether I'm waiting a few seconds or up to a few minutes in (unless it's something about the stream being played) but it has always been possible due to how the title changes from the plug-in are triggered (not in_url specific) when it's playing for it to still be seen by the core after having sent the stop action & if that had been queued up whilst it was still in a playing state. That's the only thing I can think of which might be doing it & probably why I'm not currently seeing it happen as different interactions can mess with the timings. I'll come back to this later but I'm not going to hold up putting out a newer preview build as the notsodirect, toast & another loading issue are needed to avoid the main stream of crash reports I'm getting with the 22222 build & it breaking streams for some.

[toejam119]

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

[dro]

Can you provide the stream that you're testing this with please as none of the ones I'm trying are doing this seemingly highly specific timing. As the switch to in_url for things is part of killing off the need / support to re-use in_mp3 for anything in wacup.

[toejam119]

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/

[dro]

I picked the wrong thing to internally check for when the stream is stopping which for some of the streams will have been reset back to acting like there was no stream title despite there having been a title update received at some point. It's an optimisation on the stream implementation side so it doesn't keep sending the same metadata when it's not changed since the client connected to it with it sending an empty 'no change' value but I'd forgotten that can happen. I've changed how I do the checking for the next build so in_url will now flag if it saw a title & that seems to get those urls behaving as expected whilst seemingly not breaking those that had been working with the first 'fix'.

[toejam119]

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.