[BTPH]

So in a nutshell im trying to download content from a site. Their download links contain tokens that expire every two hours or so, meaning i cant just queue up the files and donload em one by one (as id prefer to do), ive already submitted a ticket for this issue, but in the meantime ive decided to do a little bit of a work around.

Essentially the links dont expire if theyre active, so ive been downloading 9 files at a time (which takes about 5-6 hours if downloads run at the max possible speed of my internet connection), i figure worst case i can download everything i need to this way, its a little tedious but not impossible. Ive been combining all 9 files into a package and just downloading them from there. Makes it easier to manage and to see how far along the overall download is.

The issue im having here is the ETA, specifically the ETA of the total overall package. The number isnt generated by the formula of (size-bytes loaded)/speed.

The ETA for each individual file in the package is generated this way, but the ETA for the total package itself is simply the longest eta of an individual package (which is far from accurate given im downloading 9 files at once, like if one file says ETA of 9 days based on its current speed, that will change drastically once one or two files finish downloading and more bandwidth is available for the longer download to use, reducing its ETA). I understand that there are times when this would be suitable (like if a package contains links from different hosts and some hosts are significantly slower than others), but in a lot of cases people simply arent using it that way. Is there a way we can have a secondary package ETA that just shows us Total kb remaining/total speed?


Bonus feature suggestion: would be super useful in these cases to be able to have 100+ active downloads running at a low speed, something like 10kbps just to keep the connection active. Meanwhile the first link (or first few links) are downloading at higher speeds. When one of them finishes the next link in the queue speeds up.

Not sure if its even possible to have so many active downloads, but would love a feature that does this for whatever the maximum number of possible active downloads is

[pspzockerscene]

Regarding the unreliable ETA:
I think this is a known issue but I was not able to find existing tickets which is why I created a new one.
Ticket:


Regarding more than 20 simultaneous downloads:

We have this limit for a reason:
A lot of users will simply turn all values up to the highest number possible without even knowing what they're doing.
E.g. 20 downloads * 20 connections = 400 connections in total - if many users do this this will stress servers a lot.

Now imagine we'd allow e.g. 100*100

-psp-

[Jiaz]

I've had this talk/discussion MANY MANY times before
"(FileSize - Downloaded Size) / Total file download speed" is a very *basic* view on more complex topic.

Internally there are many different calculations done.
One of it is the (Rest Size/Speed) calculation that you have in mind, but also it is important to take
the slowest download (longest eta) into consideration.

Easy example: two situations

2 Files (50MB and 150MB) loading at 1MB/s each file
-> Your calculation would return 100 secs ETA...
-> JD calculation returns 150 secs ETA

Now download A finished while B is still running, there are two possible outcomes

1.) B will continue to load at 1MB/s
-> Your calculation was wrong and the ETA will increase
-> JD calculation was correct and just counting down

2.) B will speed up to 2MB/s
-> Your calculation was correct and the ETA just counting down
-> JD calculation will adapt and the ETA will decrease and faster counting down

Your *easy* calculation with (Rest/Speed) does ONLY provide good ETA in case the assumption that you will always max out your download speed but that isn't the case in real world and heavily depends on many many factors like connection/ISP/free/premium.....
(rest/speed) may result on wrong ETA in meaning of that it may take longer than expected

JDownloader ETA calculation might also be wrong but instead of taking longer to finish, it may only result in faster download.
So JD returns the *best guess* at maximum ETA while (Rest/Speed) always returns the *earliest finish time*

I don't say that the current calculation is perfect but myself and many others prefer an ETA that is realistic than an ETA that increases over time.
I better know that it might 10 mins and it can be finished after 5, than waiting 5 mins and then realising it takes/took 10 mins in the end.

[Jiaz]

There is an open ticket about this. To let you choose between simple (size/speed) or current eta calculation

[Jiaz]

Originally Posted by BTPH

Bonus feature suggestion: would be super useful in these cases to be able to have 100+ active downloads running at a low speed, something like 10kbps just to keep the connection active. Meanwhile the first link (or first few links) are downloading at higher speeds. When one of them finishes the next link in the queue speeds up.

Not sure if its even possible to have so many active downloads, but would love a feature that does this for whatever the maximum number of possible active downloads is

You cannot tell a TCP connection at what speed to download. You can only limit receiving speed and TCP will cause sender site to throttle speed and later on increase speed again. Depending on server TCP settings this can also lead to overall slow when a slowed down connection no longer will get higher speeds. Also this doesn't work with connections that are already limited server side.