You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
According to src/http.rs#L15, the default timeout for updating is 1 hour. This is quite insane, as who's prepared to wait an hour to download an update?
My current network blocks spotify, however allows the connection to open - this means that spotify-launcher hangs for an hour before giving up, unless --skip-update is passed (which isn't ideal when I'm only on this network 4 out of 7 days of the week, for a few hours each day).
Are there any plans to allow the timeout to be configurable, or at the very least lowered?
The text was updated successfully, but these errors were encountered:
I think I misread the documentation back then and confused it with tokio::time::Timeout, which would be the timout for the entire download operation. I've changed the timeout to 10 seconds, which means if no data was transfered for 10 seconds it's going to fail the download. This might be annoying when trying to do the initial download over a very slow/unreliable connection but probably better than the startup being stuck for a very long time when there's already an installation we could use.
I read the documentation correctly, the timeout is for the whole duration of the request, so setting this to 30 means the download is going to fail for everybody who can't download that fast.
I've refactored this with tokio::time::Timeout so it's based on inactivity and released it in 0.4.1.
According to src/http.rs#L15, the default timeout for updating is 1 hour. This is quite insane, as who's prepared to wait an hour to download an update?
My current network blocks spotify, however allows the connection to open - this means that spotify-launcher hangs for an hour before giving up, unless
--skip-update
is passed (which isn't ideal when I'm only on this network 4 out of 7 days of the week, for a few hours each day).Are there any plans to allow the timeout to be configurable, or at the very least lowered?
The text was updated successfully, but these errors were encountered: