#1
|
|||
|
|||
"Max. sim. Downloads per Hoster" should be based on Subdomains
Hi,
first of all thank you very much for JDownloader! It's such an outstanding tool! I just found out that JDownloader would distinguish Hosters based on the domain name / second-level domain name. This is probably fine in many scenarios but not in those scenarios where your download files are distributed on several subdomains of the domain name (like dl1.domain.name, dl2.domain.name, etc.). Now if there are independent servers behind each subdomain and each independent server doesn't have the best connection speed you cannot make use of your full available bandwith because JDownloader will maximum do 20 parallel downloads for all the subdomains together. I'd kindly ask for a feature which would extend the "Max. sim. Downloads per Hoster" by a "Max. sim. Downloads per Subdomain". Thank you anohymne |
#2
|
||||
|
||||
This makes only sense when you add generic http links manually and not download from *supported* sites with plugin support because only for generic links the final download url/domain is known.
I'm little confused because you're talking about *max downloads per hoster* and in the text you say "cannot make use of your full available bandwith because JDownloader will maximum do 20 parallel downloads for all the subdomains together" ?! By default JDownloader has global max limit of 20 concurrent downloads. So any change to domain vs subdomain won't help here when you already have 20 downloads running. Can you please provide example links?
__________________
JD-Dev & Server-Admin |
#3
|
|||
|
|||
In my case these are generic http links which I added to JDownloader myself. No specific file hosting services are concerned, no dlc containers.
Links look like this: **External links are only visible to Support Staff****External links are only visible to Support Staff**[xy] **External links are only visible to Support Staff****External links are only visible to Support Staff**[xy] **External links are only visible to Support Staff****External links are only visible to Support Staff**[xy] and so on I'd like to limit the concurrent downloads per subdomain, e.g. to 4 downloads per subdomain. Like this I could increase the overall bandwidth usage significantly since - like I already mentioned - each server would only offer a very limited download speed. I hope this explanation is clearer. Thanks |
#4
|
||||
|
||||
I will add support for this as soon as I find free time. Requires some internal changes
__________________
JD-Dev & Server-Admin |
#5
|
|||
|
|||
Thank you very much! I'm looking forward it! You will probably be the only one on the market to offer such a feature. I couldn't find it in any other tool. Your customer orientation is just great and since I'm not aware of any customers I will of course donate :-)
|
#6
|
||||
|
||||
Better wait for the feature to be implemented before you thank me
__________________
JD-Dev & Server-Admin |
#7
|
|||
|
|||
Alright, I'll do so ;D
|
#8
|
||||
|
||||
I know that this isn't quite the same issue, but touching on Jiaz comment that it can only work on generic DIRECTHTTP plugin... outside of that i did add support for this a version of xfs template that I altered heavily, which would achieve the same outcome for dedicated hoster plugins, but in a automated fashion... I did this as a work around (which worked in the old jd0.9 and v2) that dynamically altered max sim dls but plugin code. It used to start download, then tested to see if the connection could be utilised. this approach was taken due to not knowing if the user is connected to said server in an outside browser instance or download manager Or the user changed UI connection settings between downloads Or if the site provider even had the same connection settings for each server!. Most xfs sites use the httpd connection settings you have control over x chunks and total connections to server. If the user doesn't match the max chunk settings inline with this, then they can start another download but could possibly still fail due to trying to connect with say 4 chunks and only 2 available on total server connections if that makes sense. Problem is having to either manually define this within plugin code (think this is a bad approach myself) or let the core handle it and track it dynamically which i would prefer to see. Another unknown was the generated link subdomain/fileserver ip is only known after one starts premium download process or free download process (which typically means captchas and wait times) and you could get the same file server as previous which means no more connections available, in which the plugin used to -1 slot to prevent new downloads starting, when a download finishes it would retry that next in queue download which in this case had a cached generated link.
fun times raztoki
__________________
raztoki @ jDownloader reporter/developer http://svn.jdownloader.org/users/170 Don't fight the system, use it to your advantage. :] |
Thread Tools | |
Display Modes | |
|
|