I had noticed a couple of things when accessing via plex.tv but now it is broken on my local web server.
The main thing is that it now stops after every episode when casting from the web interface. At the end of an episode the 15 second countdown breafly shows then resets to the season cover. Definitely a bug.
The other thing that has changed that is an inconvenience is that the season label at the top used to be a dropdown you could use to select the next season, now it is just a label so you have to click on the series name then click on the correct season. It would be very nice if the removed functionality could be restored.
Previous the the latest update where the web interface was updated, for localhost it played 3 episodes at a time with a 15 second timer between each then display the splash screen of the next episode. There are feature requests that this number should be configurable.
The timer worked before the update regardless of other discusions on how many episodes should play.
Now the timer displays for almost a second and then the screen is bounced to the season splash screen.
This is clearly broken.
Thanks for the heads up on the season fropdown location.
Oh, the whole light blue border around yellow buttons for selected default is really jarring. A nice green for selection would be much nicer. But I digress from the original bug.
I am happy to act as a beta tester for interface changes to the plex web interface. It is clear that not enough of the community use it via plex.tv to cast to Chromecast rather than localhost or this would have been picked up sooner. Admittedly I had seen it in that interface but not reported it as I assumed it would not be shipped to plex server until resolved.
The other broken thing is if you choose to play a partially played episode it asks if you want to play from last viewed time or start from the beginning.
It plays from last time regardless of selection and you have to manually click the progress to take it to the beginning if that was your selection.
I think this has been broken for a while though and I just forgot to report it.
It’s the web interface it does not matter what it is running on but I already said it was Chrome on Windows on the local PC.
ChomeCast is the latest Non 4k model. round thing plugged into telly.
It worked before the localhost web server was updated with the changes that were already in the plex.tv web interface.
I am now trying to work round this show stopper of a failure by using the mobile app on may old Note 8. Latest Plex version but insteas of stopping, or progressing to the 4th episode in the queue it just replays the 3rd played episode continuously.
Some behaviour standardisation across your clients would be nice.
Is there a controller/client combination that actually works just now? I have windows boxes, Android devices and a Chromecast.
If you can get me the logs from PMS and from the Android app after the failure of the 4th episode (or loop of the 3rd episode), I can take a look. Just let me know which video failed/looped.
So, just to confirm, casting from plex web in chrome browser in windows, to chromecast:
On play of an episode, at end of episode counts down 15 seconds and plays the next episode for you?
I will clear all caches yet again and test this tomorrow and send logs from either side of the failure.
The Android issue has not re-arisen so may have been a glitch from first use in a while but I have also switched phone since then to an alternate backup.
Yes, that works for me. I tested repeatedly jumping to the end of the episode to get to the next one to go through 5 episodes and that also worked for me. The problem you see could be specific to the CC device itself or maybe naturally playing is needed. I haven’t had time to try letting it play naturally. It could be the post-play’s 2 hour limit coming into play. If there is no interaction within 2 hours, the count down should not work and you would have to manually hit play to continue. Could be the bug is around those actions at the 2 hr point.
This is the log entry from the end of an episode. Definitely not the 2 hour thing as it happens after the first episode ~45m
Nov 08, 2020 16:37:09.934 [13600] DEBUG - Auth: authenticated user 1 as Bodestone
Nov 08, 2020 16:37:09.934 [9000] DEBUG - Request: [192.168.0.11:44357 (Subnet)] POST /log (19 live) TLS GZIP Signed-in Token (Bodestone)
Nov 08, 2020 16:37:09.934 [13536] DEBUG - Completed: [192.168.0.11:44357] 200 POST /log (19 live) TLS GZIP 0ms 274 bytes (pipelined: 44)
Nov 08, 2020 16:37:09.962 [13536] DEBUG - Auth: authenticated user 1 as Bodestone
Nov 08, 2020 16:37:09.962 [9000] DEBUG - Request: [192.168.0.11:44357 (Subnet)] GET /:/timeline?ratingKey=38187&key=%2Flibrary%2Fmetadata%2F38187&playbackTime=2319510&playQueueItemID=181918&state=playing&hasMDE=1&time=2330000&duration=2580000 (19 live) TLS GZIP Signed-in Token (Bodestone)
Nov 08, 2020 16:37:09.963 [9000] DEBUG - Client [sxtwej0c8vpi30ha4ieqgvma] reporting timeline state playing, progress of 2330000/2580000ms for guid=, playbackTime=2319510ms ratingKey=38187 url=, key=/library/metadata/38187, containerKey=, metadataId=38187, source=
Nov 08, 2020 16:37:09.971 [9000] DEBUG - Library item 38187 ‘Homecoming’ got played by account 1!
Nov 08, 2020 16:37:09.973 [13600] DEBUG - Auth: authenticated user 1 as Bodestone
Nov 08, 2020 16:37:09.973 [11124] DEBUG - Request: [192.168.0.11:44359 (Subnet)] POST /log (19 live) TLS GZIP Signed-in Token (Bodestone)
Nov 08, 2020 16:37:09.973 [11124] WARN - [Chromecast] Did not move header “accept” to query string. This can result in an unnecessary OPTIONS preflight request.
Nov 08, 2020 16:37:09.973 [13536] DEBUG - Completed: [192.168.0.11:44359] 200 POST /log (19 live) TLS GZIP 0ms 274 bytes (pipelined: 9)
Nov 08, 2020 16:37:09.981 [9000] DEBUG - [Now] User is Bodestone (ID: 1)
Nov 08, 2020 16:37:09.982 [9000] DEBUG - [Now] Device is Chromecast (Chromecast).
Nov 08, 2020 16:37:09.982 [9000] DEBUG - [Now] Profile is Chromecast
Nov 08, 2020 16:37:09.982 [9000] DEBUG - [Now] Updated play state for /library/metadata/38187.
Nov 08, 2020 16:37:09.982 [9000] DEBUG - Statistics: (nr6opfk1nqiozwv7wndiesi2) Reporting active playback in state 0 of type 4 (scrobble: 1) for account 1
Nov 08, 2020 16:37:09.984 [13600] DEBUG - Completed: [192.168.0.11:44357] 200 GET /:/timeline?ratingKey=38187&key=%2Flibrary%2Fmetadata%2F38187&playbackTime=2319510&playQueueItemID=181918&state=playing&hasMDE=1&time=2330000&duration=2580000 (19 live) TLS GZIP 21ms 833 bytes (pipelined: 45)
Nov 08, 2020 16:37:10.024 [9000] DEBUG - [Transcode] Transcoder segment range: 0 - 525 (525)
Nov 08, 2020 16:37:10.107 [13600] DEBUG - Completed: [127.0.0.1:59974] 200 GET /player/proxy/poll?deviceClass=pc&protocolVersion=3&protocolCapabilities=timeline%2Cplayback%2Cnavigation%2Cmirror%2Cplayqueues&timeout=1 (20 live) GZIP 20013ms 5 bytes (pipelined: 155)
Nov 08, 2020 16:37:10.125 [13600] DEBUG - Auth: authenticated user 1 as Bodestone
Nov 08, 2020 16:37:10.125 [9000] DEBUG - Request: [127.0.0.1:59974 (Loopback)] GET /player/proxy/poll?deviceClass=pc&protocolVersion=3&protocolCapabilities=timeline%2Cplayback%2Cnavigation%2Cmirror%2Cplayqueues&timeout=1 (20 live) GZIP Signed-in Token (Bodestone)
Nov 08, 2020 16:37:10.125 [9000] DEBUG - Content-Length is -1 (of total: -1).
Doesn’t seem to be anything obvious. The 'did not move header line crops up in the console while playing so isn’t directly related to the end event.
This is the behaviour: https://www.dropbox.com/s/ksv5b3hi7rylotp/PlexGlitch.mp4
It was doing this on various PCs when using plex.tv rather than localhost as that already had the UI updates. This was always using the Chrome browser.
I noticed when I got back to the PC from the telly that the controls container and tab name were flickering back and forth.
I’m going to try in Edge now that is Chromium based… No I’m not, it doesn’t support casting.
The rest of the log also says nothing useful. Another person was also wathcing at the time and I didn’t want to mess about replacing IP addresses. Scanning all of the log events from my username where that episode was mentioned there were no additional error events.
I’ll have to watch again from browser, let it run to conclusion then do multiple search and replaces on the log to remove identifiable info to keep family members safe. I can, alternatively, find the first few blocks for me connecting to an episode and the last few blocks from when an episode ends but I do not believe an error will be logged. I think this is an HTML, javascript or CSS glitch in the web page rather than a server error.
The console shows nothing when starting to cast either aside from that one ‘[Chromecast] Did not move header’ entry.
I will look at providing additional log information though.
.