Handle HTTP-related errors #12
Conversation
|
It seems bad to swallow these exceptions in the backend and tell mopidy there is no track available (returning None from _next_track). How will the user know something went wrong or what to do? It seems like Mopidy should be catching exceptions raised by backends and the front end can report an error to the user using whatever UI it has and the user can reload the playlist or whatever. |
|
Agreed. I may be missing something but have not found a way to implement the behaviour you described. Looking at the Mopidy issue linked above, it seems like Mopidy currently also just skips tracks that it cannot play...not sure how to expose this in the UI. |
|
Not being able to display error messages to users is a known issue in Mopidy, see mopidy/mopidy#1011 |
|
Fixed in merged 'Develop' branch. |
The backend should handle HTTP-related errors like timeouts and connection failures, instead of leaving it to the Mopidy core.
Dependent on a fix being released for mopidy/mopidy#1221