168734 - download queueing for download manager

Status: NEW

(Toolkit :: Downloads API, enhancement)

Description

[ratman]

i think this may be a dupe, but for the life of me i can't find it.

basically, users should have the ability to queue files for downloading.  when a
user downloads a file, the file should either be 
1) downloaded immediately,
2) queued for future download, or 
3) the user could be prompted as to which option is preferable.  
the prefs would naturally include a setting for which of the three would occur
upon download.  queueing essentially would delay the actual onset of the
download process to a future signalled time.

included in the preferences, and implicit in the use of a file queue, would be
the option of the maximum number of files to download at once when the queue is
initiated.  the download manager toolbar would consequently include a button to
start downloading the queue.  while the queue is running, further user downloads
would either be added to the end of the queue or would be downloaded immediately
"on top" of the queue.

the ability to reorder files in the queue could be a future extension of this
option, but would not be a requirement.

Comment 1

[ratman]

oops, forgot to add [rfe].  so sorry for the spam.

Comment 2

[Jo Hermans]

*** This bug has been marked as a duplicate of 151216 ***

Comment 3

[ratman]

this bug is not a duplicate of bug 151216.  that bug asks for requested
downloads to be downloaded one at a time.  this bug is about placing requested
downloads on a file queue for later download.  

i think a file queue would be more effective if the user is allowed to select
the maximum number of simultaneous downloads (as opposed to the maximum number
of total tcp connections).  technically, however, limiting the number of
simultaneous downloads (even if the limit is the current limit of 8) should not
be required to allow users to place download requests on a file queue.

Comment 4

[Daniel Wang]

*** Bug 143179 has been marked as a duplicate of this bug. ***

Comment 5

[Michael Gabriel]

dupe of bug 151216 / you decide which goes through

Comment 6

[ratman]

this bug and bug 151216 are *NOT* the same bug.  this bug can be fixed
independently of bug 151216.  please see comment #3 for more.  

Comment 7

[Jason Barnabe (np)]

*** Bug 229927 has been marked as a duplicate of this bug. ***

Comment 8

[pixolex]

And add a multiconnection option to accelerate download makinf fragments like
other download managers! 

Comment 9

[pixolex]

And add a multiconnection option to accelerate download makinf fragments like
other download managers! 

Comment 10

[OstGote!]

(In reply to comment #9)
> And add a multiconnection option to accelerate download makinf fragments like
> other download managers! 
That is Bug 75360.

Comment 11

[Chris Lewis]

I'd just like to throw my support behind a download queuer. I'm surprised noone
has made an extention for this already...

Comment 12

[Zbigniew Luszpinski]

Someone knows any about:config option to limit file download to 1 and queue the rest? Some servers just block/reset connection when you download few files in parallel. Sometimes it is faster to download file one by one.

I'm tired to have several tabs open and to remember what I need to click when one download finishes to start another.

Comment 13

[Zbigniew Luszpinski]

Any hope to have download queue in FF3.1? Downloading files 1 by 1 in queue (instead of parallel download like now) is very good thing because:
1) some servers do not allow multiple connections at a time, (so I'm kicked out when I select >1 file for download)
2) files are downloaded faster because connection bandwidth is not split to many downloads at a time, (so I get 1st file in queue immediately and can use it immediately when the next one begins to download).
3) More chances for successful download: if I browse the web and click for file download here and there FF immediately begins downloading all of them. If there are many files I want to have the total connection bandwidth is split and split to very small, slow pieces. This causes servers to disconnect due to slow transfers or no transfers at all. The result is that have zero successful downloads from working sites.

Comment 16

[Zex]

It's amazing that nobody cared to implement this feature since 2002. Or should I say fixing this flaw, because making all downloads simultaneous is a design flaw. Now it's 2014, that's 12 full years, and still waiting for the basic functionality to be implemented. Incredible lack of care about their users.

Comment 17

[Worcester12345]

Someone please just WONTFIX this bug, and be done with it.