-
Notifications
You must be signed in to change notification settings - Fork 109
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
When starting up pauses every other Spotify client #146
Comments
I cannot reproduce this between instances of mopidy-spotify or my Android client. Only actually playing music causes the play token to be lost. |
Hm, I can't reproduce this as easy as I thought. But it has happened
enough times for me to get so annoyed I reported it at least ; )
I'll update when I can reproduce it 100%.
|
Does Mopidy start in paused or stopped state when this happens? |
Actually Yeh I forgot about that relatively new queue/state restoring functionality. Are you using that? |
Mopidy was in paused state. It just happened now:
I'm now running mopidy with |
Ahh right so it's because it's paused (rather than stopped) and restoring the connection (rather than starting mopidy). I think this is because to get to the paused state we need to go through the play state. A more verbose log would hopefully confirm that. |
That didn't say much:
Gonna run it with three |
Hopefully this makes more sense to you than me because I don't see anything obvious:
Is there any more debug options you can apply other than starting with |
Also, I can now reproduce this 100%. I think the key is that mopidys Spotify playback must be paused, computer suspended (or really network loss), another Spotify player starts to play and then libspotify must get reset by peer. |
I don't think we go through play to get to paused, order is 'NULL -> READY -> PAUSED -> PLAYING' at least on the GStreamer level. Sounds like something I would have had to try and fix for gapless. I think the key part here is libspotify being in offline mode while paused and us incorrectly handling it coming back. |
Any news or ideas here? |
I can now reproduce this thanks to your detailed instructions and and I think I know what's going on:
I think we need a |
This is not an acceptable patch @kingosticks
|
My apologies. I must have missed your input on the PR, how can we rectify
this?
…On Mon, 28 May 2018, 12:25 Simon Lundström, ***@***.***> wrote:
This is not an acceptable patch @kingosticks
<https://github.com/kingosticks>
Spotify songs which were in the saved state are now discarded:
kaka:~$ mopidy
INFO Starting Mopidy 2.1.0
INFO Loading config from builtin defaults
INFO Loading config from /Users/simlu/.config/mopidy/mopidy.conf
INFO Loading config from command line options
INFO Enabled extensions: spotify, mpd, http, stream, m3u, scrobbler, softwaremixer, file, local, local-sqlite
INFO Disabled extensions: none
INFO Starting Mopidy mixer: SoftwareMixer
INFO Starting Mopidy audio
INFO Starting Mopidy backends: StreamBackend, M3UBackend, FileBackend, LocalBackend, SpotifyBackend
INFO Loaded 4512 local tracks using sqlite
INFO Audio output set to "autoaudiosink"
INFO Starting Mopidy core
INFO Logged in to Spotify in offline mode
INFO Loading state from /Users/simlu/.local/share/mopidy/core/state.json.gz
INFO Playback of spotify:track:6g1NlCpW7fgqDnWbCCDrHl failed: Session must be logged in and online to load objects: <ConnectionState.OFFLINE: 4>
WARNING Track is not playable: spotify:track:6g1NlCpW7fgqDnWbCCDrHl
INFO Starting Mopidy frontends: MpdFrontend, HttpFrontend, ScrobblerFrontend
INFO MPD server running at [::1]:6600
INFO HTTP server running at [::ffff:127.0.0.1]:6680
INFO Starting GLib mainloop
INFO Logged in to Spotify in online mode
INFO New MPD connection from [::1]:58387
INFO Scrobbler connected to Last.fm
^CINFO Interrupted. Exiting...
INFO Stopping Mopidy frontends
INFO Stopping Mopidy core
INFO Saving state to /Users/simlu/.local/share/mopidy/core/state.json.gz
INFO Limiting history to 500 tracks
INFO Stopping Mopidy backends
INFO Stopping Mopidy audio
INFO Stopping Mopidy mixer
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#146 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AA5DqBArGP3TgHO-gyCFlPI_jl-ws9h-ks5t296egaJpZM4N_xOG>
.
|
No idea. I think it's very weird that by just applying your patch breaks mopidys state restore. |
I've reproduced this issue both with and without my patch. The patch itself is fine. Unfortunately I can't say the same about the state restore functionality which looks broken for Spotify tracks. There's a race condition between Spotify being ready ('Logged in to Spotify in online mode') and loading the track during playback state restoration. Your log clearly shows Mopidy trying to load the Spotify track before the Spotify backed was ready. I guess whether or not you'll run into this depends on the network and possibly also if the track has been previously played (it may still be cached and therefore already "loaded"). I don't think we currently have any mechanism which allows slow backends to signal core they are really ready - maybe we should. As an alternative, we could move pyspotify's connection state check into the timeout case so we give it an opportunity to become ready; a bit of a hack. Or maybe have mopidy-spotify's on_change function wait with a timeout on a new |
Uh, my bad. I could reproduce it 100% yesterday but I can't today. There were other issues with Spotify yesterday so let's just blame them? ; P If I interpret the logs correctly, and I'm sure I don't, Mopidy-Spotify only needs to be loaded and being in offline mode is OK:
Thanks for the detailed information about the inners of Mopidy-Spotify @kingosticks ! (And for fixing this issue! = ) |
No, being logged in but in offline mode is not enough, you must be in online mode to load a track (the error message explicitly says that).
I've not fixed anything here, it's just not a deterministic issue. If Spotify's servers/your network is slow then you are more likely to hit it. I've opened a new issue at #185 to track how we are actually going to fix this. |
When mopidy with mopidy-spotify is started it pauses every other Spotify client (even other mopidy-spotifies) even though mopidy isn't autostarting the music.
The text was updated successfully, but these errors were encountered: