# Iris Icecast playback stuck in a loop (MOVED)

**URL:** <https://discourse.mopidy.com/t/iris-icecast-playback-stuck-in-a-loop-moved/4016>\
**Category:** Misc\
**Created:** [May 17, 2020, 9:58am UTC](https://discourse.mopidy.com/t/iris-icecast-playback-stuck-in-a-loop-moved/4016 "2020-05-17T09:58:01Z")\
**Posts on this page:** 19\
**Page:** 1

<div class="post-metadata">

**Author:** ![Marco\_Giordano](https://yyz2.discourse-cdn.com/flex036/user_avatar/discourse.mopidy.com/marco_giordano/32/1368_2.png) [@Marco\_Giordano](https://discourse.mopidy.com/u/Marco_Giordano)\
**Post date:** [May 17, 2020, 9:58am UTC](https://discourse.mopidy.com/t/iris-icecast-playback-stuck-in-a-loop-moved/4016/1 "2020-05-17T09:58:01Z")

</div>

Hello everyone,

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

> [@Mopidy is not playing with icecast2](https://discourse.mopidy.com/t/mopidy-is-not-playing-with-icecast2/2469/47):
>
> ```auto
> DEBUG 2019-01-14 16:06:35,332 [2278:Dummy-15] spotify.session
> Audio buffer stats requested, but no listener
> 
> ```

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.

---

<div class="post-metadata">

**Author:** ![kingosticks](https://avatars.discourse-cdn.com/v4/letter/k/858c86/32.png) [@kingosticks](https://discourse.mopidy.com/u/kingosticks)\
**Post date:** [May 17, 2020, 10:33am UTC](https://discourse.mopidy.com/t/iris-icecast-playback-stuck-in-a-loop-moved/4016/2 "2020-05-17T10:33:44Z")

</div>

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.

> [@Marco\_Giordano](#):
>
> Also, this error appears:

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

> [@Marco\_Giordano](#):
>
> it get stucks on a track every 2 hours (circa) until I send a command (mpc next, mpc seek).

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.

---

<div class="post-metadata">

**Author:** ![Marco\_Giordano](https://yyz2.discourse-cdn.com/flex036/user_avatar/discourse.mopidy.com/marco_giordano/32/1368_2.png) [@Marco\_Giordano](https://discourse.mopidy.com/u/Marco_Giordano)\
**Post date:** [May 17, 2020, 12:50pm UTC](https://discourse.mopidy.com/t/iris-icecast-playback-stuck-in-a-loop-moved/4016/3 "2020-05-17T12:50:51Z")

</div>

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](https://canada1.discourse-cdn.com/flex036/uploads/mopidy/original/2X/f/f3b034593db032d4cd102ac333552cdd77cbf8e5.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.**

---

<div class="post-metadata">

**Author:** ![kingosticks](https://avatars.discourse-cdn.com/v4/letter/k/858c86/32.png) [@kingosticks](https://discourse.mopidy.com/u/kingosticks)\
**Post date:** [May 17, 2020, 1:41pm UTC](https://discourse.mopidy.com/t/iris-icecast-playback-stuck-in-a-loop-moved/4016/4 "2020-05-17T13:41:49Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![kingosticks](https://avatars.discourse-cdn.com/v4/letter/k/858c86/32.png) [@kingosticks](https://discourse.mopidy.com/u/kingosticks)\
**Post date:** [May 17, 2020, 1:50pm UTC](https://discourse.mopidy.com/t/iris-icecast-playback-stuck-in-a-loop-moved/4016/5 "2020-05-17T13:50:37Z")

</div>

The looping you see sounds a lot like [https://github.com/jaedb/Iris/issues/528](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.

---

<div class="post-metadata">

**Author:** ![Marco\_Giordano](https://yyz2.discourse-cdn.com/flex036/user_avatar/discourse.mopidy.com/marco_giordano/32/1368_2.png) [@Marco\_Giordano](https://discourse.mopidy.com/u/Marco_Giordano)\
**Post date:** [May 17, 2020, 3:36pm UTC](https://discourse.mopidy.com/t/iris-icecast-playback-stuck-in-a-loop-moved/4016/6 "2020-05-17T15:36:26Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![kingosticks](https://avatars.discourse-cdn.com/v4/letter/k/858c86/32.png) [@kingosticks](https://discourse.mopidy.com/u/kingosticks)\
**Post date:** [May 17, 2020, 3:49pm UTC](https://discourse.mopidy.com/t/iris-icecast-playback-stuck-in-a-loop-moved/4016/7 "2020-05-17T15:49:46Z")

</div>

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

> [@Marco\_Giordano](#):
>
> 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.

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.

---

<div class="post-metadata">

**Author:** ![sapristi](https://yyz2.discourse-cdn.com/flex036/user_avatar/discourse.mopidy.com/sapristi/32/1364_2.png) [@sapristi](https://discourse.mopidy.com/u/sapristi)\
**Post date:** [May 17, 2020, 6:29pm UTC](https://discourse.mopidy.com/t/iris-icecast-playback-stuck-in-a-loop-moved/4016/8 "2020-05-17T18:29:04Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![Marco\_Giordano](https://yyz2.discourse-cdn.com/flex036/user_avatar/discourse.mopidy.com/marco_giordano/32/1368_2.png) [@Marco\_Giordano](https://discourse.mopidy.com/u/Marco_Giordano)\
**Post date:** [May 17, 2020, 8:20pm UTC](https://discourse.mopidy.com/t/iris-icecast-playback-stuck-in-a-loop-moved/4016/9 "2020-05-17T20:20:46Z")

</div>

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`

---

<div class="post-metadata">

**Author:** ![kingosticks](https://avatars.discourse-cdn.com/v4/letter/k/858c86/32.png) [@kingosticks](https://discourse.mopidy.com/u/kingosticks)\
**Post date:** [May 17, 2020, 8:59pm UTC](https://discourse.mopidy.com/t/iris-icecast-playback-stuck-in-a-loop-moved/4016/11 "2020-05-17T20:59:43Z")

</div>

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?

---

<div class="post-metadata">

**Author:** ![Marco\_Giordano](https://yyz2.discourse-cdn.com/flex036/user_avatar/discourse.mopidy.com/marco_giordano/32/1368_2.png) [@Marco\_Giordano](https://discourse.mopidy.com/u/Marco_Giordano)\
**Post date:** [May 17, 2020, 9:07pm UTC](https://discourse.mopidy.com/t/iris-icecast-playback-stuck-in-a-loop-moved/4016/12 "2020-05-17T21:07:52Z")

</div>

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:

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

```

---

<div class="post-metadata">

**Author:** ![Marco\_Giordano](https://yyz2.discourse-cdn.com/flex036/user_avatar/discourse.mopidy.com/marco_giordano/32/1368_2.png) [@Marco\_Giordano](https://discourse.mopidy.com/u/Marco_Giordano)\
**Post date:** [May 17, 2020, 10:54pm UTC](https://discourse.mopidy.com/t/iris-icecast-playback-stuck-in-a-loop-moved/4016/13 "2020-05-17T22:54:02Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![kingosticks](https://avatars.discourse-cdn.com/v4/letter/k/858c86/32.png) [@kingosticks](https://discourse.mopidy.com/u/kingosticks)\
**Post date:** [May 17, 2020, 11:07pm UTC](https://discourse.mopidy.com/t/iris-icecast-playback-stuck-in-a-loop-moved/4016/14 "2020-05-17T23:07:29Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![Marco\_Giordano](https://yyz2.discourse-cdn.com/flex036/user_avatar/discourse.mopidy.com/marco_giordano/32/1368_2.png) [@Marco\_Giordano](https://discourse.mopidy.com/u/Marco_Giordano)\
**Post date:** [May 17, 2020, 11:14pm UTC](https://discourse.mopidy.com/t/iris-icecast-playback-stuck-in-a-loop-moved/4016/15 "2020-05-17T23:14:45Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![blacklight](https://yyz2.discourse-cdn.com/flex036/user_avatar/discourse.mopidy.com/blacklight/32/669_2.png) [@blacklight](https://discourse.mopidy.com/u/blacklight)\
**Post date:** [May 18, 2020, 12:02am UTC](https://discourse.mopidy.com/t/iris-icecast-playback-stuck-in-a-loop-moved/4016/16 "2020-05-18T00:02:33Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![Marco\_Giordano](https://yyz2.discourse-cdn.com/flex036/user_avatar/discourse.mopidy.com/marco_giordano/32/1368_2.png) [@Marco\_Giordano](https://discourse.mopidy.com/u/Marco_Giordano)\
**Post date:** [May 18, 2020, 12:09am UTC](https://discourse.mopidy.com/t/iris-icecast-playback-stuck-in-a-loop-moved/4016/17 "2020-05-18T00:09:19Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![Marco\_Giordano](https://yyz2.discourse-cdn.com/flex036/user_avatar/discourse.mopidy.com/marco_giordano/32/1368_2.png) [@Marco\_Giordano](https://discourse.mopidy.com/u/Marco_Giordano)\
**Post date:** [May 20, 2020, 3:51pm UTC](https://discourse.mopidy.com/t/iris-icecast-playback-stuck-in-a-loop-moved/4016/18 "2020-05-20T15:51:33Z")

</div>

Does anyone have some news about this?

---

<div class="post-metadata">

**Author:** ![kingosticks](https://avatars.discourse-cdn.com/v4/letter/k/858c86/32.png) [@kingosticks](https://discourse.mopidy.com/u/kingosticks)\
**Post date:** [May 20, 2020, 10:08pm UTC](https://discourse.mopidy.com/t/iris-icecast-playback-stuck-in-a-loop-moved/4016/19 "2020-05-20T22:08:08Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![Marco\_Giordano](https://yyz2.discourse-cdn.com/flex036/user_avatar/discourse.mopidy.com/marco_giordano/32/1368_2.png) [@Marco\_Giordano](https://discourse.mopidy.com/u/Marco_Giordano)\
**Post date:** [May 22, 2020, 9:30am UTC](https://discourse.mopidy.com/t/iris-icecast-playback-stuck-in-a-loop-moved/4016/20 "2020-05-22T09:30:03Z")

</div>

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).