Iris Icecast playback stuck in a loop (MOVED)

Hello everyone,

I’m having the same issue using spotify and the shout2send audio output. Also, this error appears:

I’m running Mopidy as a service and it get stucks on a track every 2 hours (circa) until I send a command (mpc next, mpc seek).

Another strange behaviour is that, with some songs, it continues to play a song after it ends, sending silence (for example, if a song is 6:20, it continues to play after 6:20 with silence, until i do some action).

I’m using Mopidy with Iris but i’m noticing that this is related to gstreamer as the errors are all about gstreamer.
Gstreamer version is 1.0.
Running on a RPI4 with Buster.
No pulseaudio or any other sound is installed, it is a fresh install of mopidy on a fresh new RPI.

Than you for any help.

This topic one is well over a year old and is regarding an old version of Mopidy. Even if you think it’s the same problem, please start a new topic and provide the requested extra information in that new topic.

That’s not an error. That’s a debug message. You can ignore that.

Can you be more specific? What does “stucks” mean exactly? Does it stop producing audio? Does the playing time stop incrementing? Does it change to paused or remaining in the playing state? Does this problem occur when you do not use icecast? Does this happen with other music sources (local files, radio streams etc?).

Also need your mopidyctl config and mopidyctl deps output.

So far I have not seen any gstreamer error messages in your post. Please provide a log demonstrating the issue and point out at which point the issue occured.

There’s information in our troubleshooting documentation if you have problems with any of this.

Hello and thank you for fast response.

I’m sorry to reopen an old thread but i think I’m experiencing an issue that has something to do with this thread. And this issue is present on 4 different RPI that streams to 4 differents Icecast, using 4 different spotify versions. Same OS for all but 2 of them running mopidy 3.0.1, the other two are running mopidy 3.0.2.

What i mean with “stack” is that Iris is stuck on one track and it is possible to see that it tries to play it: it starts from 00:00 then it comes to 00:04 and return to 00:00. No audio is produced when this issue appears. You can see this here:
ezgif.com-video-to-gif

If I send some play command like next or seek, mopidy and iris restart to play and send audio.

Here you can find some info you requested for:

Mopidy Version: 3.0.2

Mopidy deps:
Running “/usr/bin/mopidy --config /usr/share/mopidy/conf.d:/etc/mopidy/mopidy.conf deps” as user mopidy
X11 connection rejected because of wrong authentication.
Executable: /usr/bin/mopidy
Platform: Linux-4.19.97-v7l±armv7l-with-debian-10.4
Python: CPython 3.7.3 from /usr/lib/python3.7
Mopidy: 3.0.2 from /usr/lib/python3/dist-packages
Mopidy-MPD: 3.0.0 from /usr/lib/python3/dist-packages
Mopidy-Spotify: 4.0.1 from /usr/lib/python3/dist-packages
Mopidy-Iris: 3.46.0 from /usr/local/lib/python3.7/dist-packages
Mopidy: 3.0.2 from /usr/lib/python3/dist-packages
Pykka: 2.0.2 from /usr/lib/python3/dist-packages
setuptools: 40.8.0 from /usr/lib/python3/dist-packages
GStreamer: 1.14.4.0 from /usr/lib/python3/dist-packages/gi
Detailed information:
Python wrapper: python-gi 3.30.4
Relevant elements:
Found:
uridecodebin
souphttpsrc
appsrc
alsasink
osssink
oss4sink
pulsesink
id3demux
id3v2mux
lamemp3enc
mpegaudioparse
mpg123audiodec
vorbisdec
vorbisenc
vorbisparse
oggdemux
oggmux
oggparse
flacdec
flacparse
shout2send
Not found:
flump3dec
mad

Mopidy config:
[core]
cache_dir = /var/cache/mopidy
config_dir = /etc/mopidy
data_dir = /var/lib/mopidy
max_tracklist_length = 10000
restore_state = false

[logging]
verbosity = 0
format = %(levelname)-8s [%(threadName)s] %(name)s %(message)s
color = false
config_file =

[audio]
mixer = software
mixer_volume =
output = lamemp3enc ! shout2send async=false mount=mount ip=icecastip username=icecastuser port=icecastport password=icecastpass
buffer_time = 50

[proxy]
scheme =
hostname =
port =
username =
password =

[iris]
enabled = true
country = NZ
locale = en_NZ
spotify_authorization_url = https://jamesbarnsley.co.nz/iris/auth_spotify.php
lastfm_authorization_url = https://jamesbarnsley.co.nz/iris/auth_lastfm.php
genius_authorization_url = https://jamesbarnsley.co.nz/iris/auth_genius.php
data_dir = $XDG_DATA_DIR/iris

[file]
enabled = true
media_dirs =
  music/
excluded_file_extensions =
  .directory
  .html
  .jpeg
  .jpg
  .log
  .nfo
  .pdf
  .png
  .txt
  .zip
show_dotfiles = false
follow_symlinks = false
metadata_timeout = 1000

[http]
enabled = true
hostname = 0.0.0.0
port = 6680
zeroconf = Mopidy HTTP server on $hostname
allowed_origins =
csrf_protection = true
default_app = mopidy

[m3u]
enabled = true
base_dir =
default_encoding = latin-1
default_extension = .m3u8
playlists_dir =

[softwaremixer]
enabled = true

[stream]
enabled = true
protocols =
  http
  https
  mms
  rtmp
  rtmps
  rtsp
metadata_blacklist =
timeout = 5000

[spotify]
enabled = true
username = myusername
password = ********
client_id = myid
client_secret = ********
bitrate = 160
volume_normalization = true
private_session = false
timeout = 10
allow_cache = true
allow_network = true
allow_playlists = true
search_album_count = 20
search_artist_count = 10
search_track_count = 50
toplist_countries =

[mpd]
enabled = true
hostname = ::
port = 6600
password =
max_connections = 20
connection_timeout = 60
zeroconf = Mopidy MPD server on $hostname
command_blacklist =
  listall
  listallinfo
default_playlist_scheme = m3u

Mopidy error:
mag 17 13:12:29 raspberrypi systemd[1]: Started Mopidy music server.
mag 17 13:12:30 raspberrypi mopidy[20531]: INFO [MainThread] mopidy.main Starting Mopidy 3.0.2
mag 17 13:12:30 raspberrypi mopidy[20531]: INFO [MainThread] mopidy.config Loading config from builtin defaults
mag 17 13:12:30 raspberrypi mopidy[20531]: INFO [MainThread] mopidy.config Loading config from file:///usr/share/mopidy/conf.d/mopidy.conf
mag 17 13:12:30 raspberrypi mopidy[20531]: INFO [MainThread] mopidy.config Loading config from file:///etc/mopidy/mopidy.conf
mag 17 13:12:30 raspberrypi mopidy[20531]: INFO [MainThread] mopidy.config Loading config from command line options
mag 17 13:12:30 raspberrypi mopidy[20531]: INFO [MainThread] mopidy.main Enabled extensions: http, file, stream, mpd, spotify, m3u, softwaremixer, iris
mag 17 13:12:30 raspberrypi mopidy[20531]: INFO [MainThread] mopidy.main Disabled extensions: none
mag 17 13:12:30 raspberrypi mopidy[20531]: INFO [MainThread] mopidy.commands Starting Mopidy mixer: SoftwareMixer
mag 17 13:12:30 raspberrypi mopidy[20531]: INFO [MainThread] mopidy.commands Starting Mopidy audio
mag 17 13:12:30 raspberrypi mopidy[20531]: INFO [MainThread] mopidy.commands Starting Mopidy backends: FileBackend, M3UBackend, StreamBackend, SpotifyBackend
mag 17 13:12:30 raspberrypi mopidy[20531]: INFO [Audio-2] mopidy.audio.actor Audio output set to “lamemp3enc ! shout2send async=false mount=audio ip=icecastip username=icecastuser port=iceport password=icepass”
mag 17 13:12:31 raspberrypi mopidy[20531]: INFO [SpotifyEventLoop] mopidy_spotify.backend Logged in to Spotify in online mode
mag 17 13:12:31 raspberrypi mopidy[20531]: INFO [SpotifyBackend-6] mopidy_spotify.web Logged into Spotify Web API as dkuch7i32extu2ic2tzhhn8gb
mag 17 13:12:35 raspberrypi mopidy[20531]: INFO [SpotifyBackend-6] mopidy_spotify.playlists Refreshed 6 Spotify playlists
mag 17 13:12:35 raspberrypi mopidy[20531]: INFO [MainThread] mopidy.commands Starting Mopidy core
mag 17 13:12:35 raspberrypi mopidy[20531]: INFO [MainThread] mopidy.commands Starting Mopidy frontends: IrisFrontend, HttpFrontend, MpdFrontend
mag 17 13:12:35 raspberrypi mopidy[20531]: INFO [IrisFrontend-10] mopidy_iris.core Starting Iris 3.46.0
mag 17 13:12:35 raspberrypi mopidy[20531]: INFO [HttpFrontend-12] mopidy.http.actor HTTP server running at [::ffff:0.0.0.0]:6680
mag 17 13:12:35 raspberrypi mopidy[20531]: INFO [MainThread] mopidy_mpd.actor MPD server running at [::]:6600
mag 17 13:12:35 raspberrypi mopidy[20531]: INFO [MainThread] mopidy.commands Starting GLib mainloop
mag 17 13:14:54 raspberrypi mopidy[20531]: ERROR [HttpServer] mopidy_iris.core Connection “GALF4IDNZKQQ” not found
mag 17 14:21:42 raspberrypi mopidy[20531]: ERROR [MainThread] mopidy.audio.gst GStreamer error: Could not write to resource.

This is a totally new error seen in these earlier posts. I don’t think this is related and I will move it.

The looping you see sounds a lot like https://github.com/jaedb/Iris/issues/528 to me. I would be interested to know if you see this problem outside of Iris or if it’s specific to when using Iris. The resolution to that issue doesn’t apply to someone using Spotify but I’m not convinced that was what fixed it. But you could try using another webclient and I’ll ask again that you test without using icecast.

Thnk you @kingosticks,

I don’t know if this is the same issue as the one you linked but (if I unsterstood) I don’t have mysql server nor client in any of my rpi.

I can try to uninstall Iris and try with MusicBox and se if these error throw away.

On one rpi I also have the audio output to pulsesink (also using Iris) and that issue is present but randomly; here it happens at least one time every two hours.

You do not need to uninstall Iris. You just need to install some other web client (try https://mopidy.com/ext/musicbox-webclient/) and test with that.

If you have the same issue without icecast then I think we can rule out icecast being the problem. So let’s now work on finding out what is the common factor, so far it appears to be Iris so please test using another client.

Well Iris does have some server side features (running in background even when it’s not the current client in use), so trying with it uninstalled might be worth it.

I just tried by uninstalling Iris and using MusicBox and unfortunately I had the same error (but after more time):
mag 17 20:25:14 raspberrypi mopidy[24822]: ERROR [MainThread] mopidy.audio.gst GStreamer error: Could not write to resource.

Same error from mopidy with audio output to pulsesink.

Now I’ve ran mpc next to restart the audio playing and I’ve noticed that mopidy something like reconnected to spotify:
mag 17 21:55:07 raspberrypi mopidy[24822]: INFO [SpotifyEventLoop] mopidy_spotify.backend Logged in to Spotify in online mode

That’s not an error, that INFO message is fine. But I see what you mean, it’s like it lost network connection.

So what exactly is the pulse sink output you have configured? Is it sending to a remote pulse server? Is this just the network connection failing? Does this happen with a normal local alsa output?

Sorry for the “error” mistake but I thought it was strange as it comes out after running the next command (maybe, at some point, spotify is disconnecting the client? I don’t know if they have such a functionality).

The main problem is the mopidy that is using shout2send.
It is running as a service (sudo service mopidy start) and this issue happens when a track finishes and the next one has to play (they all come from a playlist as I’m playing an entire playlist in loop) and it get stucked on the start, like that track was never really downloaded or something like that.

The out sink in audio is:

output = lamemp3enc ! shout2send async=false mount=mount ip=icecastip username=icecastuser port=icecastport password=icecastpass

I was able to reproduce many times this issue manually:

While using MusicBox and mopidy’s audio out to shout2send, when i hit pause and wait at least 6-8 seconds and then press play, MusicBox gets stuck and that gstream error is reproduced. It restart to works when i press play another time.

And you say you see this exact same behaviour with pulsesink also? Or is that incorrect?

On the pulsesink one it seems not to be reproducible by hand so no, not the same behaviour.

Another thing: when this issue happens when manually triggered, I can hear (on the Icecast stream) first a silence (and this is correct as the fallback stream starts when mopidy is sending no data to it) and - after a few second - the last 1 second of music of the audio feed coming from mopidy before it was stopped.

Could it be related to Icecast, something like it can’t accept the audio stream and then mopidy cannot create the pipe?

Sorry for any mistake but I’m not that expert.

FYI the same issues with gstreamer+Icecast still occur on all of my installations as well. The only reason why I stopped bumping the issue is because in the meantime I went for a Snapcast-based solution to handle my multiroom setup, but any fix on the Icecast integration side will greatly help.

I’ve created a script that detects for Icecast stream silence and, if silence is more than n seconds, it triggers an mpc seek +00:00:01 or curl so the stream tries to restart from the point it stopped. Of course, when this issue happens and you hit the seek bar or play button, it goes at the starting point of the track, so you only can restart from a song’s starting point.

This is not a solution but maybe a small workaround if you need to use Icecast with Mopidy without pulseaudio and any other third party encoder.

Does anyone have some news about this?

Can you try and reproduce with a local, rather than a Spotify track? Our Spotify backend is slightly different from the others and it’d be helpful to know if it’s specific to the combination of Spotify and Icecast or not. GStreamer’s Icecast element is a little suspect in general and it’s possible this is just some bug in GStreamer v1.14. Testing with v1.16 would also be useful but that’s a little bit tricky to get setup, I’m not sure the best way to do that.

I’m now trying with a local track. Also, this issue is present on a raspberry with mopidy’s audio out to pulsesink server (on localhost, 127.0.0.1).