mirror of
https://github.com/jpochyla/psst.git
synced 2026-04-27 07:25:52 +03:00
[GH-ISSUE #377] Network flakiness #258
Labels
No labels
api
bug
build
documentation
duplicate
enhancement
good first issue
help wanted
idea
invalid
linux
lowprio
macos
pull-request
upstream
windows
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/psst#258
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @onpaws on GitHub (Mar 12, 2023).
Original GitHub issue: https://github.com/jpochyla/psst/issues/377
Describe the bug
I've been a Psst user for a while, thanks for your nice work on it.
Not sure if it's just me, but for the past few days I experience strange network behavior.
Unclear if this issue originates from Spotify's server/CDN story, or how Psst connects, or somewhere else.
Does anyone else have this issue?
Basically since ~Thursday March 9, when Psst tries to request from api.spotify.com, it gets
Network Error: timed out reading responseCuriously if I use a VPN, this error doesn't occur and Psst connects as usual.
Meanwhile regardless of VPN, Spotify.app and https://open.spotify.com are working as usual.
I tried deleting the config.json and re-logging in, but unfortunately no change in Psst behavior.
To Reproduce
Open Psst.
Expected behavior
Psst should show default content (songs, playlists, etc)
Screenshots

Environment
Additional context

Psst release is dated Feb 11
Happy to provide more logs/etc to help debug, just let me know.
@arch-btw commented on GitHub (Mar 28, 2023):
Hello @onpaws have you also tried deleting the cache folder? That worked for me with a similar issue.
@jacksongoode commented on GitHub (Mar 29, 2023):
There is definitely some network flakiness, I've also seen it break in the midst of a VPN connection.
@onpaws commented on GitHub (Mar 30, 2023):
Sounds like you may be suggesting the cache key(s) being somehow dependent on network status? Interesting.
I'll try that next time, thanks