(06-28-2017, 12:18 PM)'ZippyDSMlee' Wrote: [ -> ]File dates only come in handy when you have to restore the OS or just have to reinstall the torrent program fresh and restart all the torrents without restarting the data, so if they are staggered in last time modified list you can drag and drop them more easily.
OK, yeah, I can definitely see that, for manual file-management timestamps can be a big help in determining what's what. I definitely keep my torrent directories sorted by (decreasing) modification date in the file browser, so that the newest stuff is always right at the top. Vuze makes a point of ignoring them, though, because as you say dates can change and it has much more reliable methods of identifying and organizing file data.
Quote:There is no option I can find to disable the “bring vuze to front window” or “file move completed “ notification.
Really? I checked and all of the Interface > Alerts settings are even visible in Beginner settings mode, so they should be visible for you. I'd check (well,
un-check, if they are checked) the Popups section options "Popup an alert when a file is finished" and "Popup an alert when a download is finished".
If you're not running the latest release version (5.7.5.0, you can see what version you have installed by chosing Help > About Vuze, the title of the window that comes up will be "About <version number>") then you should update Vuze. The list of things that can be configured in Interface > Alerts has definitely grown over time.
In the version I'm running, there's another option, "Reduce situations where the main window is automatically shown" — you could try turning that on and see if it cuts down on the interruptions. I'm not exactly sure how recently that setting was added to Vuze, though. If you're running the latest Vuze and it's not there it may be a beta feature. If you're willing to help test it out, it you could install the beta version and see if that makes any difference. (The Help menu in recent release versions contains an entry to "Join Beta program...", which will update you to the latest 5.7.5.1_B10 beta version.)
Oh, one last possibility, the latest Vuze (5.7.5.0) added a setting to "Post message to notifications" for certain types of tags, to be shown either "on Addition" or "on Removal". If you've tried everything else and still having issues with Vuze interrupting other tasks, you could go into Tags Overview and make sure that none of your tags have any notifications switched on. The options is waay down at the bottom of the Settings view. Mostly this applies to Manual tags, not automatic Download State tags which don't allow notifications to be set. So if you don't have any manual tags configured it's unlikely to be an issue. However, there are a few Category tags like "All" and "Uncategorized", as well as automatically-created Manual tags like "Untagged", that do allow notifications to be set.
Quote:I dunno would it not be smart of the devs to just program it to scan all locations inputted and not just the single default cache? If you are highly organized have everything in separate folders a single folder is not going to help you any. Everything I have moved is moved by Vuze unless it’s a few torrents I am trying to restore since I have a few left over from UTorrent, even with the data in the right cache folder it does not always find it, just saying an option to scan input inputted folders plus cache folder then on completion move to completed folder deleting any extras in the process, boil it down its 2 check boxes and a line for folder locations. Can a plugin do a data check and move files then update their locations in vuze?
Well, nearly
anything is possible through a plugin, so I'd assume one could be written to do what it sounds like you're asking. And I certainly don't speak for the Vuze developers — I'm just Some Guy (who's been using Vuze extensively for over 10 years), and my opinion is just that. But regarding "would it not be smart of the devs...", my
opinion is that, no, it's actually very smart of them
not to do that.
Let me go off on a bit of a tangent a to tell you the
#TrueStory of my friend, who shall remain nameless because I'm too much of a pussy to call him out by name (though it'd be well-deserved), who we'll just refer to as The Disorganized Photographer or "Dis" for short. Dis liked to use Picasa to sort through and display the photos on his computer, imported from the memory cards in his various digital cameras. But Dis absolutely refused to be forced to
organize the photos on his computer, and wanted to be able to dump them absolutely anywhere... and still have them show up in Picasa. So, he made sure Picasa was configured to scan the
entire contents of
EVERY SINGLE DRIVE on his system. Its scanning locations were literally configured as
"C:\ ; F:\ ; G:\ ; H:\ ; N:\ ; O:\ ; R:\". (Yes, he really had 7 or more hard drives installed in the machine, each one tens/hundred of gigabytes, then eventually multiple terabytes, all of them packed to the gills with all manner of files (often multiple copies of the same files in different places), scattered randomly around in folders with informative names like "old hard drive" and "card dump" and "Desktop" and "New Folder (37)". ...Again, none of this is a joke. In fact I once found a folder
on his desktop that was called "Desktop", containing another folder called "Desktop"! There were digital camera photos inside
C:\Users\Dis\Desktop\Desktop\Desktop\, because of course there were.)
No matter how hard I tried, I could never impress upon Dis that
the reason why Picasa ran incredibly slow on his machine, took
days (literally DAYS) to scan for photos, often would fail to notice new ones until he forced it to do a full rescan (again, DAYS), and basically just worked very poorly in general (something he complained about loudly and often!), was entirely
his fault. He was sabotaging it with his insane configuration, and forcing it to work in a way it's not meant to, wasn't designed to handle, and would never NOT cause huge problems. Picasa's databases would grow to
hundreds of megabytes in size (data which all has to load each time it's run, and which has to be updated whenever photos are discovered or edited), and those monstrous databases were mostly stuffed with useless data it had to collect just so it could keep track of the files it
doesn't need to manage. Because not only does Picasa have to store data about all of the photos it's managing, but when it scans locations like
C:\Windows\ and
C:\Applications\ — to say nothing of
C:\Users\Dis\AppData\Local\Mozilla\Firefox\Profiles\whatever\cache2\ and the like — it stores information about
every single non-image file it finds, to record the fact that those files don't contain image data and don't need to be re-examined in the future. Same thing when you have it scanning folders full of hundreds of gigabytes of MP3 music and MP4 video files just because there might happen to be a few photos scattered in there with them.
File-scanning is an intensive process, far more intensive in a bittorrent client than in a photo manager. If you ever need to be convinced of that, just use "Search For Existing Files..." and watch how long it takes just to scan a single folder, even when the files there
are part of the torrent. Or, hell, just run a "Force Re-Check" on a big torrent. I have a slightly older machine with slow-ish hard drives, admittedly, but if Vuze has to re-check a huge 20- or 30-Gig torrent containing many
thousands of files, it's gonna take several
minutes before it gets to "Checking: 100%". And that's just to scan
one single location
when the files are all there!
Because scanning is so intensive, Vuze contains a
lot of code with the sole purpose of
avoiding it as much as possible, even for the files it
does have to deal with. It protects the same file from being part of multiple torrents (unless the user is crazy enough to switch that protection off), minimizing the chances of file corruption or contention which causes re-checking. It has Fast Resume mode which constantly records current activity, so if Vuze crashes, when it starts up again it can re-check only the pieces that were in use before the crash. It can be set up to keep configuration backups (even on a separate disk, for maximum protection), so that if the software or the OS does have to be reinstalled, the previous configuration can be restored and everything can be picked up right where it was before.
When torrent state does need to be re-generated from scratch, it has features to assist the user with that process. Save Path can be changed in the Open Torrent dialog, in case the torrent's files aren't located in the default spot. If that location already contains files, Vuze offers to scan the contents for existing pieces and incorporate those into the torrent. And as a last resort, "Search for Existing Files..." was recently developed to assist with the process of recovering partial data for incomplete torrents, no matter
where it's located or what form it's in. The response to that feature was extremely positive, because (as user SS said to summarize their own beta-testing of the feature) "Almost 200 dead torrents have seeds now."
But, an option that would have Vuze automatically do lots of extra file searching in multiple locations
every time a torrent is loaded, even though it's totally unnecessary except in those rare situations (they
are rare, right? Just how often do you find yourself reloading Vuze from scratch?) where Vuze is adding torrents with files already present on disk that it doesn't know about? Do I think it would be smart for the developers to add that?
I think you and my friend Dis would get along great.