Plex claims the server is not fast enough to transcode.

This has a few times lately. Just now I watched a 1080p movie (with subtitles) right on the server, and twice the movie just stopped claiming the server is not fast enough to decode.

Given that I have an i5-6600K, 32 GB DDR4 and the movie is on a dedicated SATA3 drive, I doubt that’s true at all. At the time of the errors there was nothing at all in the system logs, there was no CPU intensive tasks nor anything using the disk. I’ve also run a checkdisk of all drives, and they’re all reporting back fine too.

It might be worth noting that I’ve also had Plex say the same thing a couple of times, just as the playback of a TV show has ended. That is: Instead of returning to the TV show listing, it says it can’t play it back. Might be related, might not. This seems random and is not consistently reproducible.

So in the words of Leonard Hofstadter…what’s up with that?

Plex is all about raw CPU power, and certain codecs can require more. Is this a h.265 rip? Or perhaps VC-1? If so, that would explain it. Do you have any possibilities to try the PMP player perhaps? It would probably work better since it most likely wouldn’ require transcoding. You can install it on the server without issues.

It’s h.264, and if you look at the logs the number of transcoded frames are actually throttled because it maxes out. It’s not a Raspberry Pi :slight_smile:

And sure, I can try the PMP, but that’s just a workaround, not a fix. If I wanted that I’d just play all the media with say…any other media player.

The log you provided does not include the time when the error occurred so I can’t tell what caused the problem. You’ll need to provide the earlier logs or try to recreate the error and provide the log right after it happens.

Which is weird, because I cleaned the logs before it happened, ran until the error occurred, closed down the server and saved the logs.

Have it happen again, but now every time:

I have a three-part movie that won’t play all three parts. Instead, it just plays the first one then says the server is not fast enough, just as the movie ends.

Included is a clean log, screenshot and the XML entry for said movie.

I tend it get this error when I am uploading a lot and I don’t have much bandwidth

@barney007, there was no bandwidth activity, watched on the local machine and happens every time…but only at the end of the episode. When it stops. Not during any part of the playback.

Ah. That us a totally different error than the transcoding one.

That error is very generic and basically means that the client was not able to receive the stream info fast enough. Unfortunately, there are many things that could be causing this error and PMS is not able to determine the cause.

If this is happening at the end of playback, 1 possibility (just thinking out loud) is that your server (or your media drive) went to sleep while the playback was finishing, so when the client tried to signal the server that it was done, it timeout waiting for the server (or drive) to come back online. Check your sleep settings and raise them. See if that makes the error go away.

  1. All the drives are set to never spin down.
  2. Even if they did, It doesn’t matter: if I right awayfast forward to the last few seconds of the movie, it still complains.
  3. I’ve verified the file system and done a surface scan.
  4. I verified/ran a repair on the file, using MKVRepair.
  5. There’s no discernible system load/drive access, except for the movie playing.

From what I can tell after some further testing:

Playback directly on server:

  • Firefox Beta: Transcode Error at EOF, does not play subsequent parts.
  • Firefox Release version: Transcode Error at EOF, does not play subsequent parts.
  • Firefox Release and beta with add-ons disabled: Transcode Error at EOF, does not play subsequent parts.
  • Chrome: No transcode error, does not play subsequent parts.

LAN playback:

IPhone app: Does not play subsequent parts.
IPad app: Does not play subsequent parts.
PS4: Does not play subsequent parts.

Since it at least finishes quietly in Chrome it seems we’re looking at two different bugs in play here. One for playback of multi-part and one for Firefox.

Addendum: