Don't clear session cookies on transient 500 errors — only on 403 auth rejections#74
Don't clear session cookies on transient 500 errors — only on 403 auth rejections#74
Conversation
…sion jars Co-authored-by: paul-1 <6473457+paul-1@users.noreply.github.com>
|
There is an issue from something that caused a missing channel token. See the log |
The log in your comment was truncated — the comment system stopped parsing at what it interpreted as an XML closing tag in the log content (the message cuts off right after A few things that would help most:
In the meantime I've audited the new cookie-routing code and the path for |
|
@copilot Here is the continued log |
... The log is still being truncated at the same spot — the line after Could you share the log one of these ways instead?
The exact content of that DEBUG line (and any WARN/ERROR lines nearby) is what I need to identify the root cause. |
…e header and returned by server Co-authored-by: paul-1 <6473457+paul-1@users.noreply.github.com>
Thanks for the gist. The log made the issue clear. Root cause: Fix (commit Warning Firewall rules blocked me from connecting to one or more addresses (expand for details)I tried to connect to the following addresses, but was blocked by firewall rules:
If you need me to access, download, or install something from one of these locations, you can either:
|
|
@copilot Still more errors in cookie refreshes See the log here: https://gist.github.com/paul-1/d46eff6d699bd80d60c6e5a6692ee49d#file-sxm-proxy-log |
…cookies Co-authored-by: paul-1 <6473457+paul-1@users.noreply.github.com>
Three separate bugs identified and fixed in commit Bug 1 — Renewal feedback loop ( Bug 2 — SXMAKTOKEN permanently lost: The SiriusXM server never returns a new Fixes applied:
|
|
@copilot when trying to play different channels at the same time. There is something getting crossed in the cookies, forcing the renew authentication back and forth. See the log https://gist.github.com/paul-1/8429540d8ecfa32e7f81c6c802f82730#file-sxm-log |
…3 loops Co-authored-by: paul-1 <6473457+paul-1@users.noreply.github.com>
Root cause identified and fixed in commit Root cause —
Fix: Moved
|
|
@copilot SXMAKTOKEN does not even get refreshed at the global level, lets avoid the nusense warning. Note the global calls days apart(Happens when we refresh channel list data) and they show the same expired data. This cookie is only relevant at the channel cookie level. |
Co-authored-by: paul-1 <6473457+paul-1@users.noreply.github.com>
Fixed in commit
|
|
@copilot I tried to play sxm today after not using for a couple of days. There was a problem with playback, can you analyze the log. https://gist.github.com/paul-1/1ffe8ca195d08335a04985c7bc8c013b#file-sxm-log Do we need to correct something? |
…t_playlist, get_segment) Co-authored-by: paul-1 <6473457+paul-1@users.noreply.github.com>
Yes, there was a bug — fixed in commit What the log showed: At 15:40:56 the SiriusXM CDN returned a transient 500 on the background playlist refresh. The code then called Root cause: Fix: Warning Firewall rules blocked me from connecting to one or more addresses (expand for details)I tried to connect to the following addresses, but was blocked by firewall rules:
If you need me to access, download, or install something from one of these locations, you can either:
|
|
@copilot When starting sxm, I get this in the log. [15.03.2026 15:57:00.886] WARN SiriusXM::new: 484: Error loading cookies from /opt/slimserver/Cache/siriusxm/sxm.txt: Can't call method "cookie_jar" on an undefined value at /opt/slimserver/Cache/InstalledPlugins/Plugins/SiriusXM/Bin/sxm.pl line 561. |
…ialized Co-authored-by: paul-1 <6473457+paul-1@users.noreply.github.com>
Fixed in d15227f. The crash was an ordering bug in Fix: removed |
|
@copilot still seeing errors, these could be problems with the primary server, should this not have switched to try teh secondary server? |
…ver failover never triggered for playlist CDN errors Co-authored-by: paul-1 <6473457+paul-1@users.noreply.github.com>
... Your log is truncated again at the same spot — the That said, the code bug is clear from inspection alone and is fixed in The fix adds:
After 3 consecutive playlist CDN failures the proxy will now switch to the secondary server, same as it already did for segment failures. |
When
get_playlist()orget_segment()received a 500, the code triedauthenticate(). If that also returned 500 (server temporarily unreachable), it calledclear_all_cookies()thenlogin()— which also returned 500. This left the proxy with no cookies at all, permanently broken until manual recovery, even though the original session was still valid and the server outage was transient.Changes
get_playlistandget_segment:clear_all_cookies()+ fresh-login fallback is now gated on$status_code == 403only. A 500 after a failed re-auth logs a warning and returnsundef, preserving all cookies so the next request can resume automatically when the server recovers.Startup crash fix:
analyze_cookies()was called inside the cookie-loadingevalblock before$self->{ua}was initialized. Moved the call to after$self->{ua} = LWP::UserAgent->new(...)and wrapped it in its owneval.Server failover now triggered for playlist CDN failures:
get_playlist()was missingrecord_channel_failure()/record_channel_success()calls on the CDN playlist request. Repeated 500s from the primary CDN would never accumulate towardSERVER_FAILURE_THRESHOLDand the switch to the secondary server would never fire. Fixed to mirror the existing pattern inget_segment().Original prompt
This pull request was created from Copilot chat.
🔒 GitHub Advanced Security automatically protects Copilot coding agent pull requests. You can protect all pull requests by enabling Advanced Security for your repositories. Learn more about Advanced Security.