Can you provide the exact steps to reproduce using mpc?
See if this makes sense to you. I just loaded a playlist. It started playing the first song, then ran mpc next, as you see next shows the same song again.
As you see couple mpc next changes to next song. No I do not have duplicate songs in the queue.
PC:/opt/xx$ mpc -h 192.168.5.113 -p 6690 next 2-Vagabondi delle stelle [playing] #4/800 0:00/0:00 (0%) volume: 19% repeat: off random: off single: off consume: on PC:/opt/xx$ mpc -h 192.168.5.113 -p 6690 next 2-Vagabondi delle stelle [playing] #3/799 0:00/0:00 (0%) volume: 19% repeat: off random: off single: off consume: on PC:/opt/xx$ mpc -h 192.168.5.113 -p 6690 next 18-Rhapsody on a Theme of Paganini [playing] #1/797 0:00/0:00 (0%) volume: 19% repeat: off random: off single: off consume: on PC:/opt/xx$ mpc -h 192.168.5.113 -p 6690 next 18-Rhapsody on a Theme of Paganini [playing] #1/796 0:00/0:00 (0%) volume: 19% repeat: off random: off single: off consume: on
Here is another issue,
Here it pretends that it is playing the next one (proton radio) but it is still playing “8- The Glade”. It changed the song but it is still stuck in the prev song.
mpc -h 192.168.5.113 -p 6690 play 8-The Glade [playing] #1/97 3:08/0:00 (0%) volume: 19% repeat: off random: off single: off consume: on mpc -h 192.168.5.113 -p 6690 next - Proton Radio [playing] #1/96 0:00/0:00 (0%) volume: 9% repeat: off random: off single: off consume: on
Even the status is wrong . I am %1000 percent it is the same song (8-The Glade), and no not both stations are playing the same song at the same time, checked it already just in case.
mpc -h 192.168.5.113 -p 6690 status - Proton Radio [playing] #1/96 2:51/0:00 (0%) volume: 9% repeat: off random: off single: off consume: on
In my view this has nothing to do with the Mpd implementation because both Moped, musicbox_webclient and Mopidy Android have this issue.
I was hoping for the exact steps so I could copy and paste them to reproduce exactly what you are doing. When you say playlist do you mean playlist or tracklist? Exactly what output config setting are you using here?
It does not matter if it is outputting to pulse, at the moment it is outputting to Snapcast. I have the same issue with Pulseaudio and Snapcast.
I just started testing Snapcast setup, at the time of the initial post, it was pulse audio. But like I said, the result is the same. I have the same issue with the playback whether it is Pulse or Snapcast /tmp/fifo
Not sure about the exact steps. I thought I provided that with the mpc steps
I load a playlist (with radios in it, but happens with local music playlist to) into the current queue, then I applied the steps you I posted above with mpc.
Put this into your playlist folder, as m3u. Load that into your current queue. It starts the first radio, play it for lke 20 secs, then click on the second radio, also try “next”
#EXTM3U #EXTINF:0, - TechnoFM http://centauri.shoutca.st:8154 #EXTINF:0, - Proton http://protonradio.com:8000/schedule
Like I said you can substitud e with Pulse, same issue’
[audio] mixer = software mixer_volume = 20 output = audioresample ! audio/x-raw,rate=48000,channels=2,format=S16LE ! audioconvert ! wavenc ! filesink location=/tmp/snapfifo buffer_time =
So I created a docker image from scratch that does not use the same config, and I still have this issue So this was not a system related thing.
Can some one try what I explained in Frustrating playback glitchy ? It seems like this issue ios very prominent with online radio stuff.
I am almost convinced that Mopidy has some personal issues with streaming online stuff, I am nt getting this glitch playback with local stuff and the reason I have been scratching my head all over here is that , well I listen online radio mostly with it so I keep hitting this issue constantly : (
I guess noone is using Mopidy to listen online radios via .m3u because I am %100 you will have the same mind blowing playback issue that I have here.
I think that the latest Gstreamer updates (1.14.2-dmo1) on Debian Testing improved this issue.
I also ran into this problem with radio streams:
When I put some radio streams in the queue, the first stream is played expected. However, when do ‘next’, the sound stops shortly and the the first stream is played again. However, the displayed track in the UI is the name of the second stream. I have this problem using gmpc as well as with mpdroid. So it doesn’t seem to be an gui issue.
In addition, when adding a playlist (containing a stream) with ‘Add and replace’ using mpdroid, the first stream is still playing but again, the correct (expected) title is shown.
My system is an old RaspberryPi running Arch Linux with gstreamer 1.14.4-1.
Can you please provide:
- Mopidy and Gstreamer debug log using
GST_DEBUG=5 mopidy -vvv. Send this via private message if you prefer.
Just tested mopidy on my PC also running Arch Linux and gstreamer 1.14.4-1: The same wrong behaviour as on the ARM device.
I preparing the requested debug output…
I believe the workaround is found here:
However, I cannot confirm as I do not know how to change the version I have installed on my Mac using Homebrew.
edit: adjusted fix to workaround to label it accurately.
That’s a workaround, sure. It’s not a fix. We do need to support the latest gstreamer release.
Downgrading to gstreamer (and gst-*) to 1.12.4 did not help.
Same problem with gstreamer 1.12.3.
It works without problems with gstreamer 1.12.2 (as mentioned in the ticket).
@kingosticks: I provided additional debug data for 1.12.2 and 1.12.3 for you.
Thanks, that’s very helpful. Could you confirm you see this with local files? The occasional buffering that occurs for the radio streams makes things a bit more complicated and I’d like to make sure it isn’t entirely due to that.
These two bug fixes from https://gstreamer.freedesktop.org/releases/gstreamer/1.12.3.html sound suspicious:
- 786034 : plugins: queue elements: Handle STREAM_START in EOS situation
- 786056 : queue/queue2:: Allow re-usability after EOS
I tried with local files. I only get the problem when starting with a stream and then switching to a local file. I provided another debug output.
local -> stream
local -> local
Both work without a problem.