33% Spinner of Doom

Live TV & DVR
,
1

Server Version#: Version 1.24.4.5081
Player Version#: Latest Roku
Tuner Make/Model: WinTV-quadHD
Guide/Lineup name: NA
Using XMLTV?: Yes
Channel number/Name: Various

We’re experiencing frequent 33% spinner of doom status on our Roku players. Between two units on a typical Saturday (college) and Sunday (NFL) it will occur once per hour.

I’ve tried different toggles, such as force direct stream, and lowering the stream width to 3Mb/s, nothing seems to affect this.

The units will essentially time out. What’s frustrating is that hitting Back on the Roku controller and reselecting the channel will go straight to the 33% spinner of doom. That is, it doesn’t even attempt to re-stream/buffer.

What’s doubly-frustating is that Plex doesn’t say what’s happening, or provide any sort of feedback and what it’s doing. It simply stops streaming and sits there with the 33% spinner of doom.

Any guidance/suggestions would be greatly appreciated.

2

Suggest roku logs + debug server logs when this happens

For roku logs See Roku Logs | Plex Support

As roku logs may contain some tokens - please copy to text file, zip and send by private message

please indicate time of the 33% issue when providing the server and roku logs

1 Like
3

Awesome thank you so much for your attention to this matter @sa2000. I’ll be on the lookout next weekend while we’re watching some games. Yesterday actually worked well through ~4 hours of watch time with the loading screen showing once but recovering. Maybe it was just waiting for me to complain about it before it started working as expected. :stuck_out_tongue:

4

I’ll try to get a roku device again to test again to try to get logs too @Mike-E .
I can say that this definitely did happen for me when housesitting for friends sometimes more periodically and other time wouldnt see it for 6-7+ hours

1 Like
5

Awesome, thank you for any additional assistance/efforts you can provide in help tracking this down, @alienbiker99!

6

Hits away! We have had 3 instances of this sucker already this afternoon, with two of them occurring right after the other on both devices. Logs captured and sent your way @sa2000. Thank you again for any assistance. :pray:

7

Peeking at the logs, looks like it might be this puppy:

ERROR (PlaybackMgr) Failed to play media! errorCode: -3 errorMsg: An unexpected problem (but not server timeout or HTTP error) has been detected. errorInfo: {roAssociativeArray}
8

I get my Live TV streams timing out frequently at the 33% spinner also. Completely random. Been happening since I started using the Roku about one year ago. Also getting 10+ server crashes per day on my Live TV server using the newest Plex Preview.

1 Like
9

Completely random indeed, @kegbeach. After the errors I encountered right out of the gate last Saturday, it worked well for the remaining day and through all of Sunday. :man_shrugging:

10

Thank you for all the diagnostic logs from the two roku’s and the Plex Media Server

I have tied the playback errors and 33% buffering to crashes of the Plex Transcoder

I each case the failure was a crash of the transcoder

These were the last 3 crashes that you had during streaming

Primary Roku 192.168.1.184
channel I17.1.31707.zap2it.com
Transcoder crashed at Oct 23, 2021 12:42
and same channel again at 12:54
(after about 500-600 seconds streaming)

Secondary Roku 192.168.1.165
Channel I41.1.34524.zap2it.com
Transcoder crashed at 12:53
After about 1490 seconds streaming

Interesting that both transcoder jobs crashed round same time - don’t know if this is indicative of some tuner streamed data issue

These crashes can be seen in the server logs on these log lines

Oct 23, 2021 12:41:49.654 [3140] DEBUG - Jobs: 'C:\Program Files (x86)\Plex\Plex Media Server\Plex Transcoder.exe' exit code for process 12192 is -1073741819 ()

Oct 23, 2021 12:53:10.931 [12556] DEBUG - Jobs: 'C:\Program Files (x86)\Plex\Plex Media Server\Plex Transcoder.exe' exit code for process 10704 is -1073741819 ()

Oct 23, 2021 12:54:10.005 [12556] DEBUG - Jobs: 'C:\Program Files (x86)\Plex\Plex Media Server\Plex Transcoder.exe' exit code for process 12320 is -1073741819 ()

The Exit Code of -1073741819 which is hex 0xc0000005 is the windows error identifier - the common windows Access Violation error for application crashes

There were no unique errors preceding these crashes - the logged transcoder errors and warning were logged at other times as well

For transcoder crashes media files / stream captures are normally needed to debug the problem and attempting to recreate the crash using supplied samples.

For live TV this is not easy as you know
You would need to be capturing the stream from the channel and streaming at the same time and stop the capture after the error / transcoder crash - so it means it needs to be predictable

It may be possible to pick up the transcoder buffer files before they get purged - that would be an easier option if you can do it before they are purged

Your path for all transcode jobs is here
C:\.processing\Transcode\Sessions
So it would be making a copy of the Sessions directory when you notice a persisting 33% buffering message on the roku and if you are also quick checking that it is to do with this just been logged in the Plex Media Server.log
is -1073741819

So if you can manage that - zip the copy of the Sessions folder and the logs and upload and send me a link for next failure

11

Thank you for your time and effort looking into this, @sa2000. It is appreciated.

I followed everything you wrote with the exception of this statement:

When we are watching live TV I am under the impression we are streaming the channel from the server to the Roku client, so this satisfies your requirement, correct?

I will see if I can get a copy of that Sessions folder for you. Do you know how much time there usually is? The server is in a different room from where I access it (via RDP) so I have to run between them to get to it quickly. That stated I already have that sucker opened in Windows Explorer so it should be a quick copy/paste once I am able to see it.

Glad to hear you were able to track this down. Nice work over there. :+1:

12

Well - if the Session subdirectories still have the stream data when you copy them out then yes. I was thinking of curl capture in parallel - but that is tedious. Lets wait and see if the Sessions directories still have the streaming segments

13

Like the rest of this isn’t? :sweat_smile::sob: There should be a muchhhhhhhh better way to get you the requested materials and this is borderline if not full tilt arcane. Seems like there should be a big fat Capture button in the Diagnostics/Troubleshooting panel in the server to help assist with scenarios such as these.

Anyways, today is college game day. Let’s see if we have any luck here. :crossed_fingers:

14

Goodness, it took over 6 hours but it finally crashed with a 33%… the server seems to have crashed along with it this time but no crash dumps, despite having modified the system registry. 13GB Zip inbound. :stuck_out_tongue:

15

Thank you for all the diagnostics - this was different

Any server crash or transcoder crash would result in same initial failure symptom on the client app

The server did crash and appears to be related to logging info for the deletion of “Czar of the Underworld” at 17:57 on the 13th November

I will refer the crash to the server development team

I see you have had a number of recent crashes
Could you locate the %TEMP% directory for the windows user account the Plex Media Server process runs in and look for these files

e54e6f5f-58e7-430e-8a83-35b1b17300ac
68507527-5610-44f3-a0ad-57e99d14e53b
e7695350-08be-4f73-ae84-7e30bad1ab3d
da0ceb4a-dff1-4fcb-85bf-5388dd15150c

They may have a .dmp file extension

Also could you download the database and send me the zip privately - i want to see if there is anything specific with the item we were deleting

Thanks

16

Appears to have been a double delete request from the roku on 192.168.1.184 to delete this after it was watched

***********************\The Adventures of Superman\Season 01\The Adventures of Superman - S01E22 - Czar of the Underworld.mp4"

What version of the Plex for Roku app was running on this roku ?

17

Are you saying that this leads to 33% messages? To be sure the 33% usually occurs when watching programs during game day and there are two Rokus in use, so a delete was not occurring when we encountered the reported/recorded crash.

In any case the Plex for Roku app version is 6.9.10.7373

19

OK - Maybe there were a number of issues and I picked up on the PMS crash you mentioned and I guessed it led to the 33% buffering message - i probably was wrong here

What time was the 33% buffering text ? Without it, it would be guesswork

What I can see:

At 17:57 PMS crash following watching the Superman episode and deleting it from roku on 192.168.1.184 (primary roku)

Server was relaunched at 18:12:12 and again at 18:12:54

I can now see a tune request at 17:18 for I3.1.34884.zap2it.com from the same roku (192.168.1.184)
but immediately after this something else was played on the roku
and I cannot see any transcoder failures

So what time ?
Which roku?

20

Well speaking of being wrong (personal specialty of mine :grin:), as you now mention this there could have been exactly that occurring during the 33%. That is, there could have been such an activity taking place (deleting a file) when the 33% occurred. My focus was on the 33% and not other activities at the time.

So, that is probably our culprit in this case. It sounds like there are two issues here, or really one major one: when an arcane system failure occurs, no message is displayed to the user and they are left with a 33% spinning circle of doom. Additionally, to find out what happens there is a lot of work that has to take place to track this down.

This is surprising to me. It would seem this should be easily and readily emitted to the debug event log and I can simply copy/paste from there.

Are there any plans to at least improve the process here to help assist with tracking down these types of failures? At the least, it would seem a “system failure has occurred on the server, please check logs” on the Roku device.

Thank you for any consideration. :pray:

Now, with that rant out of the way. :slight_smile: It sounds like we have found another issue here and we still have the outstanding transcoder issue that we’re still tracking down. That will have to wait until next weekend.

That said, I will say that yesterday worked really well. That was the first 33% failure we saw after many hours of usage. There was indeed another one that occurred much later but I figured we had already captured one and didn’t think it would be worth the bother (in hindsight it seems this would have helped).

21

Well some good news here… We’ve gone 1.5 weekends without seeing this issue. Getting to the point where I feel like bragging about it here to tempt fate into breaking it later on today. :grin:

We’ve seen the 33% buffer pop up a few times, but each time it continues onto 100% and re-gain the stream.

I’m really hoping what we were encountering was a transient Windows issue that got repaired with a subsequent Windows Update patch. We’ll know more later today. :crossed_fingers: