Queued... Whats happening. Still no answers

[Dan h]

rarely a reply if any on this issue. WTH is happening with queued files. We still have to either slaughter bandwidth by modifying concurrent downloads way above 4, or sit and wait as files finish to choose file names. Simple fix. sort it out!!!!! Been months!

[mig]

Do you realize you haven't given any details about the problem you are experiencing ? Hard to help here.

[anuhea55 00]

Dan h.....I'm still on FF56+ and VDH 6.3+ but have been following the threads on this site for VDH 7.1.+ .  The Queued issue is very important to me.  I download single Asian .mp4's..I have stacked over 20 at one time.  I've had 4 running together while the rest sat in the Que till one of the 4 completes....this process is beautiful and worked in 6.3.+.  In 7.1+, if you have to wait till one of the 4 completes before you can add 1, and then have to wait before adding another....that would be a bummer!!  How about the use of the Companion App 1.1+.  I understand that CoApp is a way VDH attempts to fix many of the FF57+ issues.  Does this provide a way to stack more than the limited number of files that and would allow an automatic "next file up." to start processing, and not have to wait till 1 of the 4 completes before choosing the next download.  You need to be able to just pack the Que with as many files as you want and have the Que process the next.  The Que feature is so important...at least for me along with many other issues..

[mig]

Assuming you are running the latest 7.1.2 version and process the downloads through the coapp (check VDH settings about that), you should not have any problem with queueing. It is set by default to 6 concurrent downloads but you can change that value.

[anuhea55 00]

mig...you are say that in 7.1.2 and coapp a queueing of at least 6 concurrent download.....but does that mean, say 6 downloads at one time.  Does this mean that if I have a 7-20 more that I want to single download that I have to wait till one of the 6 finishes.  I need to wait because the "save as" does not appear for the 7th download?  Now in 6.3+, you can pick and "save as" the 7th thru as many as you want and these 7- will wait in the Q till one of the 6 finishes.  The next one up will get processed and when another finishes, the next Queued file steps up.  With the old version, you did not have to wait till one of the 6 finishes before selecting the 7th.  If this is the case in 7.1+, even with the coapp, this is terrible.  I select a video, play in the view window, "save as" to a chosen folder by giving it a unique name, then I go back and select another file and go thru the same process.....sometimes as much as 20 or more without having to wait till one of the 6 finishes

[mig]

I am going to ask you to verify this issue again.

If you are running the latest public 7.1.2 version or development 7.1.3a3 AND use "coapp" as the download processor, whenever you request a "Download" operation, it should prompt you for the file name right away, no matter how many downloads are running or queued. If there are 6 files already downloading, it will queue the 7th one, which will start immediately when one of the 6 running ones completes.

[anuhea55 00]

Dan h....mig's answer should solve your problem.  You need the "coapp" to solve the multiple stack/queue download...just like we have with the old 6.3 (did not require coapp).  I've been reading many of the 7.1 posts for when I switch.  I will download the "coapp" too and believe many of my issues will be resolved.  Thanks MIG, I always hopped the "coapp" would do wonders!  Being able to "save as" into a remembered folder is also great.

[anuhea55 00]

Dan h....I finally switched to 7.1.2 and added coapp 1.1.3,   Chose the download processor = companion app.....and used Download instead of QuickD and I now get asked in a "SaveAs" tab the file and folder.  This Tab version is different than the previous Explorer window.  You get to select either a Tab/Window for the File Dialog (in settings).  I have Queued over 10 single .mp4 file downloads without having to wait till one of my 4 current downloads finish.  Plus, the previous folder name shows as default in the SaveAs Tab.  There is a small box to change folder or create new ones.

What I do notice that when you use Window, the pop-up SaveAs box is not as stable as when using the Tab.  When you attempt to change file names or changing dir, the pop-up occasionally closes .  The Tab box seems to be more stable and stays open.

Also, when using the coapp as processor, you now loose the ability to track the progress of the current downloads.  Since the working .part file no longer appears in the Save folder....only when download completes do I see the .mp4 appear.  If you were to choose the download processor=browser, you now can follow the progress under the small down pointing arrow (this tracks the current/past working file like the old version of 6.3.1).....however this arrow tracking method no longer functions when you change to companion.app.  Bummer!  So, is there another way to track the progress of a download with file size and names and how long before done like those under the thinner download arrow version??

[mig]

Yes, using VDH 7.1.2, coapp 1.1.3 and coapp as download processor is the way to go.

Another user reported the issue with the "dialog as popup" closing after 12 seconds. I haven't been able to reproduce the problem so far. If you are experiencing the same issue, it's better you stay with the default "dialog as tab" mode.

You can always monitor the progress of downloads, aggregations and conversions by opening the VDH main panel then selecting the "Running" section (the blue circle showing the number of actions in progress).

[anuhea55 00]

Thanks Mig...finally got around to loading both updates.  The SaveAs popup box does have some issues when you select the Window as the default instead of Tab.  When that window appears on  the screen, selecting a drive and maybe changing/creating a folder or even trying to change the name.....well I have gotten the pop-up window to just closes.  I have not tried leaving it just open without any changes.  This window is much different than that of Explorer, I guess you built your own.  The Explorer version of SaveAs appears when you choose Browser instead of CompanionApp.  Choosing Browser also provides for the old style thin downward pointing arrow that allows tracking (like in 6.3.1).  The issue with the "Running" blue circle, it does not show time remaining or size of downloads....you can get a feel from this how long the download will take, minutes or hours and even get a feel for the connect speed.  Knowing what is being downloaded, I guess, is better than nothing. Maybe you could add something to the "Running" blue button.  Choosing Browser also lets you see the processing files in the Saved folders, unlike CompanionApp downloads.  I was looking at VDH on Chrome...looks like 6.3.1 except for the download tabs on the bottom....no coapp?  I like your FF version with the coapp better...can stack many downloads and change/repeat folders....tough job you undertake.

[mig]

Did you click on the blue disk ? You should see both the remaining time and percentage for each download.

The Chrome version will soon been updated to match VDH 7.x, minus YouTube downloads which are not allowed on the Google platform.

[anuhea55 00]

Sorry Mig...my error.  After further investigation of the coapp version, I see the following:
   - the Running/BlueButton does indeed give the size, %, time left and status bar, however it shows the original name (not the saveAs name) and does not include the KB/sec speed (usefull for network evaluation).  When you switch from Coapp to Browser download, the new thin downpointing arrow (this may be from FF and not VDH) show both of these items...also because it is a pop-up, I can leave it posted on the screen.  I can leave the processes up with the Blue button.  This is much better than nothing.
   - when you change the "file dialog" to Window" from "Tab", the SaveAs pop-up box is very unstable.  Trying to change folders or trying to edit the saved names, causes the window to shut down.  I'm not sure if the "coapp idle exit timer of 60000msec could have something to do.  If you just leave the pop-up open with no change, 10sec it closes.  The Tab choice does work.  Not sure if Windows pop-up is intended to work better.  I will stay with Tab.
   - I do mostly single file downloads, by the dozens.  Is there any reason why I need to get the .part file created and not just the raw .mp4?  Both the Browser and Coapp methods create a .part.  The Browser version sends files to the SaveAs folder, while the Coapp version works somewhere else and only sends the file back after completion.  In the previous version 6.3.1, changing the "download retries=0, eliminated the .part with only the working .mp4 appearing in the SaveAs folder.  This allowed viewing the .mp4 before completion.  Now, there is no way to eliminate the .part, even for straight downloads with no conversions.
   - I have also starting using the AutoPin for completed file reference
Anyway, it's nice to see that progress is get made to this very useful tool.

[mig]

In a general way, if you get .part files while downloading with the coapp, this is because you picked a chunked stream. There is no way to play the file before it is completely downloaded because very important mp4 information is written at the end of the download.

[anuhea55 00]

I tried to uncheck the chunked stream with Coapp, but since I could not find the working dir, could not observe the .part.  I tried this using the Browser method, but still see the .part in the SaveAs folder...Will stick with Coapp for other now.  Too bad this does not work like before.

Also, the Windows SaveAs stability needs tweaking. and the Running/Blue is not too bad.  I liked the older downpointing arrow information.