Issue with rapidshare plugin

FreeRapid: 0.83u1
Rapidshare plugin: 1.0.17

When rapidshare website gives two error messages:
1) Currently a lot of users are downloading files.
2) Unfortunately right now our servers are overloaded and we have no more download slots left for non-members.

FRD stucks into an infinit loop to try downloading from rapidshare in spite of the "error attemps count" has been set to a limited number, i.e, 2.

It seems rapidshare's new free download policy is to assign different ip ranges in different time peorids. So it has to wait couple hours before this problem goes away. It's seriously blocking other download jobs. Plz check it out. Thx.

It's not a FRD problem. Their servers are simply overloaded. FRD is doing for you what you would do in the browser...

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





Edited 1 time(s). Last edit at 01/07/2010 08:27PM by Vity.

It is the problem how the plugin handles the error. In the option of FRD, there is option item "Error attemp count", if I understand correctly, it should be telling the plugin how many times it should try to connect and download before moving on. Now when the rapidshare website has problem, the plugin or FRD cann't handle it properly, just trapped into a deadly loop.

I believe that the plugin knows how many times it should try before moving to the next file in the queue, right?


Update:

Make a correction: it is NOT in a deadly loop, it just tried many times before giving up, it's just ignore the setting number of "Error Attemp count". While it does trap in a deadly loop for "Megaupload" plugin. I know this should be in another topic, but just wondering it is the plugin or the FRD should take care of the "Error Attemp count" option?



Edited 1 time(s). Last edit at 01/07/2010 11:28PM by splashgame.

Here's a technical explanation:

No, the plugins do not handle the error attempts count, it's FRD which does that.

But, plugins can throw numerous different errors, in this case it's either ServiceConnectionProblemException(...) or YouHaveToWaitExeption(...). The latter will get stuck in an infinite loop in case it doesn't get solved, as it's not counted as an error by FRD.