Skip to content

Comments

Fix rate limiting by reusing global session cookies#63

Open
uprightbass360 wants to merge 1 commit intopaul-1:mainfrom
uprightbass360:fix/reuse-global-session-cookies
Open

Fix rate limiting by reusing global session cookies#63
uprightbass360 wants to merge 1 commit intopaul-1:mainfrom
uprightbass360:fix/reuse-global-session-cookies

Conversation

@uprightbass360
Copy link

Summary

  • Per-channel cookie jars start empty, forcing a separate modify/authentication login call for each channel playback request
  • Rapid back-to-back logins trigger SiriusXM API rate limiting (HTTP 500), breaking both channel listing and stream playback
  • Fix: get_channel_cookie_jar() now always returns the global cookie jar so all channels share the single authenticated session from proxy startup

Problem

When a user browses SiriusXM channels and plays one, the proxy makes two login calls in quick succession (one global at startup, one per-channel for playback). SiriusXM's API returns 500 on the second call, and the proxy fails to serve the stream. Repeated restart attempts compound the rate limiting, sometimes blocking logins for several minutes.

Solution

Reuse the global cookie jar for all channel requests instead of creating isolated per-channel jars. The existing session-expiry and re-auth logic (codes 201/208) continues to handle token refreshes.

Test plan

  • Proxy starts and authenticates once globally
  • Channel listing loads without additional login calls
  • Channel playback works without triggering rate limits
  • Tested with live SiriusXM subscription streaming multiple channels

Per-channel cookie jars start empty, which forces a separate login API
call for each channel playback request. When a user browses channels
and then plays one, the rapid back-to-back login calls to the SiriusXM
API trigger server-side rate limiting (HTTP 500 on modify/authentication),
preventing both channel listing and stream playback from working.

This change makes get_channel_cookie_jar() always return the global
cookie jar, so all channel requests share the single authenticated
session established at proxy startup. The existing session-expiry and
re-authentication logic continues to handle token refreshes as needed.
@paul-1
Copy link
Owner

paul-1 commented Feb 16, 2026

The authentication cookies are infact long lived and common across all sessions, but are you sure sessionid's are not channel specific?

I've never seen rate limiting, except when I do a bunch of application restarts. Which is why I'm testing a branch that saves cookies and reloads them across application restarts.

Another question, are you running the plugin from a manual install from git, because the current state of the main branch is not the version that is on the Plugin Installer.

@uprightbass360
Copy link
Author

Hi Paul, apologies I didn't pull your working branch when I was debugging. I just made the fix and shot the pr using an automation. Its possible that there was an underlying change that addressed the issue in your current code but my observation was that the per-channel cookie jar was unnecessary and just led to tons of auth calls that led to my player failing to load and my account getting repeatedly rate limited. Great plugin though, I was listening all last night.

@paul-1
Copy link
Owner

paul-1 commented Feb 18, 2026

No need to apologize, if your running from a manual install from git. Look at the other open pull request, that is the final version I'm testing. But I'll look at what you proposed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants