Problem:
LiveTV streaming consistently freezes/stops hourly, around minute 3 of every hour. Problem is consistent, predictable, and always at the 3rd minute of every hour regardless of when the stream is started. Possible DVR scheduler involvement - see below.
Details:
From the client’s/render’s perspective, the Live TV stream abruptly stops, both active video & audio, aka froze. App is responsive, and one can ‘back’ to the Plex home screen and restart the Live TV again, however cannot pause or resume current froze stream.
From the server’s side, it looks as if the client stopped the stream.
Logs attached.
server_hung_live.log (33.2 KB) client_hung_live.log (19.6 KB)
You can see the PMS logs elude that the Shield Plex Player client app has asked to stop playback, and the session is removed and cleaned-up, like the rug has been ripped from out and from under the Player.
Notes:
I do not believe the Plex server is the problem as I can stream Live TV on other devices and never have the issue (Android/iPhone, Fire Stick, PC Plex Web browser). This also rules-out any issue with the Tuner hardware.
I suspect there is an issue with SHIELD Android TV app. Could be a one-off compatibility issue. Could be a random setting. Could be another app installed that is interfering.
Note that “other” Live TV apps, that stream directly from the tuner (Channels, HDHomeRun, LiveTV) all work fine and never stop at this 3rd minute mark.
The biggest clue in the PMS logs is : " . . . with reason Client stopped playback."
I’ve also attached the Shield Network logs, so we have a view form the server as well as the client sides.
Theories:
I have now confirmed this issue is only plaguing channels that happen to have a DVR schedule.
Is it possible that the DVR scheduled batch job runner is (lack of better words) bumping/freeing the associated tuner channel currently in use for Live TV?? Perhaps the time-shift feature of live tv is conflicting – although I am watching in real-time (not shifted).
Example, I only have two channels involved with DVR scheduled programming (10.1 & 13.1), and these are the only two channels that Live TV consistently freezes at :03 mark of every hour – and no, not actively recording the show. Remember, Live TV is simply freezing hourly on channels in the DVR line-up.
Topology:
-
Renderer -
NVidia Shield, Firmware:
Plex for Android (TV) v.7.30.0.16475
LAN IP: 192.168.1.153
-
Network OTA Tuner -
HDHomeRun EXTEND
ModelNumber:HDTC-2US
FirmwareVersion: 20200225
TunerCount: 2,
LAN IP: 192.168.1.155
-
Server -
Ubuntu Linux v.18.04.4 LTS (Bionic Beaver)
Plex Media Server v.1.18.9.2571-e106a8a91
LAN IP: 192.168.1.157
2 Likes
Server/Settings/Network:
Terminate Sessions Paused for Longer Than - change to 0
hit enter or save.
Already did that. No joy 
I too thought it was a timeout of sorts, yet I can start the live stream at anytime and it always hangs at minute 3 of every hour. It’s so predictable, I played a joke on my kid where I magically ‘paused’ the show by saying “abra-cadabra” and a wave of hand - LOL! (yeah - not funny)
Like I said above … I’m suspecting that the DVR scheduler sub-process might be executing every hour at minute 3 (not sure yet) and it “chokes” the active live stream in progress - frees the tuner channel, which pulls the stream right out from under the player.
AND, if I Live TV from a channel that has no schedules at all, I get past the 3 min mark just fine - no hanging.
Example: I have a daily 1hr program series set to record on tv channel 13.1, and another on 10.1, different time slots. However, I don’t record jack on the rest of the 60+ OTA channels. Watching Live TV hangs on just those two same channels.
Hmmmm… I think I’ll clear my entire DVR (empty recording schedule), and see if 13.1 still hangs at 03 hourly.
Thx!
Actually, that’s hilarious. Sounds like something I’d do.
Anywho… it was a shot in the dark. The bug still plagues FireTV’s.
Here I have the same issue, sometimes it can play for 2-3 hours without jamming and sometimes it will stop after 2 minutes. I have noticed that it jam around the third minute also.
I tried reseting to 0 minutes before killing, updated to the latest public version…
jpgrenier - thanks for the post.
Small update here . . .
I completely cleared all DVR schedules - aka no pending recordings of anything, but I still get the predictable freezing on every minute :03 of every hour (regardless of when I start Live TV), so that blows my DVR sub-process theory away.
I wonder now, if there could be a hard drive “clean-up” job running at every :03 which inadvertently obliterates the transcode files. Background: I’m no Plex-expert here, but it seems like the Live TV via Plex app does not connect directly to the HDHomerun tuner, and rather it connect to PMS, and PMS connects to the tuner. So PMS fetches about a second of live tv from the tuner, creates a transcoded file, and then the Plex player on my Shield requests that 1 sec file from PMS. Kind of like FILO buffer. All goes well as long as PMS is “ahead” of the Player’s requests. My new theory, is that at around the 3rd minute on the hour, Plex player goes to request the “next” transcoded file, yet it’s not there. This might explain why (from the player’s perspective) it seems like the active stream was just ripped-out from under it, resulting in a froze video.
In PMS settings on my Linux box, under “Transcoder”, item “Transcoder temporary directory”, I do have a valid path set to my large (and fast) SD-Drive. It seems PMS adds two more sub-dirs within that path “Transcode/Sessions”. When no Live TV is streaming, this dir is empty (as expected), and when a stream is playing, a serialized dir name exists, and inside are these 1-sec buffered files. The files keep collecting up as long as the stream plays - which starts eating up storage space. So once PMS has served the files to the player, the past played files should not be needed to be kept, so I’m guessing there is some sort of “clean-up” eventually?? Can any shed light on how PMS implements this?
Can you please provide a log covering when this happened, please?
Hi DaveBinM - thank you … yes, I have already uploaded logs at the moment this occurs. You can find them on my initial thread post above.
The “client” log was captured from the NVidia Shield, and the “server” log was obviously from my PMS hosted the linux box. Note, I’m not certain the literal time-stamps are 100% sync’d between the client and server sides, so allow for a little interpretation there (might be a few milliseconds off), yet both captured at the moment of failure.
1 Like
Can you attempt to reproduce this on the latest public releases of the server (1.19.1), and client (7.31)?
Absolutely . . . and I just got the new release in the other day via the Ubuntu updater pipeline, just hadn’t gotten around to testing until now. Good-news - looks like the issue is resolved ! I’ve made it twice now past the minute 3 mark this morning.
Extra info here : For this morning test, I also, on my linux box, I decided to open a terminal window, and run a simple while-loop to monitor the total file count in the transcoder’s temp Session dir for the active stream. The objective here was (if the bug were still here) to see if the files and session dir was inadvertently being obliterated every hour at minute :03. Fortunately, yet unfortunately, now that I’m unable to reproduce the issue, guess we’ll never know. I’m just past my 2nd hour of live TV now, still no issues and the files have stopped stacking up … i.e. they have leveled off at 5,405 (3.1GB) of cached files at the moment - obviously these are hanging around to support time-shifting, so it is evident the “FILO cleanup” of the oldest transcoded files are confirmed working as expected.
Edit 1 :
My client app is at 7.30.2.16712 which is not as the current as your suggested (7.31), yet it is a slight bump up since my initial issue and the issue is gone. So we can assume the fix was as of either PMS 1.19 or the Plex Player 7.30.2 on my Shield TV.
DaveBinM - Thanks for your attention on this matter.
Edit 2 : CRAP !! Spoke too soon. I came home today, and if froze up again at minute :03
Sorry, I had no logging at the time, so I’ll turn it back on and try again.
1 Like
Plex Media Server Logs_2020-04-14_13-03-27.zip (5.8 MB)
Here is my log, my client is a Shield TV running the lastest version I could get 7.30 and PMS 1.19.1
The live feed crashed between 13h02 and 13h03
Thanks!
Sorry, I’ll need both the client and server logs for this 
Oh sorry 
but it’s my first time oulling the client log, how do you do it?
Thanks
And will it shows the info we need if I do it now ?
Should give you what you need, and it’s unlikely that it’ll still have that data, so you might need a fresh reproduction
1 Like
Hi all,
So I spoke too soon … the hanging of live tv at minute 03 persists.
FWIW, I believe the issue is with the Plex Player app on the Nvidia Shield TV platform. I believe the PMS simply cleans-up the transcoded session AFTER the Player has hiccuped.
For the record, my Shield is on 1Gb Ethernet (not wifi).
I have attach a single file, which has both the Player logs and PMS logs. In addition, I attached some custom logging output of the transcoder session files at the time of the hang event.
all_logs_hang6.txt (316.3 KB)
While the server does indeed clean-up (delete) the files, I believe this is a side-affect of losing communication with the player rather than the cause.
Tip : For those struggling on how to get the Player logs from the Shield device, here’s a quick-n-dirty howto :
a) Launch the Shield Plex Player app, click on your account name icon, then Settings, the Advanced Settings, turn Network Logging On. Exit out of settings, and start your live tv stream.
b) Go to your PC, open a web browser to https://plex.tv/ to insure you are currently logged in to your online Plex account. If not, log in now.
c) Open a new browser window, browse to https://plex.tv/devices.xml
This should present raw XML output of all streaming devices that Plex detected.
Note: If the XML content is blank, either you are not logged into web plex, or the Shield’s network logging setting is not turned on correctly.
d) Looking at the raw XML output, find the URI (IP & PORT) associated with your Shield device. Hint: locate your Shield TV section and the tag “Connection uri=_____?____” which contains your local LAN ip & port to the Shield.
e) Test to see that you can pull the logs : Open a new browser window to that same URI you found in the xml, HOWEVER please add the following string to the end “/logging”. Mine was : “http://192.168.1.153:32500/logging” - your IP & port may be different. You should see a snapshot of raw text logs in the browser.
f) Let’s wait until the problem issue occurs (stream hangs) then simply hit the “Refresh” browser button to update the snapshot again (get most current logs).
g) Now select-all in the window and copy the snapshot to a text file for uploading here.
Here’s my logs
It happend between 11h02 and 11h04, I hope I have all the info you need.
I don’t know if it’s releated but it looks to be happening at the third minute of the hour when you where watching a previous show and then it ends and another show starts. because we where watchinf a morning show since 7h30 this morning and nothing happend until the show ended and the new show started at 11h00.
Plex Media Server Logs_2020-04-15_11-04-41.zip (6.2 MB) Shield TV log.txt (1.9 MB)
Thanks !
Update : Acctually you can see the firsts ERROR message appearing at 04-15 10:58:54.021. Wich is actually the end of the morning show and the beggining of the the next show.
jpgrenier - great observation !!
I’m seeing the same consistent trend in my Player logs as well. Example, it seems that once the hour ends for a particular program, the Player’s request’s to Plex Server’s “timeline” resource starts to fail, and that it takes 3 minutes roughly for this to snow-ball into the Player ending the session. So while it is the Player stopping the stream, it is PMS that is maybe causing the Player to so-called “fly blind” without these timeline metric updates from the server. Interesting …
And here’s is what it looks like on the server:
Apr 15, 2020 07:00:07.707 [0x7f032f7fe700] INFO - Time value greater than duration
Apr 15, 2020 07:00:07.707 [0x7f03709bf700] DEBUG - Completed: [192.168.1.153:59710] 400 GET /:/timeline?audioStreamID=5067&duration=180
The server is saying the client’s passed-in value is too great, so replies with a http 400 error.
This means, this still being an issue with the player is still possible - saying the player should not be sending the server an out-of-bounds value in the 1st place. The Player could be simply the catalyst of it’s own fault.
Are we on to something Plex?
smithj108 - That’s actualy a “good” news that we have the same issue 
Plex here’s another log of my last bug
Shield TV log #2.txt (1.7 MB) Plex Media Server Logs_2020-04-15_13-06-59.zip (6.2 MB)
I think I’m seeing a similar issue. We are using server Version 1.19.1.2645 on Ubuntu with a 2019 shield pro for playback, running version 7.30.2.16712. Live TV is sourced via an HDHR5 Quattro with everything connected via gig ethernet.
The problem originally showed up as a video freeze about 3 minutes into the CBS network news while watching the live broadcast. This happened several nights in a row before we realized the pattern. When the freeze happens we can return to the guide, tune another network, then tune back to the CBS programming and it may run to the end of the program without further issues, or it sometimes freezes again. (We have to tune away from CBS before returning or we will just get a blank screen.) We happen to have a scheduled DVR event for this same program so the program is being captured in parallel. We can return to the captured session later and it will play start to finish without a problem.
Time-wise, the issue seems to have appeared around the introduction of the recent program guide/in-channel program info updates, but we made other changes around the same time (Hauppauge to HDHR tuner, network topology) so I dismissed it at the time as side-effects of the other changes.
The OP mentioned that this might only occur for channels with DVR events scheduled – we have since seen it happen on other channels without any DVR events scheduled.
Due to the repeatable nature I attempted to capture a client log of the freeze, but wouldn’t you know it, it didn’t happen at all last night. (the Shield sw version has been auto-updating frequently lately, so perhaps there have been related changes having some impact?) However, we did tune to a different program after the news ended and I think I caught a log of a similar freeze during that showing. No server log though. There seem to be a lot of audio errors showing up first, then the freeze is around the 19:33 mark. I’m not sure of the exact time because I wasn’t watching the picture when it happened – I turned after realizing I hadn’t heard audio in a number of seconds.
logging1.txt (1.1 MB)
I’ll try to capture server side logs as well if we get back to a repeatable error presentation.
