uloz.to navazovani prerusenych stahovani (problem with resume download)

@tong2shot: you should work as an analyst , great work

-------------------------------------

thank you

please, how can I determine type of server of hosted file?
if it is [dl.sx.superhosting-cdn.p.uloz.to] or [dl.sxy.uloz.to] ?

if I see error with adress "dl.s1.uloz.to" - it seems as [dl.sxy.uloz.to] which support resuming :)

hamoun Wrote:
-------------------------------------------------------
> thank you
>
> please, how can I determine type of server of
> hosted file?
> if it is [dl.sx.superhosting-cdn.p.uloz.to] or [dl.sxy.uloz.to] ?

Please try plugin version 1.0.28. Then you can see which server hosts the file in FRD log.
It will appear like this :
WARNING: Final download link URI: [dl.sx.superhosting-cdn.p.uloz.to]
or
WARNING: Final download link URI: [dl.sxy.uloz.to]

You can also see the server using browser :
- In Firefox : in Downloads window, right click the file, choose "Copy Download Link", then paste somewhere (eg: notepad).
- In Opera : in Downloads tab, the server is in "From" field.
- In IE : emmm... well.. I don't know/don't remember how to do this in IE. I lost IE years ago


hamoun Wrote:
-------------------------------------------------------
> if I see error with adress "dl.s1.uloz.to" - it
> seems as [dl.sxy.uloz.to] which support resuming :)

From what I tested "dl.sxy.uloz.to" servers support resume and will resume just fine. But if you got "dl.s1.uloz.to failed to respond" then the server in question was not responding, the server was not sending response message at given time. Maybe the file had been (re)moved and the server choose not to send response message, or other reasons. But clearly this is also server problem, not FRD/plugin. Do you stil get "dl.sxy.uloz.to failed to respond" error message today ? I never receive such error message, I always got "File input stream is empty" (502 Bad gateway) when the files failed to resume in plugin version 1.0.27. Have you tried to download and resume the file using browser ?

I can only guess - as I am not familiar with uloz.to service, I only tested lately - that maybe uloz.to is in transition to use internal CDN (dl.sx.superhosting-cdn.p.uloz.to) for some files but have broken implementation in resume support, or maybe for some reasons they do that deliberately ? I don't know.

The only way to be sure is to contact uloz.to support about this resume problem.

try this link , donwload 10MB, stop and resume ..
you'll see this error

I'm using plugin 1.0.28

resume in chrome doesn't work too ...

log attached:
final link :) : [dl.s1.uloz.to]

This is what I got :
[dl.s1.superhosting-cdn.p.uloz.to]

Tested in Opera several times, always in CDN, I can download the file, but failed to resume.

From your log, it was served by [dl.s1.uloz.to] and couldn't resume, then I admit I was wrong. But still : you said it failed in Chrome too, then it's clearly server problem, just like I said in the last post. If it failed in browser then FRD can do nothing about it.

thank you very much for analysis

We have a setResumeSupported(boolean) method in HttpFile for these cases where the server lies about resume support, if you'd like to disable resume for problematic servers.

Thanks for the suggestion, ntoskrnl.

The problem is, it is not deterministic at least in [dl.sxy.uloz.to] servers case, from Hamoun's last log this kind of server couldn't resume, but from what I tested (different file), it resume just fine. Again from what I tested, when I got [dl.sx.superhosting-cdn.p.uloz.to], it is certain that this kind of server couldn't resume. But if I setResumeSupported(boolean) to false for this kind of server, then how will I know later when I regenerate the download URL, it is always hosted by same type of server ? This is dilemmatic. I consider to disable resume for [dl.sx.superhosting-cdn.p.uloz.to], but I need to do some tests first. The easiest way is to disable resume for all type of server, until uloz.to fix this problem, but I guess some users will disagree.



Edited 1 time(s). Last edit at 05/28/2012 10:19AM by tong2shot.