Discussion Thread
Last edited:
user and i have problems downloading files on ddl
they are shown as online but either get a timeout or you are redirected to a strange page after a short time
i don't understand how ddl can have such problems again and again when you compare other hosters who never have such problems
Some users are now complaining that they are getting the error 500 for some parts. I have checked this and the files cannot actually be downloaded (although they are displayed as online).
I would reupload them, but as the API shows them as online, I am unable to do so or I always have to respond to messages.
Can you fix this problem - which happens from time to time - so that the API also shows them as offline?
I think this is (also) a general problem with XFilesharing Pro.
That would be great.
Thank you.
there is oneDownload [MGS] Doki Doki Precure Movie 720p [614C5A2D] part3 rar
Download File [MGS] Doki Doki Precure Movie 720p [614C5A2D] part3 rarddownload.com
All reported parts (so far) affect servers: www506.ucdn.toPlease always send some example URLs. So i can check further.
And locate the Server which is causing this.
All reported parts (so far) affect servers: www506.ucdn.to
It affects different releases that were uploaded at different times.
However, I don't want to rule out the possibility that it doesn't affect other servers as well.
The download page for some of these parts is also very slow to load.
Download page of this marked parts remains slow (but not always).While opening the link, i have also first time noticed a slow loading download page. Which is really interesting.
Im checking if third-party script or something related is causing the slow loading. Currently not found the cause.
Now it is loading fast.
The Server is back again btw. Servers like this when something is stuck, or the filesystem is disappearing our monitoring is not reporting.
So we are happy if someone reports that there is an ERROR 500 and we need to reboot server and see the cause.
Download page of this marked parts remains slow (but not always).
However, the parts can be loaded again, albeit very slowly (~25-700kbs/s).
I'll let you know if I find more servers.
Nevertheless, the API should definitely (!) report such files as offline or at least as faulty. Then you can decide for yourself whether to re-upload them or wait. It would also improve monitoring for you.
You probably don't even notice this and only find out about our users who then complain :P
But that's exactly what the API should notice. If a file cannot be downloaded, the API must also know this. In this case, it doesn't really matter what exactly the problem is. Whether it is the OS, filesystem or the hardware - the file cannot be downloaded.As I mentioned, we always receive a report when a storage goes offline, but we don't get notified about those frustrating, unique errors related to the OS or filesystem. These occur when the server appears reachable but is actually not accessible. :D
But that's exactly what the API should notice. If a file cannot be downloaded, the API must also know this. In this case, it doesn't really matter what exactly the problem is. Whether it is the OS, filesystem or the hardware - the file cannot be downloaded.
Optimal case:
API checks file -> file accessible -> online
API checks file -> file not accessible (no matter why) -> offline
In this particular process, however, the API does not do exactly that. Please really check this.
If a file throws an error 500, the API should also receive it. Then, if you are really cool, you could even show that the part is there but cannot be downloaded (then I can decide for myself whether to wait or re-upload it). If you also get such errors displayed (and can then react), then it will be good
I have (fortunately) not been able to find any other servers so far.
That sounds great.We will implement the solution. We got the communication about it now. I will give more informations next week.