As we stand right now Plex doesn't support HTTP/1.1 Transfer-Encoding: chunked and it also has some serious problems when receiving large streams (HD content in mpeg-ts).
Basically the stream *may* start but won't playback smoothly because Plex is constantly trying to rebuffer -- this only applies to HD streams, SD (720p) will playback just fine.
The bad thing in this situation is that you don't have a proper way to stream files via HTTP/1.0 without providing a Content-Length header.
This in turn is not possible in a clean fashion if you provide a continuous stream which as a result has no known content length or end.
I'm working really hard to try to get Plex to smoothly playback the TS-stream I'm feeding via HTTP but since chunking isn't an option I'm slowly running out of ideas.
I think it would be worth a try if Plex (at least Laika) will cope with a http-live-stream containing HD content in TS fragments..
Are there any plans to upgrade the curl backend used by plex to support HTTP/1.1 chunked encoding (OSX shipped curl has it..)?
Is the permanent rebuffering for files without content length a known issue?
I don’t consider it ignorance in any way - it’s a valid question, let me try to explain my situation:
I’m providing a live stream via http.
‘live’ in this case mean really live, actually remuxed seconds before being made available via HTTP.
Until the user cancels the stream there is no known runtime limit and so I can’t provide the normal Content-Length header HTTP/1.0 uses.
So to have a clean way of communicating the data size that is transmitted to the client I would prefer chunked transfer encoding as HTTP/1.1 defines it.
This solves the problem for the client to decide if the transmission was interrupted or if the server is just busy collecting new data to transmit.
(Each chunk contains a smal header including the byte length that will follow.)
I just managed to get Plex to accept a stream with a fake Content-Length header and by denying I would support byte-ranges (which is true).
But I think telling Plex that you want to stream something like 1TB of data just to keep the stream running is not a clean way of doing things.
On the other hand if I don’t provide the mentioned headers Plex seems to have a really hard time buffering and displaying the stream.
This could be related to the fact that there is no way for it to know If I’m done sending data or just preparing new data to be transmitted.
According to HTTP/1.0 without a specified content length the client should just read from the server until the socket is closed but that doesn’t work out like expected.
I hope this made my issue a little clearer - if not, let me know.
Unless Plex uses keep-alive for media streams there's no need to know the length of the stream -- clients should simply download until the server disconnects and assume that an EOF exception marks the end of the stream (which is what HTTP/1.0 clients typically do). If the server knows the length of the stream it can provide the related header, but other than progress bars or error checking it doesn't serve any purpose.
For things like XML data and UI images it's clearly worthwhile to reuse a connection, but I have trouble understanding the benefit for media streams. The wasted TCP setup is pretty trivial compared to a typical media stream size/duration, and clients certainly wouldn't want to wait on zombie media transfers before beginning new ones, or before sending new API queries. HLS might see some benefit from keep-alive (depending on the segment duration) but the way HLS is implemented in the Plex Media Server the next segment's size is known before the transfer begins.
Am I misunderstanding your use case? Does one of the transfer types Plex supports make use of a large number of segments of unknown sizes?
--
I'd much rather see compression support myself. Many of my common XML results are 1+ MB and compression on those would drastically reduce my remote library browsing delays. And chunking certainly might be handy there, so you don't have to pre-calculate the compressed stream length.
Compression is already supported in the 0.9.6 series :) It indeed makes things much faster when accessing the server remotely, over clients that support it. Just send "Accept-Encoding: gzip" for compressed goodness.
from what i gather in this thread there are some hacks that can make it work (manipulating the length header), but it sounds like there is another way?
am i right that you are saying i can set the “keep-alive” header for the request to make plex keep streaming until EOF?
then again i cant get plex to open this stream at all. is this because instead of the content-length header being absent VLC is setting it to 0? can I just manipulate the response headers within plex to remove this header if this is the case?
A "content-length" header of 0 is valid, per RFC2616/14.13, and typically clients should treat such responses as though there is no document body (unless a non-identity transfer encoding is also specified). A length of 0 is not a special value and does not indicate that the document body length is unlimited, so VLC likely should not be sending that value in the first place -- servers that cannot determine the length of the response should not send a content-length header at all.
Adding or removing keep-alive would not change anything. Keep-alive only comes into play if and when the document body has been transferred to its natural completion.
I am not aware of any way to to manipulate HTTP behavior in Plex directly, but I haven't really looked into it, so there might be. It's sure not something you can just toggle in the UI though.
Assuming the content-length header is your problem, I suspect other clients that do work are simply ignoring that header. Such behavior is probably contrary to the RFC, but that violation might be useful for purposes of compatibility; I couldn't say without knowing a lot more about the specifics of the situation. Plus I personally am unlikely to code such changes, so my opinion isn't of great value anyway.
Of course all of the above assumes that the HTTP transaction in question is intended to transfer the actual media, and that such media is in some sort of single-stream format, which I cannot determine from the information provided.
I’m unsure if VLC always sets that header or if it was set in response to a request header that curl had (for example what types of content curl would accept).
I did figure out the problem was attempting to stream video from an “application” plugin which apparently plex does not allow. If anybody wants more details they are in the thread i linked above, but long story short streaming from VLC to plex works just fine and no HTTP header manipulation is required.
