Resume not working on Plex direct play

[davilla]

sorry, still confused about what you call 'local' access.

[bgraversen]

local access means that both the Plex Media Server and the mkv files are on the same box/VPS not that the Plex Media Server is on the same network as the MrMC plex client.

The flow would work like this:
Plex Media Server opens the file on the hard drive /home/plex/media/file.mkv and then direct plays the file to my Fire TV box at home. This is the same as if I was accessing a friends Plex Server and he has the media on the same box as the server. So I'm accessing the server remotely but PMS has access to the files locally.

And the other flow:
If the media is in the Amazon cloud there is more of a delay because Plex doesn't have immediately access to the file. Chunks of the file need to be pulled from Amazon Cloud Drive first before they are then sent to the MrMC Plex client. I don't know if this is registered as a slower I/O issue or something else but I do know that the partial transfer error only shows a retry with the first scenario when the whole file is stored locally on the Plex Media Server.

[davilla]

That's way too confusing lets call it local media, ie. media is on the same network as your client. Sounds like both of yours are remote media related. The moment you bounce outside your local network, then a lot of other things come into play. Once the plex client has the net path to the item, then where the actual plex server is located does not matter. That path is either local or remote.

[bgraversen]

Ok so that makes since. So essentially Plex is not doing anything with the file and just passing it through to the client meaning I'm accessing the file path directly? Also when MrMC plex client asks for a specific seek point it is accessing the file directly? Could it be the fact that the entire file is not available at the time of the seek request be the reason I'm seeing both the partial transfer error and the eof response?

Referring to this in the log
NOTICE: DVDPlayer: eof, waiting for queues to empty

[davilla]

Correct, once our plex client has the listing, it also has the net paths. playing involves the net paths. the resume point is also fetched when the listing is fetched. When playback starts, the entire file better be there or you get into issues like seeking to a resume point that does not exist (yet). Hit the timeout and you are done.



Note, transcoding is very different. There are several tricks being played, specially for a resume.

[davilla]

There could be another thing going on, a few versions ago, I bumped READ_CACHE_CHUNK_SIZE from 64*1024 to 512*1024 and some things are having issue with it. Seemed fine for us with smb/nfs/http/etc but maybe too aggressive a bump for some.

[bgraversen]

I'm not sure direct play will ever work in my case then if the requirement is to have the full file downloaded from ACD when the seek is requested. Is the seek behavior different when actively playing a movie as opposed to resuming it from a complete stop.

To be clear if I'm watching the movie and skip to anywhere else in the movie without stopping I can seek just fine and I'm confident that the entire file has not completely downloaded from Amazon Cloud Drive. If I stop the movie and then try to resume it at the point I stopped it that's when I get the failure.

Do you think it would be worth a try to try and create an SMB share and see if that has the same behavior? That could help us rule out Plex as the culprit.

[davilla]

We have to wait for 3.0.4 testflight, then I can turn up the debug log to include logging that is normally only enabled during development. Those areas are turned off under the 3.0.3 test flight.

And yes, startup/resume is very different than seeking around once started. There are a lot of things going on during startup, a big one is the file is being probed to see what it is, what video format, how many audio tracks and their formats, subtitles, etc. One just does not jump to some point and go. With a seek, you already know the container (mkv, mp4, etc) and only need to know if the stream properties have changed. The demuxer provides this info but it must get setup 1st.

[bgraversen]

Great Thanks! We'll pick this up in the 3.0.4 testflight. Looking forward to helping out.

[davilla]

3.0.4 testflight is starting up