Xtream proxy redirect http/https mixing issues

[haroldthegray]

Not sure if this is a bug/feature-request/dumb-user problem...

I have an instance that I'm reverse proxy-ing through nginx. nginx provides https and gets back to m3u-filter's http service.
No problem.
I am filtering Xtream playlists on both sides.
No problem.
Trying to open a stream?
Problem.

I am using proxy-redirect Xtream inside m3u-filter.
Calling up a stream hits https://m3u.mynginx.com/live/user/pass/0000001.ts as expected, which redirects to my source input https://XXstreamsXX.com:80/live/XXuserXX/XXpassXX/0000001.ts mostly as expected, EXCEPT it is HTTPS whereas my source is HTTP.

I'm guessing that the protocol is being stripped at some point when the redirection URL is built, but I figure strictly adhering to the input URL as defined might be best if that is possible?

source.yml snippet for clarity

sources:
  - inputs:
      - enabled: true
        type: xtream
        headers:
          User-Agent: "..."
          Accept: application/json
          Accept-Encoding: gzip
        url: 'http://XXstreamsXX:80'
        username: XXuserXX
        password: XXpassXX

[euzu]

@haroldthegray I will take a look at this.
But i am busy this weekend.

[haroldthegray]

Thank you. Hope your busy weekend is fun and not chores.

[euzu]

@haroldthegray there is a debug output debug!("Redirecting stream request to {}", stream_url);
Can you test it with loglevel debug and tell me the debug output uses https?

[haroldthegray]

Yep... this was a dumb-user (me) problem. Higher level nginx proxy config I setup was rewriting. Sorry about the confusion.

While we're here talking about user-error...
How should I include two different xtream sources in the YAML?

sources:
  - inputs:
      - enabled: true
        type: xtream
        headers:
          User-Agent: "..."
          Accept: application/json
          Accept-Encoding: gzip
        url: 'http://XXstreamsXX:80'
        username: XXuserXX
        password: XXpassXX
      - enabled: true
        type: xtream
        headers:
          User-Agent: "..."
          Accept: application/json
          Accept-Encoding: gzip
        url: 'http://YYotherstreamsYY:80'
        username: YYuserYY
        password: YYpassYY
    targets:
      - name: base
        output:
          - type: xtream
        filter: .....

According to the logs, this pulls in the source xtream info just fine, but when it comes to making it available at the target, everything gets the first source's URL and credentials. Proper stream SID in the URL, just wrong source for redirect.

[euzu]

@haroldthegray congratulations, you found a bug. I will fix it.

[euzu]

@haroldthegray i have created the branch bugfix/multi_xtream_input

It is WIP,

my solution is to give all streams a new id and store the mapping. This part is done.
Now i have to implement the id mapping for redirect and reverse proxy.

[euzu]

@haroldthegray i have now a version which can be tested on the branch bugfix/multi_xtream_input.

Can you test it for live and video files.
For series there is work to do, because series are different. The ids are not fetched initially, they are only accessed when you open a series.

Can you build it or should i provide you a static build ?

[haroldthegray]

Will build and give it a shot.

[haroldthegray]

@euzu I tested live files with a build from the bugfix branch, but I'm still getting the issue of the first input's URL and credentials being used on files from the second input.

[euzu]

@haroldthegray thanks for testing. I need to set up a mock xtream server to debug.
I try to figure out the problem.

[haroldthegray]

No worries. I'm happy to test more. Just let me know.

[euzu]

@haroldthegray lets continue with the issue and close this discussion.