-
Notifications
You must be signed in to change notification settings - Fork 14
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Retry on aborted connections #24
Comments
Would like to see this. I get disconnected after a while but I can play again manually. Retry will be good option. |
Any chance this gets fixed? I basically have the similar problem that the plug-in collapses if the opposing streaming server doesn't reply in time:
Playback stops and can not be turned back on. One is forced to restart the mopidy ( |
Isn't that an actual connection error? What is this extension supposed to do here? I'm not interesting in supporting this but will merge a decent PR |
The radio stream stops playing when the connection is reset, and the log contains:
2015-12-08 05:29:42,998 - INFO 304 GET /musicbox_webclient/index.html (192.168.0.213) 13.42ms
2015-12-08 05:29:43,164 - INFO 304 GET /mopidy/mopidy.min.js (192.168.0.213) 11.70ms
2015-12-08 05:29:53,476 - INFO Starting new HTTP connection (1): opml.radiotime.com
2015-12-08 05:30:29,771 - INFO TuneIn API request for Tune.ashx failed: ('Connection aborted.', error(104, 'Connection reset by peer'))
2015-12-08 05:30:29,775 - ERROR Failed to tune station id s225233
2015-12-08 05:30:29,779 - WARNING Track is not playable: tunein:station:s225233
2015-12-08 05:30:39,838 - INFO Starting new HTTP connection (2): opml.radiotime.com
2015-12-08 05:30:42,126 - INFO 200 GET / (127.0.0.1) 42.55ms
2015-12-08 05:30:43,962 - WARNING Element doesn't implement handling of this stream. Please file a bug.
It might be possible to have Mopidy-TuneIn retry a couple of times before giving up, which should make it much more robust.
pydora follows a two-pronged strategy of retrying connections at least once, and also handling specific HTTP-related exceptions with the time between retries increasing exponentially.
It seems to be working well for the Mopidy-Pandora backend and I haven't had any connection issues since - not sure if it can be ported.
The text was updated successfully, but these errors were encountered: