Right, so that semi confirms my theory that the app is having trouble reconnecting to your server after a network switch (which explains why I can’t repro the issue). Hopefully there will be a hint in your logs!
I’m not sure if I understand correctly, but I’m able to cast to my cromecast devices from Plex web and even from Goggle Play Music on my mobile. So technically speaking chromecast should be able to access Plex server (at least when initiated from Plex web). If needed I can provide some logs.
Yeah, I guess we will need to logs to see exactly why that error is showing. The crash was occurring because there was an error with that dialog from the screenshot.
I did DM the logs
The odd thing with this then, is that artwork for all the tracks loads fine, and I can browse the server content with no issue. I’m going to investigate both client and server logs as well to see if I can pin it down.
This is getting out of hand, now there’s two of them!
With the latest Beta, the sweet fades stops working after about 3 songs into a playlist. This was the same in the two previous Beta versions.
One button inline control is working as intended now in fullscreen player. HOWEVER, previous song is still not working outside of the fullscreen player. It still gets handled like a double press followed by a single press.
Update: Double press cant go from last to first song in queue (with Repeat all) outside the fullscreen player.
i get some jittery choppy or more like pops during playback primarily at the begining of a track. Almost as if there is cache issues but my files are only m4a and are 320kbit, any of this normal at the moment? i never had this occur before.
When playing FLACs on either WiFi or 4G it often stops playing after two tracks (I’m assuming the currently played song and the next buffered song). It then resumes when I wake and unlock the phone, rinse and repeat.
I’m not sure if this is a Plex issue or a an Android/device issue. I’m using a Sony Xperia XZ1 Compact with Android Pie and I have all battery saving trickery turned off. It doesn’t seem to happen if the device stays unlocked while playing, but I haven’t thoroughly tested that.
I haven’t tested it with different formats since my library is 100% FLAC. Please let me know if I need to provide some logs 
Same here with mp3s. i think its a problem with the server (when the hdd goes to sleep), but i’m not sure…
This has to be either server-related or device-specific. Admittedly, I’m not on Pie yet (still Oreo), but I have never seen this with FLAC playing from either of my own servers. Logs might be the easiest way to pin it down, even if it’s not directly related to the player beta.
my playback also stops after a few tracks …
I tested this now and you’re right. I’m putting a list together of all of what I found that is broken:
From most important to least (in my opinion)
- Synced content doesn’t seem to be working at all, on either Cellular or Wifi. No matter what, the content is always pulled from the server and not local storage. (This could destory someone’s monthly datacap)
- Voice search in Android Auto is broken. When using voice search to request to play an album, 99% of the time, a podcast will be returned. (Distracted driving)
- Options button to shuffle tracks randomly hides itself on Android Auto on the head unit of the car (not Android Auto on phone)
- Sweet fades work for the first track or two, and then stops working.
- Seeking through a track before it loads doesn’t work. After it fully loads, it will work as it should.
- Bitrate is no longer shown when looking at song info.
This “information” is no good to us without logs or steps to reproduce.
We are quite obviously trying to resolve bugs. We would love it if you can help by giving data points.
“It’s not working” isn’t (useful) a data point 
Logs would be appreciated with rough time of when you turned the screen off + when the audio stopped. If you are able to test from a different server/TIDAL that might also help us determine if it’s server or client related 
- Synced content doesn’t seem to be working at all, on either Cellular or Wifi. No matter what, the content is always pulled from the server and not local storage. (This could destory someone’s monthly datacap)
Fix in progress.
- Voice search in Android Auto is broken. When using voice search to request to play an album, 99% of the time, a podcast will be returned. (Distracted driving)
We have made some optimizations to the search routine which prefer the selected source which should prevent this from occurring, that fix might not be available until version 7.10 of the app.
- Options button to shuffle tracks randomly hides itself on Android Auto on the head unit of the car (not Android Auto on phone)
Is it possible the shuffle button hiding is coinciding with this: Beta for the new Audio Player on the Android mobile - #26 by marcjt (shuffle is not available when playback is started from the play button at top of the album, by design)?
- Sweet fades work for the first track or two, and then stops working.
I’ve seen a number of reports of this, I’ll check in on the status. Is this occurring with every track, or just FLAC, or just TIDAL etc.?
- Seeking through a track before it loads doesn’t work. After it fully loads, it will work as it should.
We have an open bug report for that.
- Bitrate is no longer shown when looking at song info.
Fixed, should be in the next beta of 7.9
Thanks for the list!
Is it possible the shuffle button hiding is coinciding with this: Beta for the new Audio Player on the Android mobile (shuffle is not available when playback is started from the play button at top of the album, by design)?
I’m not sure, but I can get a video later today of the head unit in my car showing the error. Everyone’s head unit UI might be slightly different.
I’ve seen a number of reports of this, I’ll check in on the status. Is this occurring with every track, or just FLAC, or just TIDAL etc.?
Looks to be every track no matter the codec, no Tidal subscription here, just testing local server content.
Curious to find out if it ends up being a server issue!
Can you please provide logs + timestamps of when the sweet fade doesn’t occur so we can investigate? Thanks!