Video object HTTP request timeout

Dev Community Dev/API Corner
1

Does anyone know where the timeout setting (appears to be 20 seconds) is for the HTTP get request that calls the creation method for a VideoClipObject?

Does any know if there is a timeout value in Plex's code or some setting that will allow Plex to wait longer for a VideoClipObject request to be returned by a channel?

Or is that limit hard coded in the PMS executable?

The limit seems to be 20 seconds.

This limit does not appear to be enforced for directory objects.

 

Is it embedded in the PMS server compiled code, or in a Python file?

 

I am trying to access an external URL stream source that can take over 40 seconds to start streaming.  This is actually being done through VLC player, which re-streams it out for Plex.  It would be nice to start at the beginning of the stream, rather than mid-stream.

I have come up with a way using a separate thread and sleep delays in both the CreateVideoClipObject method and the indirect PlayVideo callback method that is currently working.  It appears that I am exploiting two 20 second timeout sessions for the two methods while trying to bring up the source in a separate thread.  Pretty ugly.

 

I would like to change the timeout period to 60 seconds to avoid this issue.

I made some minor changes to plex.js to extend the Plex/Web timeouts to 60 seconds for postbacks for DirectoryObjects and Settings actions.

 

If I can extend this also, that would make things simpler, easier and more reliable.  PMS is doing very well running my code, it just doesn't wait long enough for the response.

 

Thanks.

 

Mar 28, 2014 21:18:32:664 [13308] DEBUG - HTTP requesting to: ...

Mar 28, 2014 21:18:53:666 [11492] ERROR - Error issuing curl_easy_perform(handle): 28
Mar 28, 2014 21:18:53:666 [11492] WARN - Error issuing request to: ...
(Operation timed out after 20998 milliseconds with 0 out of -1 bytes received)
ar 28, 2014 21:18:53:666 [11492] DEBUG - Simulating 408 after curl timeout
Mar 28, 2014 21:18:53:666 [11492] ERROR - HTTP 408 downloading url ...
Mar 28, 2014 21:18:53:666 [11492] ERROR - [TranscodeUniversalRequest] Unable to get container: ...
Mar 28, 2014 21:18:53:666 [11492] VERBOSE - Completed request: GET 
2

(So you seem to have a much better grip on all of this channel stuff then me so it's hard to believe you haven't seen this one yet...But then again...I'm a master of overlooking docs myself so just in case, let me do my good deed for the day! ;))

HTTP

The HTTP API provides methods for making HTTP requests and interacting with the framework’s HTTP subsystem.

	HTTP.Request(<em>url</em>, <em>values=None</em>, <em>headers={}</em>, <em>cacheTime=None</em>, <em>encoding=None</em>, <em>errors=None</em>, <em>timeout=<object object at 0x10042bc40></em>, <em>immediate=False</em>, <em>sleep=0</em>, <em>data=None</em>)

	<p>Creates and returns a new <a  class="" href="https://dev.plexapp.com/docs/api/networkkit.html#HTTP.HTTPRequest" title="HTTP.HTTPRequest"><span>HTTPRequest</span></a> object.</p>
	
					Parameters:
				
					<ul  class=""><li><strong>url</strong> (<a  class="" href="http://docs.python.org/library/functions.html#str" title="(in Python v2.7)"><em>str</em></a>) – The URL to use for the request.</li>
					<li><strong>values</strong> (<a  class="" href="http://docs.python.org/library/stdtypes.html#dict" title="(in Python v2.7)"><em>dict</em></a>) – Keys and values to be URL encoded and provided as the request’s POST body.</li>
					<li><strong>headers</strong> (<a  class="" href="http://docs.python.org/library/stdtypes.html#dict" title="(in Python v2.7)"><em>dict</em></a>) – Any custom HTTP headers that should be added to this request.</li>
					<li><strong>cacheTime</strong> (<a  class="" href="http://docs.python.org/library/functions.html#int" title="(in Python v2.7)"><em>int</em></a>) – The maximum age (in second) of cached data before it should be considered invalid.</li>
					<li><strong>timeout</strong> (<a  class="" href="http://docs.python.org/library/functions.html#float" title="(in Python v2.7)"><em>float</em></a>) – The maximum amount of time (in seconds) to wait for the request to return a response before timing out.</li>
					<li><strong>immediate</strong> (<a  class="" href="http://docs.python.org/library/functions.html#bool" title="(in Python v2.7)"><em>bool</em></a>) – If set to <span>True</span>, the HTTP request will be made immediately when the object is created (by default, requests are delayed until the data they return is requested).</li>
					<li><strong>sleep</strong> (<a  class="" href="http://docs.python.org/library/functions.html#float" title="(in Python v2.7)"><em>float</em></a>) – The amount of time (in seconds) that the current thread should be paused for after issuing a HTTP request. This is to ensure undue burden is not placed on the server. If the data is retrieved from the cache, this value is ignored.</li>
					<li><strong>data</strong> (<a  class="" href="http://docs.python.org/library/functions.html#str" title="(in Python v2.7)"><em>str</em></a>) – The raw POST data that should be sent with the request. This attribute cannot be used in conjunction with <em>values</em>.</li>
					</ul>

Check out the rest of the docs here.

If you take a look at the docs, timeout is an argument already available for HTTP requests. This also appears to be the same for XML.ElementFromURL() & HTML.ElementFromURL() so adding timeout=60.0 will hopefully do the trick. Whether this is for GET requests or not is beyond me, I haven't really played with this much just yet... ;)

3

Thanks SHoTT, but that is not the problem I am having.  I have no problem with the HTTP request interface that can be called in the channel code.  That works fine and I am aware of that timeout attribute.  Let me try to clarify:

The problem I am trying to overcome is when I click on the Play button behind the VideoClipObject (on screen icon, second click) PMS executes the channel code that creates the VideoClipObject and provides the information about the stream and where to find it (URL).  PMS then connects to the source, not the channel code.  So the HTTP request is initiated by PMS, not the channel.

That process has a 20 second timeout for the channel code to return the object to PMS so it can start connecting and transcoding and feeding it out to the Roku or the Plex/Web player, etc.  I agree that 20 seconds should be enough time in almost all circumstances.  However, I am doing something out of the ordinary and if I provide that information to PMS too early, the stream feed will not be ready (there is a limit on how long PMS will wait for that also) and the process will fail.

I don't know exactly when the remote source will start streaming, but it can vary between about 20 seconds to almost 50 seconds.

There does not appear to be a setting for this timeout that I have found.  It is probably in the code since this is a PMS initiated and controlled process.  It would be nice if it is in a Python files that I can change to get this to work reliably.  It may also be coded in the PMS server executable, in which case, I am probably stuck.

I have been searching the text of the Python files for certain key words and values, but no luck.

It appears that all the Python code is for the client side programming support like channels, and not for server side programming (i.e. PMS).

If I'm wrong about this, someone please correct me.

If someone knows that this timeout cannot be changed, someone please let me know.

Thanks.

4

I believe that the timeout you are running into issues with will vary depending on the client app. If PMS is not transcoding the video for the client app, then it is not directly involved in the http request for the video stream. Once the channel code passes the video url to the client app, then the client app's player takes control. Each client may have a different default http timeout and we have little to no control over that since the native player is used in most cases.

5

Thanks for joining in Mike.  You're a great participant here on the forum and a gracious and valuable contributor.  I know that the client/player app takes control once PMS passes the connection.  That is something beyond my control.  I have no problem with that.

What I am trying to accomplish is holding off PMS from either getting the container or getting the URL from the channel (after requesting it) and passing the transcode off to the client without timing out.

A little further clarification:

When the user clicks on the play button behind the VidoeClipObject icon, the channel makes a final VCO to hand back to PMS, which then starts transcoding the source (in my case) and passes that info and the link to the transcode along to the client/player (as far as I can determine).  I would like PMS to wait up to 60 seconds or so for the VCO to be returned before timing out and saying that no container was returned; or alternatively, waiting 60 seconds or so for the feed URL to respond before it starts trying to transcode that source for the client/player.  In my case, PMS is transcoding the output from VLC (the URL source which is an mpegts) to an HLS for the Roku (the client).  Both of these appear to have a 20 second limit.  I am exploiting both of these with Thread.Sleep methods to get this to work, but it is not reliable; it is a delay game/hack that mostly works within limits.  I just wanted to see if it would work at all, and it can.

So the issue is between PMS and the channel and does not involve the client.  Does this make sense, or am I misunderstanding this?

I know that this is outside the norm and probably intent of the Plex design.  But since it is a timeout (force close of a connection) I thought that it should be relatively easy to adjust (at least on my copy of Plex for now). Maybe I'm wrong.

Do I understand the process correctly here?

Did I misunderstand your point?

Thanks.

6

Thanks for joining in Mike.  You're a great participant here on the forum and a gracious and valuable contributor.  I know that the client/player app takes control once PMS passes the connection.  That is something beyond my control.  I have no problem with that.

What I am trying to accomplish is holding off PMS from either getting the container or getting the URL from the channel (after requesting it) and passing the transcode off to the client without timing out.

A little further clarification:

When the user clicks on the play button behind the VidoeClipObject icon, the channel makes a final VCO to hand back to PMS, which then starts transcoding the source (in my case) and passes that info and the link to the transcode along to the client/player (as far as I can determine).  I would like PMS to wait up to 60 seconds or so for the VCO to be returned before timing out and saying that no container was returned; or alternatively, waiting 60 seconds or so for the feed URL to respond before it starts trying to transcode that source for the client/player.  In my case, PMS is transcoding the output from VLC (the URL source which is an mpegts) to an HLS for the Roku (the client).  Both of these appear to have a 20 second limit.  I am exploiting both of these with Thread.Sleep methods to get this to work, but it is not reliable; it is a delay game/hack that mostly works within limits.  I just wanted to see if it would work at all, and it can.

So the issue is between PMS and the channel and does not involve the client.  Does this make sense, or am I misunderstanding this?

I know that this is outside the norm and probably intent of the Plex design.  But since it is a timeout (force close of a connection) I thought that it should be relatively easy to adjust (at least on my copy of Plex for now). Maybe I'm wrong.

Do I understand the process correctly here?

Did I misunderstand your point?

Thanks.

Perhaps I'm way off base here but, it sounds to me like you're double-transcoding or least double-remuxing content for some clients. What is the original source and why does VLC need to be in the picture at all?

FWIW, mpegts is the (most common) container type that HLS delivers and AFAIK all Plex clients handle it natively. So, to say that PMS needs to transcode the stream seems redundant. Is it a bandwidth issue?

7

The source is an mp4 file sitting out on the web somewhere on a system that does not respond very quick to a request.  The source moves to a different url every couple days.

The video is H264 and the audio is AAC:

    "category":{
      "Stream 0":{
        "Frame_rate":"25",
        "Codec":"H264 - MPEG-4 AVC (part 10) (avc1)",
        "Type":"Video",
        "Language":"English",
        "Resolution":"640x360"
      },
      "Stream 1":{
        "Bitrate":"127 kb/s",
        "Type":"Audio",
        "Sample_rate":"44100 Hz",
        "Codec":"MPEG AAC Audio (mp4a)",
        "Bits_per_sample":"16"
      },
 
VLC transcodes to mp2 since VLC's AAC output seems to be less than robust.  This is not the only file I want to access; others may not be in this format.
In this case, it works if I turn off VLC transcoding and just have it remuxed to an mpegts from the mp4.  I'm trying to make it more useful by allowing VLC to transcode whatever it can read to what Plex prefers.
 
VLC is not delivering HLS; it is delivering an mpegts stream.  Plex is creating the HLS for Roku.  VLC can deliver HLS, but I'm not sure it provides the m3u8 early enough.  I haven't worked much on that yet.

Based on what I learned initially, Plex cannot deal with this directly at this time.  Am I mistaken?

Thanks.

8

H264/AAC MP4 video files are considered pure gold in the world of channel development. Every Plex client app can handle them natively. No transcoding necessary. VLC is only getting in the way.

9

I know that H264/AAC are what Plex and Roku "desire" most.

The question is can Plex handle a remote URL for an mp4 file with no metadata?

I'm not sure what VLC is doing for 40 to 50 seconds, but VLC is not ready to play it for that long (buffering?).  This is not true for all sites though.

I also wanted a channel that could work with whatever VLC could deal with, which Plex could not.

If I just drop the url in the browser address bar, the video starts in a couple seconds.  So, it is not that the server is incredibly slow.

10

Yes. Metadata just makes the channel look pretty. It’s perfectly possible to build a channel with a basic interface “play the video” button and have it play your MP4.


Since VLC and Plex Media Server both use ffmpeg under the hood, there are not likely many situations where Plex will fall flat while VLC doesn’t (as long as you pass the proper parameters in your channel code).

11

Thanks Mike.

I'll try that out.

If nothing else, I can use VLC to get the "proper parameters" (VideoClipObject and MediaObject attributes) about the source to hand it off to Plex.

I already have that implemented.

12

Well, I don't know how much information I need about the stream for the MediaObject, but handing the URL directly to Plex works well.

Plex is still transcoding and remuxing the source to an HLS, even though the MediaObject attributes info for Plex specify that it is mp4/h264/aac (Plex log using Plex/Web client below).  For Roku (client) it also transcodes except the audio out is aac, not mp3 (essentially the same log entries).

Apr 01, 2014 08:45:25:020 [6060] DEBUG - Request: [127.0.0.1:60876] GET /video/:/transcode/universal/session/r9y0och42hbprpb9/base/index.m3u8 (5 live)
Apr 01, 2014 08:45:25:020 [6060] DEBUG - MDE: analyzing video part 0: mp4/h264/mp2/
Apr 01, 2014 08:45:25:020 [6060] DEBUG - MDE: selected video transcode profile: hls - mpegts/h264/mp3/
Apr 01, 2014 08:45:25:020 [6060] DEBUG - MDE: remuxing h264 video stream
Apr 01, 2014 08:45:25:021 [6060] DEBUG - MDE: selected media 0
Apr 01, 2014 08:45:25:021 [6060] DEBUG - [Universal] Remuxing to hls/mpegts/h264/mp3
Apr 01, 2014 08:45:25:021 [6060] DEBUG - Starting a transcode session r9y0och42hbprpb9 at offset -1.0 (stopped=1)
Apr 01, 2014 08:45:25:021 [6060] VERBOSE - [Event] Firing plex.event.transcodesessionmanager.sessionstarted to 0 sink(s)
Apr 01, 2014 08:45:25:021 [6060] DEBUG - Job running: C:\Program Files (x86)\Plex\Plex Media Server\PlexNewTranscoder.exe -i "http://cs6-8v4.vk.me/p15/6c0a9bfab400.360.mp4" -threads "0" "-y" -segment_format "mpegts" -f "segment" -loglevel "quiet" -loglevel_plex "error" -map_metadata "-1" -progressurl "http://127.0.0.1:32400/video/:/transcode/session/r9y0och42hbprpb9/progress" -vcodec "copy" -flags "-global_header" -segment_time "10" -segment_start_number "0" -bsf "h264_mp4toannexb,h264_plex" "-sn" -acodec libmp3lame -ac "2" -aq "2" "media-%05d.ts" 
Apr 01, 2014 08:45:29:115 [7156] INFO - [Transcoder] Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'http://cs6-8v4.vk.me/p15/6c0a9bfab400.360.mp4':
Apr 01, 2014 08:45:29:116 [8148] VERBOSE - Finished writing response for GET /log?level=2&source=Transcoder&message=Input%20%230%2C%20mov%2Cmp4%2Cm4a%2C3gp%2C3g2%2Cmj2%2C%20from%20%27http%3A%2F%2Fcs6-8v4.vk.me%2Fp15%2F6c0a9bfab400.360.mp4%27%3A%0A, 0 bytes in 4087ms
Apr 01, 2014 08:45:29:117 [5584] INFO - [Transcoder]     Stream #0:0(eng): Video: h264 (Constrained Baseline) (avc1 / 0x31637661), yuv420p, 640x360 [SAR 1:1 DAR 16:9], 452 kb/s, 25 fps, 25 tbr, 25 tbn, 50 tbc
Apr 01, 2014 08:45:29:117 [8020] VERBOSE - Finished writing response for GET /log?level=2&source=Transcoder&message=%20%20%20%20Stream%20%230%3A0%28eng%29%3A%20Video%3A%20h264%20%28Constrained%20Baseline%29%20%28avc1%20%2F%200x31637661%29%2C%20yuv420p%2C%20640x360%20%5BSAR%201%3A1%20DAR%2016%3A9%5D%2C%20452%20kb%2Fs%2C%2025%20fps%2C%2025%20tbr%2C%2025%20tbn%2C%2050%20tbc, 0 bytes in 16ms
Apr 01, 2014 08:45:29:118 [5456] INFO - [Transcoder]     Stream #0:1(und): Audio: aac (mp4a / 0x6134706D), 44100 Hz, stereo, fltp, 127 kb/s
Apr 01, 2014 08:45:29:118 [8020] VERBOSE - Finished writing response for GET /log?level=2&source=Transcoder&message=%20%20%20%20Stream%20%230%3A1%28und%29%3A%20Audio%3A%20aac%20%28mp4a%20%2F%200x6134706D%29%2C%2044100%20Hz%2C%20stereo%2C%20fltp%2C%20127%20kb%2Fs, 0 bytes in 16ms
Apr 01, 2014 08:45:29:129 [7156] DEBUG - [Transcoder] Average FPS ~ 25 fps, Frame rate ~ 25 fps.
Apr 01, 2014 08:45:29:129 [8148] VERBOSE - Finished writing response for GET /log?level=3&source=Transcoder&message=Average%20FPS%20~%2025%20fps%2C%20Frame%20rate%20~%2025%20fps., 0 bytes in 0ms
Apr 01, 2014 08:45:29:144 [5456] INFO - [Transcoder] Output #0, segment, to 'media-%05d.ts':
Apr 01, 2014 08:45:29:144 [8148] VERBOSE - Finished writing response for GET /log?level=2&source=Transcoder&message=Output%20%230%2C%20segment%2C%20to%20%27media-%2505d.ts%27%3A%0A, 0 bytes in 15ms
Apr 01, 2014 08:45:29:148 [6060] DEBUG -  [FFMPEG] Duration: 2637
Apr 01, 2014 08:45:29:148 [6060] DEBUG - Read line, and done: 1
Apr 01, 2014 08:45:29:148 [6060] DEBUG - Started session successfully: r9y0och42hbprpb9
Apr 01, 2014 08:45:29:148 [6060] DEBUG - HLS: Building an M3U8 for 2637 total seconds with 10 seconds/segment, target duration of 10.
Apr 01, 2014 08:45:29:149 [6060] VERBOSE - Completed request: GET /video/:/transcode/universal/session/r9y0och42hbprpb9/base/index.m3u8: 2200
Apr 01, 2014 08:45:29:149 [8020] VERBOSE - Finished writing response for GET /video/:/transcode/universal/session/r9y0och42hbprpb9/base/index.m3u8, 0 bytes in 4165ms
Apr 01, 2014 08:45:29:154 [5584] INFO - [Transcoder]     Stream #0:0: Video: h264 (avc1 / 0x31637661), yuv420p, 640x360 [SAR 1:1 DAR 16:9], q=2-31, 452 kb/s, 25 fps, 90k tbn, 25 tbc
Apr 01, 2014 08:45:29:155 [8148] VERBOSE - Finished writing response for GET /log?level=2&source=Transcoder&message=%20%20%20%20Stream%20%230%3A0%3A%20Video%3A%20h264%20%28avc1%20%2F%200x31637661%29%2C%20yuv420p%2C%20640x360%20%5BSAR%201%3A1%20DAR%2016%3A9%5D%2C%20q%3D2-31%2C%20452%20kb%2Fs%2C%2025%20fps%2C%2090k%20tbn%2C%2025%20tbc, 0 bytes in 16ms
Apr 01, 2014 08:45:29:156 [5456] INFO - [Transcoder]     Stream #0:1: Audio: mp3, 44100 Hz, stereo, fltp
Apr 01, 2014 08:45:29:156 [8020] VERBOSE - Finished writing response for GET /log?level=2&source=Transcoder&message=%20%20%20%20Stream%20%230%3A1%3A%20Audio%3A%20mp3%2C%2044100%20Hz%2C%20stereo%2C%20fltp, 0 bytes in 16ms
Apr 01, 2014 08:45:29:157 [6060] DEBUG - Request: [127.0.0.1:60897] PUT /video/:/transcode/session/r9y0och42hbprpb9/progress?width=640&height=360 (5 live)
Apr 01, 2014 08:45:29:157 [6060] DEBUG -  * width => 640
Apr 01, 2014 08:45:29:157 [6060] DEBUG -  * height => 360
Apr 01, 2014 08:45:29:158 [6060] DEBUG - We want 6 segments ahead, last returned was -1 and max is -1.
Apr 01, 2014 08:45:29:158 [6060] DEBUG - It took 0.000000 sec to serialize a list with 0 elements.
Apr 01, 2014 08:45:29:158 [6060] VERBOSE - Completed request: PUT /video/:/transcode/session/r9y0och42hbprpb9/progress?width=640&height=360: 2200
Apr 01, 2014 08:45:29:158 [8020] VERBOSE - Finished writing response for PUT /video/:/transcode/session/r9y0och42hbprpb9/progress?width=640&height=360, 0 bytes in 0ms
Apr 01, 2014 08:45:29:272 [5584] DEBUG - Request: [127.0.0.1:60898] GET /video/:/transcode/universal/session/r9y0och42hbprpb9/base/00000.ts (5 live)

When I said I have no metadata, I don't mean just the pretty stuff.  In general, I don't know the mux container (except by filename extension, if provided), the codecs, the duration, bitrate etc.  I know this for this test case, but not in general. VLC can get most of that info. 

It appears that Plex (for either Plex/Web or Roku as the client) does not need any of that information.  It is working fine with no information through attributes at all (except for the url, of course).

I believe that Roku cannot accept an mp4 container at this time.

It looks like Plex/Web wants mp3 audio.

So, I guess that transcoding is still required, at least to remux, in both cases.

This does resolve this issue for this case.  That was too easy.

Can a file name with path be passed to Plex as the source URL?

If so, do you know the format?

I tried C:/.../...mp4  Plex doesn't like it.

Thanks.

13

Can a file name with path be passed to Plex as the source URL?

If so, do you know the format?

I tried C:/.../...mp4  Plex doesn't like it.

Thanks.

There is not currently any support for streaming from disk via channels.

14

That's kind of odd, since Plex will discover files on the system drives and those can be played.

Oh well.  Thanks Mike, you've been very helpful.

While all this was good, and I made some real progress here, the original question remains:

Does any know if there is a timeout value in Plex's code or some setting that will allow Plex to wait longer for a VideoClipObject request to be returned by a channel?

Or is that limit hard coded in the PMS executable?

The limit seems to be 20 seconds.

This limit does not appear to be enforced for directory objects.

Thanks.

15

There does not appear to be anyone who knows the answer to this timeout question, or if they do, they did not post to this topic.

Thanks.

16

The timeout is handled specifically by each Plex App and there's no way to override it that I've ever heard of.

The problem that you're running into here is that you're adding many layers of complication to everything by using VLC in between.  If you have URL's of MP4s it could be put into a channel with literally a couple of lines of code and would run perfectly (and play natively on probably every single Plex app without the need for any transcoding).  What you're doing here seems like you're introducing 2 layers of transcoding into things that should be able to play natively.  You're transcoding it with VLC and judging from the additional timeouts you've done something with the output of VLC that PMS doesn't like and it's transcoding the video yet again.  

So in addition to the timeouts with the multiple layers of transcoding and the extra CPU overhead it causes, you're also very likely losing a ton of video quality.

The "correct" answer here is that if you have web playable MP4 links you should write a channel that plays them directly instead of jumping through hoops and doing layers of transcoding.

17

And just to add to this conversation, Mikedm139 answered this quite some time ago but I think you just chose to ignore his responses.

18

If Mike answered this quite some time ago, I did not recognize his response as actually answering my question.  I do not ignore Mike's responses as he is very helpful and seems to be a really nice guy.  And based on his picture icon, a really handsome guy too.  :)

Several timeout issues were addressed.  I have already altered timeouts in Plex/Web and I believe the one I would like to change is not in there.  The same timeout seems to be occurring when using either Plex/Web or Roku.  I am trying to understand if a very specific timeout can easily be changed.

I already have the remote mp4 streaming directly through Plex in my channel.  I did not ignore that suggestion and it works well and was fairly straight forward to implement.

My goal wasn't just to get a specific remote file to stream to Roku, it was to get a VLC interface channel working.  At this point, I have that resolved, and even implemented an alternate strategy for the timeout issue, with only a minor lack of robustness for one feature, and no special mods to make the channel work.  So far, 2 coding errors in Plex have been corrected due to issues I found and/or raised.

If the timeout is in the Plex Apps, then there is no simple solution because it is spread out too far.  I thought that PMS was processing the Plex channel code and handling the VideoClipObjects returned by the channel since channels seem to be integrated with PMS on the Plex server, not in the Plex Apps, which may not be running on the same system as PMS.  Maybe I'm wrong here.

The "correct" answer here, as you stated, is the answer to a problem that I am not trying to solve.

19

Does anyone know where the timeout setting (appears to be 20 seconds) is for the HTTP get request that calls the creation method for a VideoClipObject?

Does any know if there is a timeout value in Plex's code or some setting that will allow Plex to wait longer for a VideoClipObject request to be returned by a channel?

Or is that limit hard coded in the PMS executable?

The limit seems to be 20 seconds.

This limit does not appear to be enforced for directory objects.

 

Is it embedded in the PMS server compiled code, or in a Python file?

The timeout is handled specifically by each Plex App and there's no way to override it that I've ever heard of.

If Mike answered this quite some time ago, I did not recognize his response as actually answering my question.  I do not ignore Mike's responses as he is very helpful and seems to be a really nice guy.  And based on his picture icon, a really handsome guy too.  :)

Several timeout issues were addressed.  I have already altered timeouts in Plex/Web and I believe the one I would like to change is not in there.  The same timeout seems to be occurring when using either Plex/Web or Roku.  I am trying to understand if a very specific timeout can easily be changed.

I already have the remote mp4 streaming directly through Plex in my channel.  I did not ignore that suggestion and it works well and was fairly straight forward to implement.

My goal wasn't just to get a specific remote file to stream to Roku, it was to get a VLC interface channel working.  At this point, I have that resolved, and even implemented an alternate strategy for the timeout issue, with only a minor lack of robustness for one feature, and no special mods to make the channel work.  So far, 2 coding errors in Plex have been corrected due to issues I found and/or raised.

If the timeout is in the Plex Apps, then there is no simple solution because it is spread out too far.  I thought that PMS was processing the Plex channel code and handling the VideoClipObjects returned by the channel since channels seem to be integrated with PMS on the Plex server, not in the Plex Apps, which may not be running on the same system as PMS.  Maybe I'm wrong here.

The "correct" answer here, as you stated, is the answer to a problem that I am not trying to solve.

To spell out what I was saying is the correct answer here it is again: The timeout is not within the control of the channel framework and it is not something that people can modify in the Plex App preferences so it is beyond your control.

20

Well, that is an answer that actually addresses my question.  It is also what I thought might be the answer.

It certainly could have been stated earlier.

My question seemed plain enough.  I didn't ask for alternate solutions to my problem, I asked a specific question.

Which is why I included  the question: "Or is that limit hard coded in the PMS executable?"

Based on your response, the simple answer to that question is "yes".

I knew the timeout limit couldn't be in the Plex App since the Plex Server log showed that the server never attached to the stream.  For a different issue, I adjusted the Plex/Web app because I did see the Server continue its processing of the channel code, so I knew the timeout was probably in the Web App.

Thank you.