open()ing a URL hangs if network is very slow

[flagoworld]

Superpowered version: 2.6

Describe the bug call open() multiple times before a URL has time to open due to slow network connection

Steps to Reproduce

Superpowered::httpRequest *request = new Superpowered::httpRequest("https://example.com/some/song.mp3");
request->addHeader(uaKey, Superpowered::httpDataMode::Copy, uaVal, Superpowered::httpDataMode::Copy);
request->timeoutSeconds = 30;
request->maximumBytesToReceive = 1024 * 1024 * 1024;
player->open("https://example.com/some/song.mp3", request);

Call it multiple times on the same player

Expected behavior I expect the previous connection attempt to be canceled and the new one to begin (async network ops)

Actual behavior The player hangs (sem wait) for a while until the connection fails or succeeds, then eventually starts working again.

Device information Please list which devices have this bug. iPhone, probably everything else too

[yoshi-hun]

Hello! This behaviour seems to be the expected, if you have a look at SuperpoweredAdvancedAudioPlayer.h:116, it says as a warning: This method has no effect if the previous open didn't finish or if called in the audio processing thread. You should not call open() multiple times blindly, you can call player->getLatestEvent() periodically, to check on the status of open(). You can check possible return values of said function here, the ones starting with PlayerEvent_ are the ones you need, you can also find their meaning there.

[flagoworld]

That leaves the possibility for the program to be unable to function for quite a long time. There must be a way to cancel the request and allow open() to be called again? Especially with poor cellular reception, the hang can last for a minute or more. Very bad UX.

[yoshi-hun]

The open() function should not be called in the UI thread, this potentially takes more time even with good connection. If you are still worried about it taking too long, maybe try with a lower http request timeout. Superpowered::httpRequest unsigned int timeoutSeconds; ///< Timeout in seconds. Default: 60

[flagoworld]

OK, but that doesn't solve the underlying problem really. I have already changed my code to keep track of opening state and run open() on another thread, but the user still is unable to do anything until open() times out. Even if the UI isn't locked up, it is essentially stuck in a loading state for a while. That is bad UX. There needs to be a way for the user to cancel or override the existing open() operation. You know what I mean?

[yoshi-hun]

Unfortunately, there is no way to cancel the operation besides it timing out.