Mopidy Discourse

Often doesn't switch to next track

In my raspberry-mopidy-Iris installation, it often happens that the playlist doesn’t switch to the next track, but it keeps playing blank at the end of current track. If I manually act on Iris interface to go to next track, it does, but not automatically.
I have to restart mopidy to fix things.
What could it be?

Is it connected to WiFi? I get strange behaviour like that if the network connection drops out.
Is anything happening in the logs? I often see “Spotify is disconnected” “Spotify is connected” as the connection drops and comes back.

Thanks for answering.
Yes, it is connected via WiFi, but the weird thing is that nothing wrong is in the logs. When Spotify gets disconnected (sometimes it happens) I cannot play any Spotify’s playlist at all. This issue instead is only related to “go to next track when current ends”. It doesn’t proceed automatically. (not always, only randomly).

If there is nothing in the logs, turn up the verbosity until we can see what is going on during the track change: Configuration — Mopidy 3.1.1-1-gf17acacf documentation

Does it happen with all backends or only Spotify (I assume this is happening with Spotify tracks, you did not specify).

Having to restart Mopidy is odd. Are you sure you cannot recover by issuing a “stop” command? Or clearing the playlist? I’m not saying those are reasonable workarounds but I am trying to understand what could possibly be so stateful that a restart is required.

Hi Nick. I will make tests as you suggest and come back. In the meantime, this is happening either with Spotify and with local tracks. But, as I said, this behavior is not persistent, it happens randomly that’s why I am trying to figure out the cause.

I understand it’s not persistent between Mopidy restarts but I want to know is it persistent between clearing the tracklist. If you issue a “stop” command it will clear down the tracklist and all the play state. I want to know if that is sufficient to fix the issue.

I also understand from what you say that it’s not consistent. It sounds like it is not track dependent and presumably you’ve done experiments to confirm that. If it’s also happening with local tracks then it’s obviously nothing to do with network connections or Spotify connection status so we can totally ignore that.

This morning it happened again. I then stopped and cleared, then reload the playlist but after the first track it didn’t continue to the next one.
As I have increased logging verbosity, this is what I found in the log:

2021-06-08 09:32:00,223 ERROR [516:HttpServer] asyncio: Future exception was never retrieved
future: <Future finished exception=WebSocketClosedError()>
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/tornado/websocket.py", line 874, in wrapper
    yield fut
  File "/usr/lib/python3/dist-packages/tornado/gen.py", line 1133, in run
    value = future.result()
tornado.iostream.StreamClosedError: Stream is closed

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/tornado/gen.py", line 1141, in run
    yielded = self.gen.throw(*exc_info)
  File "/usr/lib/python3/dist-packages/tornado/websocket.py", line 876, in wrapper
    raise WebSocketClosedError()
tornado.websocket.WebSocketClosedError

Now I had to restart mopidy, so I need to wait for the next failing event to report more

Can we have the full log please, that websocket exception is likely to be a consequence rather than a cause.

here it is:

Can you do a DEBUG level one pleaese. It’ll be big so I suggest you put the verbosity back to something higher afterwards.

I’m wondering if it’s related to

2021-06-07 18:18:12,976 ERROR [516:MainThread] mopidy.audio.gst: GStreamer error: Server does not support seeking.

but I guess it can’t be because you said there was nothing in the log previously so this must be something else going on…