Bug #63979

Need: Final multihoster controlling improvements

Added by pspzockerscene over 4 years ago. Updated over 4 years ago.

Status:ClosedStart date:03/21/2015
Priority:HighDue date:
Assignee:pspzockerscene% Done:


Target version:-


Hey guys
Our multihost implementation is already pretty good but there is one major design issue: It "gives up" too soon and this is because the list of the currently non working hosters is managed inside the plugin.
1. If we had that list (or similar) in the upper controlling, JD knew any time if a host is disabled and how long.
Example of how it is now:
Try MOCH download --> Fail (host "blacklisted for lets say 5 minutes ) --> Next candidate --> All (M)OCH premium candidates fail --> Eventually JD switches to free mode or "Account skipped" in the end dependion whether user uses an account usage rule or not
Handling with this improvement:
Try MOCH download --> Fail (host "blacklisted for lets say 5 minutes ) --> Next candidate --> All (M)OCH premium candidates fail --> JD can now see that e.g. the current host it wants to try it blacklisted on the multihost in 5 minutes so it can simply wait these 5 minutes and retry.
At this point JD can simply check on which MOCH the host has the fewest waittime --> Display this to the user and try this candidate next
This would satisfy a lot of users and we while we still not "bomb" APIs of multihosts.
Please implement it - raztoki and me will refactor the MOCH plugins then.

2. Some multihosts (at this point only 2) limit the number of max simultan downloads per host --> We can implement this inside the plugin but it would be better to have this in the controlling ;)
Current MOCHs which do this: offcloud.com, premium.to

2nd point = not that important - first point = very important!

Related issues

Related to Feature #3864: Grouping: Multihoster related bugs & features Closed 11/02/2011

Also available in: Atom PDF