View Single Post
  #8  
Old 05.05.2018, 10:18
dabrown dabrown is offline
Black Hole
 
Join Date: Jun 2015
Location: North America
Posts: 273
Default

The only way I've found to make mirror detection nearly foolproof is 1) set Mirror Detection Decision to FILENAME and 2) rename all the links in the package manually.

Otherwise, mirror detection breaks if JD changes the filename (even temporarily) due to it's lack of a default filename lock setting. When you change the link's filename manually, it always uses that. No glitchy temporary incorrect filenames that break the mirror detection.

Jiaz: I get that it's trying to find a trusted name, but when I dump a bunch of files in one package with the sole intent is that they are mirrors, I'd like them to stay mirrors. Not suddenly decide that one file isn't a mirror anymore if it got skipped or postponed due to a captcha timeout or a post-captcha wait time detection. If it was a package of mirrors when I moved the package from linkgrabber to the download list, I expect it to remain a mirror.

Here's a long rundown of what happens: Say I have 5 links. One from Rapidgator, one from Depositfiles, one from Fileboom, one from Filejoker, and one from Filefactory. They all ended up in the same package on link detect, with the name this_is_a_really_long_filename.zip. This name was what linkgrabber detected for all 5 files.

I have JD running unattended, so it skips the RG, DF, FB, and FJ ones in order due to unsolved captchas. It ends up downloading the FF one since no captcha was needed.

But instead of having a 100% complete package with one DL'd file marked "Finished" and the rest marked "Finished(Mirror)", I have one "Finished" file (FileFactory), 3 "Finished (Mirror)" links, and one that's "Skipped (Captcha Required)" (Fileboom). 4 of the 5 files still show the name to be this_is_a_really_long_filename.zip. Fileboom now is called this_is_a_really_...me.zip. So, when I hit Unskip, it tries to download that file AGAIN, and only when the download starts, it now complains that the file exists (and the name is changed BACK to this_is_a_really_long_filename.zip. Now I get a time penalty for the aborted download, since it initiated the download even though I had to tell it to skip the file due to being a duplicate. Of course, some times I catch that problem before (I see the skipped files in what should be a completed package) but with a download list of over 150,000 links and thousands of packages, sometimes I'll miss a couple.

As I said, I can avoid this by manually renaming every single "mirrored" link manually. But that's a real pain in the caboose (not to mention a waste of time) when the detected filename happens to be what I want the completed file to be called. I have to rename every link temporarily to something else, then back to the actual link, or I get the mirror mismanagement problem above.

There are literally only 2 use cases where I would ever want JD to rename the file from what was detected: when it didn't detect the filename at all (the name shows up as a partial URL of the link) or when downloading images from a gallery. Neither of which involve mirror handling. I realize that other users may prefer getting finalized archive filenames, but when I drop an archive into the download list, I expect that filename is what it is going to be on the hard drive when it's done.
Reply With Quote