mopidy: mopidy (mpd frontend) stuck in playing state after last song of queue

Since some time (I can’t tell in versions), mopidy doesn’t exit the playing state after the last queued song has been played. mpd clients continue to report that mopidy is still playing.

E.g. currently, the last song stopped (audibly) playing a few minutes ago and I receive this output:

languitar@miles ~ [1]> mpc -h 192.168.1.8
Andre Manoukian - Blow !
[playing] #12/12   0:00/3:06 (0%)
volume: 68%   repeat: off   random: off   single: off   consume: off

It is possible to manually stop playing in this state:

languitar@miles ~> mpc -h 192.168.1.8 stop
volume: 68%   repeat: off   random: off   single: off   consume: off
languitar@miles ~> mpc -h 192.168.1.8
volume: 68%   repeat: off   random: off   single: off   consume: off

I first thought this might be an issue with the spotify backend, but this also happens for local media files, so seems to be more general. This is also happening with and without consume mode.

I am using Mopidy 2.0.1 on archlinux 64 bit.

About this issue

  • Original URL
  • State: open
  • Created 8 years ago
  • Comments: 23 (13 by maintainers)

Most upvoted comments

I had the same problem when using Snapcast. By sending stream end message to listeners in case of an error gets me past the problem:

https://github.com/gotling/mopidy/commit/c13ab38b184f4b8902d1b0b8e75adcd423eaccc9

It looks as though two days ago BadAix bumped the version of Snapcast to 18.0 which, if I’m reading correctly, moved his TCP stream into the Master branch and I’ve confirmed that he has compiled armhf versions on his download page.

woot!

I would love a fix for this. Did anyone find a solution? Could we merge the change by @gotling ?