sspiff / lms-plugin-pyrrha

Pyrrha - Daughter of Pandora
GNU General Public License v2.0
13 stars 4 forks source link

playback stops or does not start after 4 hours #15

Closed sspiff closed 6 months ago

sspiff commented 6 months ago

Playback may stop after 4 hours or, if paused for a long time, may not restart after 4 hours since first play.

Symptomatic log message sequence:

Plugins::Pyrrha::ProtocolHandler::getNextTrack (125) fetching new playlist
Plugins::Pyrrha::Utils::getStationList (74) using cached station list
Plugins::Pyrrha::Utils::__ANON__ (163) auth token expired, clearing cache
Plugins::Pyrrha::Utils::__ANON__ (168) station.getPlaylist error 1001: An unexpected error occurred

Workaround: pressing play again should restart playback.

nabertrand commented 6 months ago

What do you think about having every API call re-authenticate so the token is never expired? I wrapped all of the API calls in a method that authenticates first here: https://github.com/nabertrand/lms-plugin-pandoradirect/blob/0c56d73b75ce617c2629d4d1af78c1036ee74cd2/Plugin.pm#L72-L82. My thinking was that the API actually isn't called all that often so there wouldn't be too many authentication requests.

sspiff commented 6 months ago

Haha, that's one way to do it! During playback, I guess you'd be re-authing every four tracks, so several times an hour depending on track length?

My original approach was to cache aggressively so as not to harass the API and because Pyrrha was originally using blocking IO to the API. To that end, I had it waiting for a 1001 error code, then clearing the cache, and then letting LMS actually retry the higher level operation (i.e. "start playback"). Now it proactively expires the cached auth token after 4 hours.

But, had an oversight with trying to re-use a cached copy of the station list that prevented the proactive expiration when fetching a new playlist, hence this issue. Got a fix for it coming up.

Going forward, if these kinds of things keep popping up, will have to consider caching less.