Uqload sources not working #411
Labels
No labels
MediaFlow Proxy
autorelease: pending
autorelease: tagged
bug
documentation
duplicate
enhancement
help wanted
invalid
question
wontfix
🇩🇪 German
🇫🇷 French
🇮🇳 Indian
🇸🇦 Arabic
🌐 Multi
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: Creepso/webstreamr-github#411
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Using mediaflow I get "Request time out" when if you go on the link via browser the links works good.
I think that this might happen because some domains block stremio request
On some movies(domains) I get "Video embed restricted for this domain" when I visit the link. This means they block requests from stremio.
you need to add more infos please. e.g. which instance, which movie/series and which link maybe. also checking your mediaflow proxy logs might be a good idea. in general referer headers are passed where needed, but this is all a bit fragile. mediaflow proxy seems a bit fragile as well...
Instance: Public by Hayduk(0.53.7)
Mediaflow: On
Movie: Caught Stealing
Problem: Request time out
Link: Working when you manualy go to the website and click play movie.
The timeout must be related to your mediaflow proxy somehow. Any details about it?
Public for me:
Private dev instance (new hosters):
Uqload seems to not play for me right now, that's a different issue though..
Or is the playback issue what you're saying? Timeout sounded like a specific error you see in logs or as result with errors on.
Where do you see "Request time out"?
I get "Request time out" with Show error checked on the addon configuration.
When I try to click the source it opens the page where the movie is hosted and I can play it, but not directly from stremio.
I have mediaflow deployed localy on my raspberrypi, with caddy as middle man which connects to my custom domain on goddady.
It work for other sources...
Strange, MFP might be too slow because it has to deal with other URLs. I seem yo even get that randomly on mine on oracle vps free tier.
Let's wait for when the release is deployed, in the mean time I would suggest to try checking if you see something your MFP logs
And I'd suggest to also unchecked languages you don't need :)
If all of this does not help, then I have to think about making MFP URL generation lazy potentially. It would return links then which will be resolved only when you open them basically. Downside is that I can't parse resolution from the playlist anymore which is useful in some cases. Upside will be way better performance
You can do that by adding an option to the addon and if people want performance vs resolution display can check the box.
I don't think is a MFP problem because filelions and other sources work well. Anyway I will try to have it checked.
2025-10-07 07:22:45,448 - httpx - INFO - HTTP Request: GET https://uqload.cx/abw pto4om1ez.html "HTTP/1.1 200 OK"
104.28.239.220:0 - "HEAD /extractor/video?host=Uqload&api_password=xxxxxxxxxxxxC&d=https%3A%2F%2Fuqload.cx%2Fabwpto4om1ez.html&h_referer=https%3A%2F%2Ffrembed. lat&redirect_stream=true HTTP/1.1" 302
2025-10-07 07:22:45,488 - httpx - INFO - HTTP Request: GET https://vidhidefast.c om/v/xz62s7qhsais "HTTP/1.1 301 Moved Permanently"
This is what appears on the mediaflow logs
301 and 302 error codes
I have mediaflow accessed via https. Is that a problem?
then maybe it does not return within the expected time. I raised the queue timeout a bit in the last release and I'll re-visit the mediaflow request related settings again. if it still does not work after the release I'll increase the timeout.
and your idea is a good one, I'll think about this in general and re-visit hosts using media-flow.
Looks like the public instance was updated. How does it behave now?
but anyway, you gave me some good ideas to optimise things, keep watching the releases / commits too, I think I can improve mediaflow proxy usage soon :)
uqload playback was also fixed in
298ac96558and I hope this time it will be really deployed fast..I installed the 0.54.1 release on the public instance and I can see that mixdrop is now fixed.
For uqload I still see the same error, maybe the public instance is not updated yet on the latest version.
If you can contact the guy and speedup the update process would be good.
Or tell me how to deploy it on vercel or google cloud so I can update and give you feedback in real time.
Also give me another way of contact for faster chat if you want.
Ok I updated the addon as I saw a new update on public instance but still I have same problem with uqload.
104.28.239.220:0 - "HEAD /extractor/video?host=Uqload&api_password=xxxxxxxxxxxx&d=https%3A%2F%2Fuqload.cx%2Fabwpto4om1ez.html&redirect_stream=true HTTP/1.1" 302
2025-10-07 14:36:45,599 - mediaflow_proxy.routes.extractor - INFO - Background cache refresh started for key: Uqload_{"host":"Uqload","destination":"https://uqload.cx/abwpto4om1ez.html","redirect_stream":true,"extra_params":{}}
2025-10-07 14:36:45,908 - httpx - INFO - HTTP Request: GET https://uqload.cx/abwpto4om1ez.html "HTTP/1.1 200 OK"
2025-10-07 14:36:45,918 - mediaflow_proxy.routes.extractor - INFO - Background cache refresh completed for key: Uqload_{"host":"Uqload","destination":"https://uqload.cx/abwpto4om1ez.html","redirect_stream":true,"extra_params":{}}
does public instance 0.54.2 include your fix?
Also what is strange is that when I go to the link of the website I can play it with another ip(changing it with vpn) but i cant play it even on the website when I am on my home ip. Maybe they blocked my home public ip?
For ex. on the Movie "The Lost Bus" I get the same error request time out and when I visit the website link This shows "Video embed restricted for this domain"
Still showing for me. Timeout is timeout. But I'm not willing to debug MFP, it seems to be too unreliable. I'm in the process of removing requests to MFP from webstreamr. You can play around again when that is done. Latest commits show some progress already
Yes the best option is to have that option that user can choose if want to make the request via MFP or directly for each individual source in this way one of the option will always work.
So in the case of uqload maybe the direct request might work(so no need for uqload).
Anyway if you fix it anyhow let me know...
There are planty of sources to watch so it's not a big problem but I see that Request time out even in source like filemoon depending on the film you choose. Anyway with uqload I didn't had any movie that worked at all. Instead mixdrop now works very well, vox also and all others.
If you have time plese check my other opened issue for an albanian site that uses voe if you can includ it as another source (AL = Albania country).
Thanks for the good work you do.
I was able for the first time to play a stream from uqload and not get request time out.
Movie: The Monkey 2025
Uqload from Frembed.
After the last update the uqload started to work more frequently...so it's around 80% working depending on the movie...
I think everything is more good now and I see that all the sources at least have one working result...
The only thing I see is the FileMoon brings to results per movie(one is working and one saying always request ID failed but when you visit the link the movie is ok and play).
Maybe I will open a new issue just for that after I check all the logs and bring back more results.
good to hear, the filemoon issues I also sometimes saw. in my cases they were always because filemoon detected a vpn or invalid IP range. it's a bit hard to confirm that, you'd have to do a manual curl on the system where mediaflow proxy runs and see what you get back. or it fails already on webstreamr site. I don't have a solution for that atm, it does not affect all filemoon links at least. and the webstream proxy/vpn situation is already a bit complicated tbh :/
Yes not all filemoons link are affected so it's a small thing. Thanks for your work. See you on other issues :)