Forget to mention:
Browser used: Google Chrome v72
OS: Mac OS Mojave 10.14.5

6.4.0 build 1805 is released.

geralt2b wrote:Why cant i use the youtube function to get a 4k version link?
It up to 2K in most case. But I can use youtube-dl to get a 4k version link.
I hope I just miss setting out?

Hello,
Fixed. Thanks for the report!
By the way, currently it's not in the top of the list, you have to choose it manually somewhere in the middle of the list.

It used to be on Windows that you could send multiple download request to Free Download Manager and then click on them one after the other setting the appropriate directory for each.

Currently if multiple are sent then when the final one is clicked on the others are lost. Can this capability be restored?

Bryan Z wrote:It used to be on Windows that you could send multiple download request to Free Download Manager and then click on them one after the other setting the appropriate directory for each.

Currently if multiple are sent then when the final one is clicked on the others are lost. Can this capability be restored?

This. I've had numerous issues with this in that the first DL is caught by FDM, but the second defaults to my browser, and subsequent are not caught by the FDM or browser. They really do disappear as Bryan said.

I'm still on 6.3 though - I'll give 6.4 a shot and see if it persists like that.

Bryan Z wrote:It used to be on Windows that you could send multiple download request to Free Download Manager and then click on them one after the other setting the appropriate directory for each.

Currently if multiple are sent then when the final one is clicked on the others are lost. Can this capability be restored?

Hello,
This is a bug. Thanks for the report!

Something odd happens for me - and I've noticed this before, but don't remember if I made a big report.

Downloading Gentoo Linux files from the Oregon State University Open Source Lab (basically their FTP mirror for Gentoo) at https://gentoo.osuosl.org/releases/amd6 ... /hardened/ ) and something strange happens.

In that list, if you pick any of the .ISO related files, FDM parses the name exactly as you see there. But if you pick any of the .tar.xz files, the ones ending with .tar.xz come out fine - but all of the others (.CONTENTS, .DIGESTS, and .DIGESTS.asc) end up with a .xz appended to them.

See this image for clarification:



The file I tried to DL that time was the stage3-amd64-hardened-20190814T214502Z.tar.xz.CONTENTS and as you can see in the FDM popup dialog, it appended .xz

Windows 10 Pro X64 1903
FDM Beta version 6.4.1805 (fba80b3)
Browsers tested:
Firefox Nightly (currently at 70.0a1 (2019-08-17) (64-bit)) (tested on 2 different profiles)
Google Chrome Version 76.0.3809.100 (Official Build) (64-bit) (3 different profiles)
Microsoft Edge (Chromium) Version 78.0.249.0 (Official build) canary (64-bit)

Reproducible 100% of the time with any of those browsers, any profile (including a brand new one in Nightly).

FWIW, I'm using the context menu to select the file manually for FDM to DL (to preserve server time / date of the files).

johnlgalt wrote:Something odd happens for me - and I've noticed this before, but don't remember if I made a big report.
(...)
The file I tried to DL that time was the stage3-amd64-hardened-20190814T214502Z.tar.xz.CONTENTS and as you can see in the FDM popup dialog, it appended .xz

It's all OK on the FDM side. It's just some server admin which forgot to set MIME type for those text files. You can check download logs - the server passes "Content-Type: application/x-xz", which is obviously improper for CONTENTS listing.

On the other side, If MIME type was set properly, the file on click would be opened in the browser…

However, FDM for Linux/Android should have option to keep filenames unchanged, without adding MIME type (extension) passed in "Content-Type" HTTP header field.

johnlgalt wrote:FWIW, I'm using the context menu to select the file manually for FDM to DL (to preserve server time / date of the files).

What is wrong with normal click - FDM grabs files from the browser cache without checking timestamps on server or what?

johnlgalt wrote:But if you pick any of the .tar.xz files, the ones ending with .tar.xz come out fine - but all of the others (.CONTENTS, .DIGESTS, and .DIGESTS.asc) end up with a .xz appended to them.

Hello,
Thanks for the report! This will be fixed in the next update.

Usher wrote:It's all OK on the FDM side. It's just some server admin which forgot to set MIME type for those text files. You can check download logs - the server passes "Content-Type: application/x-xz", which is obviously improper for CONTENTS listing.

On the other side, If MIME type was set properly, the file on click would be opened in the browser…

However, FDM for Linux/Android should have option to keep filenames unchanged, without adding MIME type (extension) passed in "Content-Type" HTTP header field.

Ahh, didn't think about the MIME type because the browser downloads it with the correct name.

Usher wrote:What is wrong with normal click - FDM grabs files from the browser cache without checking timestamps on server or what?

No, if I click normally on .CONTENTS / . DIGESTS / .DIGESTS.asc the browsres attempt to DL them directly - but obviously they then have the current DATETIME values.

johnlgalt wrote:if I click normally on .CONTENTS / . DIGESTS / .DIGESTS.asc the browsres attempt to DL them directly

The browser starts downloading because MIME type passed by the server isn't registered in the browser database.
However, in order to force downloading, MIME type should be set to universal application/octet-stream value rather than to any type which can be associated with some specific extension (here xz compressed file) or application (xz utils, peazip or other archiver).

6.4 build 1819 is released.

Usher wrote:

johnlgalt wrote:if I click normally on .CONTENTS / . DIGESTS / .DIGESTS.asc the browsres attempt to DL them directly

The browser starts downloading because MIME type passed by the server isn't registered in the browser database.
However, in order to force downloading, MIME type should be set to universal application/octet-stream value rather than to any type which can be associated with some specific extension (here xz compressed file) or application (xz utils, peazip or other archiver).

That makes sense. And it explains why this happened across different browsers as well. Thanks, Usher.

Alex wrote:6.4 build 1819 is released.

Downloading it now.

johnlgalt wrote:

Alex wrote:6.4 build 1819 is released.

Downloading it now.

Have you noticed that FDM for Linux is BETA? See the screenshot:

Alex wrote:

Bryan Z wrote:It used to be on Windows that you could send multiple download request to Free Download Manager and then click on them one after the other setting the appropriate directory for each.

Currently if multiple are sent then when the final one is clicked on the others are lost. Can this capability be restored?

Hello,
This is a bug. Thanks for the report!

Well, now it doesn't throw the N+1 DLs at the browser, it catches them - but any previously undownloaded item disappears, so you can only DL the last one.

Windows 10 x64 Pro Insider Preview build 18963
Firefox nightly (currently 70.0a1 (2019-08-20) (64-bit))
FDM v6.4.0 [build 1819, Aug 19, 2019] ßeta