search

PromyLOPh / pianobar

Console-based pandora.com player
http://6xq.net/pianobar/
Other
1.73k stars 323 forks source link

Pianobar takes several failures before it will reauthenticate after 403's #731

Closed nneul closed 2 years ago

nneul commented 2 years ago

Subject of the issue

Client doesn't reauthenticate until it's 403 failed multiple times.

Your environment

Steps to reproduce

Pause playback for a while (multiple minutes+) Resume playback It will play for a bit to exhaust buffer, then it will get a failure typically - the issue is it gets multiple 403's in a row with each new track outputting "Unable to open audio file (Server returned 403 Forbidden (access denied)) - then it hits the "Receiving new playlist" message. At THAT time, it realizes it needs to reauthenticate and works fine.

This is a quick operation, but it winds up skipping through multiple tracks to get there. It would be better if it triggered reauthentication after the first 403.

DISREGARD [(Independently, it would be GREAT if it could continue buffering the song in background up to the end of the song even while paused so that it wouldn't chop it off at buffer-size when resumed, but that's a whole separate issue.)]

Expected behaviour

Ideally, it should reauthenticate and re-attempt the same request that it got the 403 for, but at least, if it gets a 403, reauthenticate immediately and not 3 failures in a row.

Actual behaviour

Fails 3 times, then reauthenticates only when getting a new playlist chunk.

nneul commented 2 years ago

Just noticed the buffer_seconds config option - going to give that a try for at least the buffer question - not sure if it will address it or not, but the core issue of the reauthentication I don't expect that to have any effect.

nneul commented 2 years ago

Confirmed, increasing buffer side addressed the cutting-off issue.

PromyLOPh commented 2 years ago

Unfortunately this is by design. Pandora sends back four tracks for every playlist query. So pianobar does not know it needs to re-authenticate until it requests the next playlist (i.e. after failing to play expired song urls). Unfortunately the API does not expose when exactly token or playback URLs expire, so there is no reliable way to circumvent the situation – except for trying and failing.

As for the audio buffer issue: As you figured out yourself you can indeed just increase the in-memory buffer and the problem should be gone.

nneul commented 2 years ago

Oh - so it's not that the authentication has expired - it's that the previous playlist returned pre-authenticated urls that are expired, and you only authenticate during the retrieval of the list of urls (new playlist chunk). That makes sense.