[CHANGES MADE] 30 MB dl from getwacup before radio starts

[Nahsty]

hi.

was wondering why was it taking so long for radio to get going after restart of WACUP.

turns out,
when first starting a radio wacup takes some time to download something (30+ MB) from getwacup.com;
and after that it's generally smooth sailing.

oh, and i have "Internet access" disabled, so i find it a bit weird.

[dro]

What do you mean by radio? The internet radio view or a http / youtube url or something else?

As depending on what action is involved it could be the internet radio cache related to the internet view in the media library window or one of the supporting tools needed to be able to play internet content such as youtube (but that should be a one time download unless it's not being kept between instances).

That prefs option doesn't completely disable everything per it's notes otherwise I'd be getting complaints urls don't work even if that's what it should do (maybe I should refine it to make sure it does kill any internet access even if it breaks streaming url playback).

[Nahsty]

1.99.43.23234

and again, it has something to do with MP3.

for example, Chillstep.info has two streams:
OGG: http://chillstep.info:1984/listen.ogg
and
MP3: http://chillstep.info:1984/listen.mp3

when i start WACUP and select OGG stream, an immediate connection is made to chillstep.info:1984

Code: [Select]

[12.16 16:35:48] wacup.exe - 127.0.0.1:60484 open directly
[12.16 16:35:48] wacup.exe - chillstep.info:1984 open directly
however,
if i start WACUP and select MP3 stream [or even just switch from OGG stream], it connects to getwacup.com:443 to download some 30 MB of data. afterwards it's all good and i can switch streams without issue

Code: [Select]

[12.16 16:36:42] wacup.exe - 127.0.0.1:60502 open directly
[12.16 16:36:42] wacup.exe - getwacup.com:443 open directly
[12.16 16:36:43] wacup.exe - 127.0.0.1:60502 close, 9 bytes sent, 1 bytes received, lifetime <1 sec
[12.16 16:36:43] wacup.exe - 127.0.0.1:60509 open directly
[12.16 16:36:43] wacup.exe - getwacup.com:443 close, 1927 bytes (1.88 KB) sent, 51174 bytes (49.9 KB) received, lifetime <1 sec
[12.16 16:36:43] wacup.exe - getwacup.com:443 open directly
[12.16 16:36:53] wacup.exe - 127.0.0.1:60509 close, 9 bytes sent, 1 bytes received, lifetime <1 sec
[12.16 16:36:53] wacup.exe - 127.0.0.1:60516 open directly
[12.16 16:36:53] wacup.exe - getwacup.com:443 close, 2177 bytes (2.12 KB) sent, 32536148 bytes (31.0 MB) received, lifetime <1 sec
[12.16 16:36:53] wacup.exe - chillstep.info:1984 open directly

[12.16 16:36:43] wacup.exe - getwacup.com:443 open directly
[12.16 16:36:53] wacup.exe - getwacup.com:443 close, 2177 bytes (2.12 KB) sent, 32536148 bytes (31.0 MB) received, lifetime <1 sec

and it is not a streaming service issue: i first noticed it on di.fm

[dro]

The 31MB size doesn't align directly to the supporting tools that might be pulled down if they're deemed to be missing though I've got to assume that the size reported in the capture has networking overhead as part of it for whichever file it is from the server. If so the other connection shown is likely related to version checks.

The nearest at ~28MB could be one of 2 files related to yt-dlp which the plug-in that handles MP3 streams is the one that also handles yt-dlp & yt playback but it shouldn't be repeatedly trying to get any of them every time wacup is started against the first attempt to play a stream unless there's some config issue I'm missing which is preventing that being pulled down.

Is there a WACUP_Tools folder in the root of the WACUP settings folder (usually %appdata%\WACUP though Preferences -> Advanced -> Diagnostics -> Settings Locations will show what your install is using. Though I've just had a go in renaming the existing folder in one of my test installs & it re-created that folder as needed & hasn't made any new attempts to download the tool that go in there after the first check made. That was also done with the internet access option off per my prior reply as I don't block stream playback when it's disabled (otherwise none of the streams would play).

However the handling for getting yt-dlp & related tools for it shouldn't be triggered when trying to play the example stream so I will look into avoiding that as it's a left over from when the in_url plug-in was re-worked to support more streams instead of just those via yt-dlp where it needed to ensure that was present but everything I've seen so far doesn't explain your issues.

[Nahsty]

yep,
yt-dlp_ffmpeg.7z is being downloaded every time despite deno.exe and yt-dlp_x64.exe already present in WACUP_Tools folder.

[dro]

That's not the correct size for that file & if it's always incomplete then no wonder it keeps trying to get it.

[Nahsty]

it is still in a process of downloading on a screenshot.
can't really catch the exact size, since it gets deleted right after dl is complete.

[dro]

If it was complete then there'd be an ffmpeg copy present so either that's happening & it's then being blocked by say an A/V solution or the download is incomplete so it never makes it to extraction (per other checks in place). Either way, for generic urls the youtube handling shouldn't be running & that's been changed for the next build. Is just a good thing you're not trying to play youtube content as that wouldn't work properly with whatever is causing the supporting tools to not be correctly obtained & extracted out.

[Nahsty]

i don't have any A/V software, even Windows Defender is nuked.

can you share yt-dlp_ffmpeg.7z as a temporary workaround?

[dro]

Just wait a few days for when I should have a new build ready to go up to resolve this & unrelated issues for other users.

[Nahsty]

well,
having ffmpeg.exe in WACUP_Tools solves my issue.

cheers.

[dro]

23402/23410 brought the changes I'd mentioned were needed.