PMS is for sure not reporting the correct information in /clients, btw it doesn’t always happen in my tests even with shield, but its definitely happening for more than shield (we have internal reports of the same), that might explain why you don’t see it with others, also as stated before its possible older app versions didn’t rely just on the clients endpoint (we have other clients that don’t i.e but I can’t say for sure).
There is of course always the possibility that there’s also a client issue that somehow messes with discovery but at this point its just more likely that its PMS. In any case once we have test builds with a fix I’ll keep you posted.
Would this also fix the missing data on the server’s /status/sessions and the player’s /player/timeline/poll endpoints?
Well my hope is that they are related yes but that still not 100% confirmed.
1 Like
I was hopeful the new 8.3.0 release of the AndroidTV client would fix this problem based on the release notes:
- Player: update server view state when being controlled via Companion.
Unfortunately the problem still persists in my testing. I have version 8.3.0.18912 (14279def).
I see these possibly related messages in the client logs:
07-06 12:42:44.069 i: [PlaybackTimeBehaviour] Time: 8727 IsStarted: true
07-06 12:42:44.071 i: [Now Playing] Server does not support timelines, ignoring
07-06 12:42:54.072 i: [PlaybackTimeBehaviour] Time: 18731 IsStarted: true
07-06 12:42:54.074 i: [Now Playing] Server does not support timelines, ignoring
07-06 12:43:04.076 i: [PlaybackTimeBehaviour] Time: 28735 IsStarted: true
07-06 12:43:04.078 i: [Now Playing] Server does not support timelines, ignoring
07-06 12:43:12.104 i: [PlaybackTimeBehaviour] Time: 36762 IsStarted: true
07-06 12:43:12.106 i: [Now Playing] Server does not support timelines, ignoring
@mikec_pt is there anything else I can provide?
Can you check what you see in the /clients/ endpoint in PMS, is it empty? I was under the impression this was a PMS bug that I think we fixed (need to confirm).
Which PMS version are you running? This this still happen with 1.19.5?
Yes, both /clients and /status/sessions are empty on PMS when media is actively playing on the Shield client. Nothing shows up under “Now Playing” on the Plex Web dashboard.
I’m on 1.19.5.3035.
I just tried to repo it using PMS 1.19.5 and 8.3.0 on androidTV and I can’t repo this (at one point I could repo some issues with the /clients response).
If you have multiple server please note that the the app you’re using to “cast” might query a different server to get /clients. Usually its the first available but that might not be exact.
status/sessions however should always be seen on the server that’s playing the content!
That said, can you please also post what are you using as the controller? And which platforms for both that and the server.
I have one server running 1.19.5.3035.
This only occurs when using the Plex Companion feature to start playback on the Shield from another device. It will play just fine, but PMS will not show the activity in /status/sessions or in the dashboard when playback is started in this manner.
I’ve been able to reproduce this using the latest iOS Plex client to initiate playback on the Shield.
Hum, and not on a browser? (Firefox/Safari i.e.?)
In that case this might be a bug in the iOS app, however its very suspicious that the server /clients endpoint is empty.
EDIT: actually no its not, because on iOS this works a bit different and we don’t need to rely on that (I was just confirming this).
In this case this is either a bug in iOS or the AndroidTV app (I need to confirm which should be updating the info)
In the mean time can you please post full iOS/androidTV and PMS logs? that might help track it. We will also try to repo this in a similar environment.
Haven’t had much time to test, sorry. For some reason, the Shield is only available as a playback destination on the iOS client and not in Plex Web or the Mac desktop app or I’d test there, too. I’ve confirmed it’s available in the plex.tv /resources endpoint, so I’m not sure why it’s not a playback destination option.
The behavior remains when playing back from the iOS client. I do see these entries in the Shield log when casting from the iOS client:
07-24 21:49:16.967 i: Time out fetching http://10.0.200.166:32500/:/timeline.
07-24 21:49:16.968 i: Fetching [method:POST] http://10.0.200.166:32500/:/timeline?includeExternalMedia=1
07-24 21:49:17.985 i: Time out fetching http://10.0.200.166:32500/:/timeline.
07-24 21:49:17.986 i: Fetching [method:POST] http://10.0.200.166:32500/:/timeline?includeExternalMedia=1
07-24 21:49:20.937 i: Time out fetching http://10.0.200.166:32500/:/timeline.
07-24 21:49:20.938 i: Fetching [method:POST] http://10.0.200.166:32500/:/timeline?includeExternalMedia=1
07-24 21:49:37.061 i: Time out fetching http://10.0.200.166:32500/:/timeline.
07-24 21:49:37.062 i: Fetching [method:POST] http://10.0.200.166:32500/:/timeline?includeExternalMedia=1
07-24 21:49:38.083 i: Time out fetching http://10.0.200.166:32500/:/timeline.
07-24 21:49:38.084 i: Fetching [method:POST] http://10.0.200.166:32500/:/timeline?includeExternalMedia=1
And when controlling via the companion API directly:
07-24 21:52:28.889 i: [Now Playing] Server does not support timelines, ignoring
07-24 21:52:38.891 i: [Now Playing] Server does not support timelines, ignoring
07-24 21:52:48.385 i: [Now Playing] Server does not support timelines, ignoring
In the iOS case, I’m sure there’s a firewall restriction which is preventing outbound connections from the Shield to the iOS device. I can see if I can remove this for testing later. Is it the iOS client’s responsibility to report status back to the PMS instance?
For the custom companion API client, it does not subscribe to timeline callbacks which seems to match the log messages. I would still expect active sessions to be reported to PMS by the Shield, however.
If I roll back to an older Android TV Plex client, it reports all playback sessions started from anywhere back to PMS itself without issue.
The fact that it doesn’t show in the web app is for sure odd!
It should show up in Firefox for casting to the Plex App (Companion API) and in chrome, it should also show as a Chromecast device since that is built-in (if not even that is working then there’s likely a network issue at play)
The web app does rely on PMS for the companion API, it will query a server for “/clients” endpoint; if you’re familiar in the “web console” you should see that request, you can the investigate the response and see if it is showing the shield as a player, if not then that could possibly still be a PMS issue.
I’ve asked some help to try and check things on iOS side again as I don’t have a device.
When using Chrome and Plex Web, the Shield shows up as a Chromecast destination but the Plex Companion player does not. Neither Firefox nor Safari show either player as a cast option. Both options show up on the iOS app, however.
I see an entry like this in the web console, but not an explicit list of available resources:
[Servers] Found 10 resources through plex.tv
I haven’t seen the Shield show up in /clients since I opened this issue.
Do you know the requirements for a player to register with PMS (and show up in /clients)? I assume it’s responding to a GDM UDP broadcast from the PMS on port 32412. Does the Shield perhaps work differently?
I’m not sure if its just GDM for PMS to populate that but I will inquire, we couldn’t repo this on iOS in new tests, and iOS doesn’t rely on that so there might be something in the network blocking network discovery? Do you have a firewall that might be blocking it?
If so this article might help figure what might be blocked
You can start with the GDM ports and see if those are blocked which would explain the empty clients endpoint.
PMS and the Shield are on different subnets, but there is a UDP repeater on ports 32410-32414 between them. My question was if the Shield behaved differently for GDM compared to other clients as other clients on the same subnet seem to be responding yet the Shield does not.
The fact that it’s missing from /clients is annoying, but the playback sessions not appearing in /status/sessions is the main reason I raised this issue.
I’ll take some network captures to confirm if GDM is in fact getting through or not, but I assume that should not be a requirement for playback status reporting to work.
Alright, some minor progress after digging through some packet captures. Turns out the return path back to PMS for GDM packets was working for all the other clients in this subnet because of a mistyped mask. The Shield now shows up reliably under the /clients endpoint on PMS after fixing that rule. My sincere apologies for not catching that much earlier. I had looked at these rules dozens of times and missed it every time.
I’m now able to test by using the Plex Web companion player. When starting playback from Plex Web the session is reported properly under the /status/sessions PMS endpoint. However, it does not show up on the Plex Web dashboard for some reason.
Starting playback using the iOS app plays the media fine, but does not show anything under /status/sessions and also nothing in the Plex Web dashboard. Same when using the companion API directly.
Since it seems networking may be a factor here, the Shield and the iOS device are on different networks. I’m going to dig around a bit and see if that makes a difference.
…and it looks like it does matter. I found some log entries like this in the Shield logs:
Time out fetching http://10.0.200.166:32500/:/timeline
Which was the IP of the iOS device. I allowed outgoing connections to the iOS player from the Shield and status reporting started working (both /status/sessions and Plex Web dashboard):
08-02 22:24:10.260 i: [pms] /10.0.200.166:50640 - GET /player/timeline/subscribe
08-02 22:24:10.261 i: Fetching [method:POST] http://10.0.200.166:32500/:/timeline?includeExternalMedia=1
08-02 22:24:10.311 i: Fetching [method:POST] http://10.0.200.166:32500/:/timeline?includeExternalMedia=1
08-02 22:24:10.506 i: Fetching [method:GET] https://10.0.10.80:32400/:/timeline?.....
The status reporting only worked if the two clients can both reach each other directly on the network. It looks like the Shield only started hitting the PMS timeline endpoint (last line in logs above) once it was able to POST timeline updates to the controlling iOS device. When I use the companion API directly I do not set up a timeline callback subscription.
I’m guessing this worked fine with the Plex Web case as the timeline connections were proxied through PMS (and were allowed through the standard http://<PMS_IP>:32400 rule).
Or am I misunderstanding things and is the controlling companion device responsible for reporting playback status from the actual playing player back to PMS (even if it’s playing from that PMS)?
I ran across this when setting up automations with Home Assistant. When I trigger playback using Home Assistant, it will start the video playing on the ShieldTV Plex client, but not actually show the video playing on the Plex server (though you can see the bandwidth usage increase and the transcoder working).
@lizaoreo That’s actually what this issue spawned from.
@jjlawren @mikec_pt Any updates on this?
Sorry I was actually under the impression this was due to network setup and was solved, but reading back…
When I use the companion API directly I do not set up a timeline callback subscription
Can you clarify this? Are you using a script for that or are we still talking about using a Plex Client?
Btw if you have multiple subnets don’t forget to add them to “LAN Networks” in Sever Settings → Network (this is unrelated to the issue but they might be seen as external connections and bandwidth limits might be applied)
I can’t really say much about Home Assistant, It totally depends on what its doing and how its using the API but I can say this:
Companion is a bit complex and not all clients act the same, some depend on GDM for discovery, but others don’t, the ones that don’t will usually try to use the PMS /clients endpoint to find about available “players” (This is i.e. the case of the Web App with say Firefox) and in the same way, timelines are also reported differently as @jjlawren confirms above while explaining the iOS vs Browser case.
The one thing that seems odd @jjlawren is that from what I was told in the iOS case, the player will report back to the server and controller, but the controller doesn’t need to report anything back to the player or server unless I misread what you were trying to say the shield should be able to report back to PMS, and when players can’t report back directly to the controller (like browsers) PMS acts as a proxy for that (or should).
With that said, can you guys share a bit more info on how home assistant is automating this? Depending on how that works, we might be able to find what’s happening.
In any case if the player can talk back to the server it should at least do that, the reporting to the controller part is where it might be direct or indirect (via PMS) but it should at least report a playback session … if not then perhaps something is wrong on the android (shield) side.
