Plexamp Chromecast stutter/restarting

[jdloudon]

I am running Plex on a WD PR4100 server and its been working fine for years until I had to install Plexamp as the standard Plex app would no longer play music.
Casting to a Cambridge MXN10. My system is all wired on a good network, so its not a wireless issue. The MXN10 is fine with other things casting to it such as BBC player and Spotify. It just seems to be a Plexamp issue. Tried casting from Android phone and iPad. Same thing happens.
I have also tried to cast to my Panasonic TV with its cheap Chromecast dongle, and that works fine. So its an issue with the Cambridge device?
Another user said that Cambridge Audio on their web site mentions a similar problem with Qobuz app and hints it has to do with an upgrade to Cast 2.0. I cannot comment on that.

Further research indicates that many people find that Plex is fine for video but not for audio, which is odd.
Anyway I have gone into my Plex server settings and enabled DLNA. Now I can use the Stream Magic app or Mconnect to see my server library and play from it and it works properly. Plexamp.is a nice looking player and Id like to use it, but for me and several others it is broken.

[elan]

I think unfortunately it’s a chromecast issue with certain devices/cast versions. We don’t have a workaround at the moment.

[tgp-2]

@jdloudon i tried casting from plexamp to the mxn10 some months ago … i no longer have this device, but i think it played aac and maybe mp3 files without issue

with everything else (flac, etc), the plex server tried to transcode, but the bitrate sent to the mxn10 was really high and playback failed/stuttered after a few seconds … is this similar to the issue you’re still seeing today with the mxn10 when casting from plexamp ?

[tingdahl]

I have this issue as well. What bugs me is that the mxn10 works well with other chromecast sources (spotify, bbc and others). The only one that does not work is plex. The same plex installation streams the same music fine to other chromecast targets. I have the problem across NAS, Windows and Linux installations of plex.

I’m willing to participate in debugging, analyzing logs and testing out.

After browsing the logs, the I searched for “GET /music”. I then see one large difference between the Chromecast session that does not work and the ones (on another device) that do work:

Not working:

Aug 09, 2025 11:13:32.812 [130210881870648] DEBUG - Request: [192.168.178.157:34338 (Subnet)] GET /music/:/transcode/universal/start?hasMDE=1&path=%2Flibrary%2Fmetadata%2F2642&mediaIndex=0&partIndex=0&directStreamAudio=1&mediaBufferSize=2048&session=cjq5op1dnkdzomt5cxketpvr&protocol=http&directPlay=0&offset=0&copyts=1 (7 live) #c080f Signed-in Token (krist17) (range: bytes=14876672-)
Aug 09, 2025 11:13:33.725 [130211053013816] DEBUG - Completed after connection close: [192.168.178.157:34338] 200 GET /music/:/transcode/universal/start?hasMDE=1&path=%2Flibrary%2Fmetadata%2F2642&mediaIndex=0&partIndex=0&directStreamAudio=1&mediaBufferSize=2048&session=cjq5op1dnkdzomt5cxketpvr&protocol=http&directPlay=0&offset=0&copyts=1 (9 live) #c080f 913ms 14782632 bytes (range: bytes=14876672-)

Working:

Aug 09, 2025 11:16:23.082 [130210877651768] DEBUG - Request: [192.168.178.45:56049 (Subnet)] GET /music/:/transcode/universal/decision?hasMDE=1&path=%2Flibrary%2Fmetadata%2F2644&mediaIndex=0&partIndex=0&directStreamAudio=1&mediaBufferSize=2048&session=g8k2zu6qd96otr9x7rhwgekl&protocol=http&directPlay=1&offset=0&copyts=1 (7 live) #c19e9 GZIP Signed-in Token (krist17)
Aug 09, 2025 11:16:23.091 [130211053013816] DEBUG - Completed: [192.168.178.45:56049] 200 GET /music/:/transcode/universal/decision?hasMDE=1&path=%2Flibrary%2Fmetadata%2F2644&mediaIndex=0&partIndex=0&directStreamAudio=1&mediaBufferSize=2048&session=g8k2zu6qd96otr9x7rhwgekl&protocol=http&directPlay=1&offset=0&copyts=1 (7 live) #c19e9 GZIP 9ms 1473 bytes (pipelined: 2)

Hence, all GET /music requests are completed with “Connection close”.

Any clues how to dig further?

[tgp-2]

can you confirm if the playback behavior when casting from plexamp to the mxn10 is same as what i described above ?

are you playing flac files ? and does playback work as expected with any other formats (aac, mp3, etc ?)

for a track where playback stutters/fails, you might look at the plex dashboard (either on the web or using the plex dash app) for more info … example below, i get this when casting to a wiim ultra (another cast 2.0 device, but this one seems to behave a little better vs the mxn10) … and when i look at the dashboard graphs for this, network transfer is ~ 10Mbps and lasts on the order of ~ 10 seconds … is the transcoded bitrate much higher with the mxn10 ?

server logs might show more on what the mxn10 is requesting and how exactly the server ends up transcoding

[tingdahl]

So, I have the problem with all types of files: FLAC, m4a, mp3. When playing on my other chromecast players, it does not transcode at all, it just play directly.

When playing on other devices, I get the dashboard playing the sound. When playing with chromecast on the MXN10, it does not show up in the dashboard.

[tgp-2]

thanks for the additional info … the m4a files, are these alac or aac codec ? (i’m sure the mxn10 worked with aac files when i tried it, but with alac i think it tried to transcode)

interesting that the mxn10 doesn’t show on the dashboard (not sure what that means exactly)

transcode job from the server logs would still be interesting to see, but overall it sounds like the mxn10, when casting from plexamp, is still having problems … seems like some cast 2.0 devices (like the wiim ultra) are behaving a bit better

[tingdahl]

Thanks for your answer. The m4a were an aac, but problems are the same with alac. So, it works if I convert files to Opus. When I play MP3 it does not. The two logs are from the moment I press ‘cast’ in plexamp. the .157 on the network is the mxn10.

opusplay.log (140.2 KB)

mp3play.log (161.5 KB)

[jdloudon]

I tried MP3. FLAC, and neither worked. Its an issue with updated version of Chromecast I believe. I have ditched the Plexamp app for now and use another app to play to my Camridge device.

[tgp-2]

interesting … existing opus files play, server-transcoded opus does not … maybe the mxn10 doesn’t like the higher bitrate (512kbps) from the server