Blacklist ap-gew4 access point

[roderickvd]

Only ap-gew4.spotify.com is listed now, but the mechanism allows to add other access points to the blacklist if so necessary in the future.

Fixes #972

[michaelherger]

Works for me. I'd only fear that banning one host would not last for long...

[JasonLG1979]

So far so good. I would much prefer graceful failure and recovery over a blacklist though.

[kingosticks]

In #972 the log shows the error when trying to load a track. Is that because other commands work OK or is that because it's the first command they do that requires a request to the AP? If the latter, could we do a test command soon as the session is active, and then fallback to the next AP in the list if it fails? Rather than trying to gracefully handle request failure everywhere, which sounds like it might be a lot of work?

[JasonLG1979]

@kingosticks That's a really good question. Can we expect that an AP will fail right away or will it work initially but then fail at some later time?

[roderickvd]

So far so good. I would much prefer graceful failure and recovery over a blacklist though.

Not going to happen in dev. Even quite hard to do in new-api but we'll get there eventually.

In #972 the log shows the error when trying to load a track. Is that because other commands work OK or is that because it's the first command they do that requires a request to the AP? If the latter, could we do a test command soon as the session is active, and then fallback to the next AP in the list if it fails? Rather than trying to gracefully handle request failure everywhere, which sounds like it might be a lot of work?

Yes it happens when trying to download an audio file over Mercury. Because this does not happen in new-api when downloading over HTTP even on ap-gew4, I'd rather spend time updating new-api than making this now some sophisticated solution in dev. This just serves as a band-aid.

[JasonLG1979]

Fair enough. I say pull the trigger and do a v0.4.2 (or whatever) release.