MA cannot resume a paused podcast

[jvrijn]

What version of Music Assistant has the issue?

2.4.4

Have you tried everything in the Troubleshooting FAQ and reviewed the Open and Closed Issues and Discussions to resolve this yourself?

• Yes

The problem

When I tried to resume a podcast after pausing it, it takes a few seconds, then the progress bar under the play button jumps to fully played. The podcast is not resumed. Scrolling through the progress bar also does not work and has the same effect, after a few seconds of silence, the progress bar jumps to the end. In both cases, the podcast is marked as played in the episodes list.

How to reproduce

Using the UI in Safari on a Mac, load up a longer podcast (I was listening to one 50 minutes long). After playing has started, hit pause, wait a few minutes and hit play.

Music Providers

I am using an RSS Podcast feed. (https://podcast.npo.nl/feed/met-het-oog-op-morgen.xml)

Player Providers

SONOS

Full log output

music-assistant.log

Additional information

I am only using MA through the UI, using Safari on Mac OS (all up-to-date). MA is running on a Raspberry Pi 4 as an add-on for Home Assistant, running in HAOS, all up-to-date. All the SONOS equipment, the HAOS Server, and the computer from which the player is controlled are on the same Unifi network segment. I have restarted MA, but this did not resolve the issue. The HA network setting is Auto, but the IP address is set to static in the DHCP server and is correct.

What version of Home Assistant Core are your running

2025.3.3

What type of installation are you running?

Home Assistant OS

On what type of hardware are you running?

Raspberry Pi

Have you included ALL of the information specified in the Troubleshooting FAQ or explained why you cannot

• Yes

[OzGav]

Have you tried a different player provider? Use snapcast if you don’t have one.

[jvrijn]

Hi @OzGav, thanks for the reply. I do not see a way to use SnapCast with my existing SONOS 2 speakers. However:

I disabled the SONOS player provider and tried Apple Airplay. Initially, I was able to pause and restart a podcast. Then, I tried jumping forward in the podcast by clicking on the progress bar. On the first try that worked, on the second try it did not. The progress bar stays in the same spot, the play/pause button shows the pause icon, indicating it is playing. However, nothing is happening. Trying to play another source on the same speaker from MA also results in no sound. I restarted the MA add-on, went back to the podcast in MA and told it to play on the same speaker, the progress bar jumps to the last point in the podcast, play button shows Pause icon, still no sound.

I also tried the UPnP/DLNA and Chromecast player providers, but MA does not pick up the SONOS speakers.

[OzGav]

@saeugetier

[saeugetier]

I will try to reproduce the problem, but I have no Sonos available. So I take a look whether this is a general problem.

[OzGav]

The idea was to use Snapcast as a DIFFERENT player to see if this problem is with the music provider or the player provider. Sonos continues to make breaking changes. A fix for one is in beta 16. I recommend you try and reproduce this with Snapcast in the first instance. If you can't then try beta 16. If that doesn't fix it then amend the title of this issue to reflect that it is a problem with SONOS

[jvrijn]

Hi @OzGav
I had a Rpi Zero 2W and a ReSpeaker 2Mic Hat and speaker laying around and I set up a Snapcast client to try this out. I loaded the Snapcast player provider in MA. Used the built-in Snapcast server in MA. Issues are similar. I loaded up a long podcast (~55 min) from the aforementioned RSS using the browser UI (Mac OS X, Safari). The podcast starts to play. About halfway through, I hit pause and walked away from my computer for an hour or more. Came back, hit play again. It took 55 seconds to resume playing over the speaker.

I also tried scrolling forward in the podcast by clicking in the progress bar. The first time, it was a small leap and it worked. Second time was a big leap from around 3 mins in to about 30 mins in and playback stopped and never resumed (I gave up after several minutes). Play/pause button showed pause icon. At this point I tried playing a radio station using Tune-In Radio in MA on the Snapcast Client with Play Now (clear queue). Playback of the radio station did not start before my patience ran out (several minutes).

I restarted the Pi with the Snapcast client and tried playing the radio station again, but still nothing happened. I then restarted the MA add-on and was able to start the radio playback.

Hope that helps in finding the bug.

[OzGav]

Can you try the latest beta? https://www.music-assistant.io/release/#running-parallel-server-versions

[marcelveldt]

I'm like 90% sure we fixed this in the 2.5 beta, those fixed are going to be pushed to stable soon.

[jvrijn]

Hi guys,
I installed MA 2.5.0b18. Set up NOS Het Oog Op Morgen as an RSS Podcast feed. Used the built-in Snapcast server with a Raspberry Pi Zero 2 W with 2Mic Hat and a speaker running the Snapcast client and Pulse Audio.

Launched a podcast episode, it's 53m22s long. After a few minutes I clicked on the progress bar to forward to somewhere around 60% of the episode. Play paused and took ~45 seconds to resume at the later point in the podcast. I used a timer, but started it a few seconds late.

At this point I let the podcast play for a couple of minutes, then hit pause. I switched to another tab in my browser. After 5 to 10 minutes I came back to the tab with MA open and hit play to resume the podcast. It took about 1m10s to resume playing. I also saw some red error message boxes pop up with the text "Player ma_beubeucocbv is not available".

[OzGav]

Can you try using snap web. Go to YOUR-MA-IP:1780 and try that.

[jvrijn]

Sure, I did as you suggested and clicked the play button in the top right of the SnapWeb. This creates a SnapWeb player in MA. Again I started a podcast, let it play for a minute and clicked in the progress bar around 60%. It took 52 seconds for playing to resume. Then I thought, what if it takes so long because the audio file is not fully downloaded? So, I clicked in the progress bar around 30% and it took 26 secs to resume. Then jumped to close to the beginning and it took about 6 seconds. Then to around 50% of the progress bar and it took 45 secs again.

I let it play for a bit and paused around 60% again. Left it paused while typing the first paragraph of this response, went back and hit play. It took ~45 seconds and it started playing on the Raspberry Pi Snapcast Client! Paused again, switched the speaker to SnapWeb and hit play again. It took ~45 seconds (UPDATED, forgot to type the numbers on first submission) seconds again.

So, it seems like the further into the podcast I click or unpause, the longer it takes. Perhaps a seek operation to get to the right time? My MA runs as an add-on in HA OS on a Rpi 4B 8GB. I run it off a Samsung T7 USB drive.

[marcelveldt]

So, this all smells like the server serving the podcast doesn't support range requests so seeking will be terribly slow.
I assume you've updated to the latest stable 2.5.0 or beta 2.6.0 by now ?
We had a couple of late changes to the caching internally to prefer caching of podcasts a bit more to prevent this issue. So basically question number one I have is if you have tested tested this on 2.6 beta already ?

I will also try to load this podcast here on my testsetup to see if I can reproduce.

[jvrijn]

Hoi Marcel, I just tested on 2.6.0b1. Same issue. I used the episode 31-03-2025 this time. Started playing, skipped forward a little bit, playing resumed in a few seconds. Skipped to about halfway, it took approx 45 secs. Jumped back to close to the beginning, it took just a few seconds. Skipped forward again to about halfway, again ~45 secs. Jumped to near the end (about 95%) and it took 1m26s to resume play.

[marcelveldt]

OK, I reproduced the issue. My hunch was right and the source does not support proper range support, making fast seeking effectively impossible. I've added a bit of extra logic to cache the podcast so that seeking will work.

Please verify if its fixed in the 2.6.0b2 update.

[OzGav]

@jvrijn beta 2 has been released

[jvrijn]

Ok. Just tried it, the situation is much much improved. Jumping from the beginning of the podcast to near the end now only takes about 6 seconds. Perhaps an indication that it working on the request would be good?