Optimize stripchat.py performance with caching & improved request handling - #268
Optimize stripchat.py performance with caching & improved request handling#268medi0x1 wants to merge 22 commits into
Conversation
|
NameError: name '_mouflon_cache_filename' is not defined |
|
Run the program nd copy everything from |
Clean up code added during merge
Fixed the merge conflict bug. Please review nd let me knw if any changes needed |
|
Tested, working well |
|
File "C:\Users\OneDrive\Desktop\SC\StreaMonitor\Downloader.py", line 43, in how to solve this ?? |
Corrects the SC player script URL by removing a duplicated version prefix. mmpVersion already contains v, resulting in vv2.x.x/main.js → 404. Updated to v2.x.x/main.js so main.js loads properly.
You can fix the issue by removing the extra v since mmpVersion already contains it: - mmp_base = f"{mmp_origin}/v{mmp_version}"
+ mmp_base = f"{mmp_origin}/{mmp_version}"This corrects vv2.x.x → v2.x.x and resolves the 404. |
|
Error while trying to add a model from SCVR 2025-12-15 23:54:36,854 - INFO - manager_cli: Failed to add: StripChat.init() takes 2 positional arguments but 3 were given Same error from both cli and web frontend. Fixed by removing the roomid artifact in the stripchat_vr.py file and using the same as in your version of stripchat.py def init(self, username): instead of def init(self, username, room_id=None): |
|
INFO - manager_cli: Failed to add: Doppio.js not found |
same mistake |
|
Maybe |
It works correctly. Thanks |
|
@medi0x1 looks like they just changed something again :/ Traceback (most recent call last): If I remove every SC model the Downloader runs again and if I try to add a SC model I get "Failed to add features" error |
SC decided to rename their api fields nd broke everything lol changed `features` → `featureSettings` so it actually works now tested: doesn't crash anymore
|
updated, test if it works on ur side. |
Works perfectly again :) Thanks |
img.doppiocdn.com is dead for the player assets, they quietly moved everything to mmp.doppiocdn.com. Same version, different subdomain. - hardcoded origin was pointing to the old img. subdomain → 404 on main.js - updated MMPExternalSourceOrigin to mmp.doppiocdn.com one line fix, took longer to debug than to patch lol
|
Hardcoding |
|
adding stripchat works, but adding stripchatVR gives error:
|
|
i keep getting this when i add a SC streamer Exception in thread Thread-211 (execute): |
|
StripChat & StripChatVR dont seems to work any more lately, Im getting following error messages: |
Same. I temporarily fixed it by hardcoding |
|
crazy fixx , install curl-cffi: |
First thanks for your code,If the anchor does not exist, an error will be reported. I tried to remove it from the detection list and the error will no longer be reported: ERROR in getInitialData: HTTP Error 404: |
…MMP player version from homepage
## Problem
Stripchat removed both `featuresV2` and `mmpVersion` from their static
config API (`/api/front/v3/config/static`). This caused a hard crash on
startup with:
Exception: 'featuresV2' not found. Available keys: [...]
## Root Cause
`getInitialData()` relied on `static_data["featuresV2"]["playerModuleExternalLoading"]["mmpVersion"]`
to build the MMP player base URL. That entire key hierarchy no longer
exists in the API response.
## Solution
- Read `mmp_origin` from `featureSettings.MMPExternalUnitedSourceOrigin`
(still present in the API), with a known-good CDN URL as default.
- Auto-detect `mmp_version` by scraping the stripchat.com homepage for
the MMP script src URL pattern. Falls back to a hardcoded constant
`_MMP_FALLBACK_VERSION = "v2.6.0"` if scraping fails (e.g. rate limit,
geo-block).
- Added `_MMP_FALLBACK_VERSION` class constant for easy manual updates
when the player version changes in future.
## Files Changed
- `streamonitor/sites/stripchat.py`
## Testing
Verified the static config API response no longer contains `featuresV2`
or `mmpVersion`. Confirmed `v2.6.0` is the current MMP version via
DevTools network inspection on stripchat.com.
|
updated, test if it works on ur side :) |
Working, thank you 👏 |
|
Hi. I think the main flow stopped working, and its falling back to hardcoded mmp_version. Or Its just me? It works with this regex |
Stripchat killed `api/front/v2/models/username/{name}/cam` — 403 globally.
## What changed
- `getStatus()`: scrapes HTML page instead of calling dead API
- `getPlaylistVariants()`: uses `StripChat._get_session()` for HLS CDN cookies
## Why it works
- Model page HTML has `modelId` and `status` embedded
- HLS CDN still uses `edge-hls.doppiocdn.com/hls/{modelId}/master/{modelId}_auto.m3u8`
- Existing MOUFLON decoder handles encryption
|
Stripchat silently killed their v2 API. Models were all showing "Unknown error" because every request returned 403. This PR scrapes the model's HTML page directly all the data (modelId, status, stream info) is embedded there. The HLS CDN URL format hasn't changed, just the way we get the stream ID. Tested working: status detection for public/private/offline, recording via ffmpeg with MOUFLON decode. |
There was a problem hiding this comment.
This is not true at all, the API works just fine, 403 just means forbidden because CloudFlare is detecting you as a bot.
This is due to the script using Python requests which is very easily detectable as a bot/script.
You can easily test this by just printing the response you're getting in the script, which will give you a CloudFlare page instead of the API response.
You can also easily test that the API is working just fine if you open the API in a normal browser, which gives you a proper JSON back with no issues.
The solution is not to use HTML scraping, but instead to switch curl_cffi to properly impersonate a browser and the API will work just fine inside the script, just like it does in your normal browser.
(It took me three lines of code to fix this in my local copy, so I'm sure your AI can do it.)
EDIT: Sorry, GitHub didn't give me the history at first, only the updated PR with only the latest comment 🤦
But I still think it's true that the API works just fine with curl, no..? Does here at least, but they could of course be updating their backend in stages. What body response are you getting from the curl when fetching the API (besides 403)..?
|
API working fine for me too |
|
Just tested curl_cffi with impersonate='chrome' still 403. The v2 API returns Cloudflare block page regardless of TLS fingerprint, at least from some regions/IPs. So even if the API technically works somewhere, it's not universally accessible. HTML scraping works everywhere the model page loads. Both approaches can coexist the API call with curl_cffi as primary, HTML scrape as fallback. For now, this PR fixes the immediate issue. If someone's region can reach the API with curl_cffi, they can submit a follow-up PR. EDIT: Just tested through a VPN in a different region and it works fine. Reverting to API-based approach with curl_cffi cleaner and more reliable than HTML scraping. PR updated. Good catch on the TLS impersonation, was a Cloudflare IP reputation issue on my end, not the API itself. |
|
now im getting 403 errors, am I the only one? |
|
did they change api behavior? # (returns user-id)
https://es.stripchat.com/api/front/users/user-ids/{username}
# (returns streamer info)
https://es.stripchat.com/api/front/v2/broadcasts/{user-id}?uniq=2grpk8f3t4ojmu59 |




Summary
This PR optimizes stripchat.py implementation to improve performance & reduce resource usage. The changes focus on reducing redundant computations, improving network efficiency, nd adding better fallback mechanisms.
Changes
Performance Improvements
Added LRU caching for frequently computed operations:
Pre-compiled regex patterns at class level instead of compiling on every use
Optimized string operations:
Improved network handling:
Better memory usage:
Robustness Improvements
Multiple fallback patterns for finding doppio.js file:
require()pattern and new chunk-based patternAutomatic proxy support from environment variables (HTTP_PROXY, HTTPS_PROXY)
Improved error handling with proper exception catching
Code Quality
Performance Impact
Testing shows significant improvements:
Compatibility
Testing
Related
This builds on the improvements from PR #263 and PR #264 by combining their approaches with additional optimizations.