[question / request] Set ffmpegdirect proxy via #KODIPROP in strm / m3u files #309
Comments
|
It should be possible to set this as a KODIPROP, although that use case is not currently supported. Let me take a look. Can you test something on Kodi 22 if I figure out how to do it? |
|
Will let you know once testbuilds are available, it can take a while to build. |
Thanks, will test and let you know |
|
Ok seems to work fine. What I tried: #EXTINF:-1,Example HLS stream I have a question: For Kodi to pass the proxy parameters to ffmpegdirect via the '|' pipe, I assume a new compile of Kodi is needed? This will also mean that e.g. inputstream.adaptive will also be compatible with a proxy when used in this way? At the moment "httpproxy=http://username:[email protected]:8081" is sent as header value, e.g. |
|
Nope, it should work wth the This is only for ffmpegdirect. I'm not sure what adaptive supports. |
No it does not, tried it again. It adds a header to the request like this: It is also clear from the abovementioned kodi forum thread that it is an issue since 2015 already and could be a security risk as proxy details is sent via headers to remote server. Where should I open an issue for this? |
|
So it doesn’t use the proxy at all and just adds a header instead? what’s wrong with using the kodiprops? |
|
I think I see where the value get's treateed the wrong way. Let me update the PR and give you some new testbuilds. |
|
Ok, can you try these testbuilds and see if it works via a |
Ok should I test like this? http://www.somewhere.com/playlist.m3u8|http_proxy=http://127.0.0.1:8080 |
I guess nothing. I was also wondering...what is default behaviour if I put an entry in m3u playlist and don't specify input.ffmpegdirect in the #KODIPROP, will it use inputstream.adaptive by default? (I think this is my experience so far) Also, I will have to open a issue for adaptive to also add proxy support? |
I tested this way as well as changing it to httpproxy but both are still added as headers. Like I said I can use the KODIPROPS way, I just thought it would be a more uniform way to do via the "|", then adaptive can also get sent the proxy info without the need for seperate #KODIPROP |
|
Ffmpeg supports a http proxy. Adaptive issues a different library so I don’t know if it can support a proxy at all. |
|
Can you try one more test build: This one simply add a log line to see if http_proxy is correctly set from a |
|
I'm getting a blank page without download links |
|
Apologies, here is the fixed link: |
|
Ok so different results depending on #KODIPROPS: With this: #EXTINF:-1,Video test (test Kodi 22 pipe) proxy works fine but when I stop the stream it makes a HEAD request to the manifest (https://example.com/index.m3u8) with the proxy set as a header (http_proxy: http://127.0.0.1:8081) if I do the following: #EXTINF:-1,Video test (test Kodi 22 pipe) it does not use the proxy at all, it puts the proxy as header and referer as header when doing manifest requests but no proxy header or referer header when doing video segment requests If I do: #EXTINF:-1,Video test (test Kodi 22 pipe) it does not use the proxy at all and puts proxy as header and referer as header for all requests (manifest and segments) In this last case since I did not put an #KODIPROP I think it plays the hls stream using inputstream.adaptive because it does not understand the proxy but understands the referer. So normal behaviour of playing a link when nothing is mentioned should be adaptive by default if I'm correct. |
|
In between my analysis of the proxy setting I saw lots of "ping" requests e.g. I guess these background requests is normal for testing since Kodi is nightly build and inputstream.ffmpegdirect is also a test version |
|
Any log statement starting with XXX? only the first example you gave is valid for ffmpegdirect. At a minimum those 3 props must be set for any ffmpegdirect call. I can look into why it moves into the header when stopping if you feel that’s important, OR you can just stick with KODIPROPs method of setting the proxy. only this first example should prompt the log line starting with XXX. |
Ok but why does Kodi usually do 2 HEAD requests when starting a stream, is it not to determine the mimetype and / or manifest type, I mean lots of people creating m3u files don't know what mimetype is? Or am I wrong? |
|
It’s the addon that does those requests not kodi. Correct, it’s to figure out what type of stream it is. |
Ok I meant addon. But why do I need 3 props instead of 1, if the HEAD statements can do the job - or am I missing something? |
|
There should be less requests if they are provided. If they are not I’d need to look into it. I’m not sure if http proxy affects this in any way. |
|
Of course there should be less requests if they are provided. I'm just trying to establish what is "normal" behaviour, meaning all people creating playlists might not provide mimetype but their url is still played correctly. So adding the proxy should not make a difference? |
As my title indicates, is it possible to set this on a per stream basis otherwise one needs to change the setting everytime in addon settings.
I also to refer to an old discussion:
https://forum.kodi.tv/showthread.php?tid=248440
The text was updated successfully, but these errors were encountered: