Closed saulchristie closed 1 month ago
That seems a poor decision to me, implementing that. Is there a workaround to go back?
Sure. Workaround is to just to revert the commit and go back to how it was. But given the fact it was implemented in the first place it made more sense to me to make the problematic behaviour optional rather than revert it as not all people will encounter the issue. For some 'true' client ip address logging may be more important, for others having source material close to the Comet server for performance reasons may be more important. It will depend on the server and user proximity.
@g0ldyy concurred with this being toggleable via config in Discord last week fwiw. The issue has been raised here more as placeholder to keep track of the issue than a new report.
EDIT: Sorry, just to avoid any ambiguity in my reply - If by 'is there a workaround to go back', you meant is there a way to revert present functionality to be the 'old behaviour' right now, then no. There is no way to prevent the client IP being sent to RD without a change to the code.
Sending the client IP to RD is desirable, under normal circumstances (at least, that's been my experience of users requests). I agree that make it optional for proxystreaming makes sense too.
Thinking about it maybe just something like the following might be a simple way to cover all bases with only one knob for admins to twiddle:
REALDEBRID_USE_SERVER_IP=never|always|proxy
never = current behaviour always = old behaviour proxy = pass true client ip for direct streams, pass server ip for proxied streams
I will just disable it completely for proxied streams.
fixed.
Due to public demand(?), commit 479aa8e527ebfeec01ffcde5c825b0a5af19538e changed Comet behaviour such that the streaming client IP was passed to Real Debrid instead the IP address of the Comet server itself.
A side effect of this is that in cases where
PROXY_DEBRID_STREAM
is used performance problems can occur if an end user is far-away from the Comet server and RD links get generated pointing to content local to the user, but a long distance from Comet for its proxying.e.g. consider a user in Australia using a Comet proxy in Europe - such a setup gives a Sydney-Europe-Australia roundtrip instead of just Europe-Australia. This can make playback unstable in poor peering scenarios.
It would be advantageous for Comet hosters to be able to choose whether to use the IP of the server so that debrid download links always point to content that is close to the Comet server, or the IP of the client for 'cleaner' RD logging.
An alternative approach might be to only pass the client IP for non-proxied traffic and pass the Comet IP for proxied streams, or a configuration option to enable/disable this behaviour.