The ultimate feature that will change torrent world forever

[skyrl]

The problem

For now, when end user wants to move a resource (eg. file) downloaded through µTorrent, he has to do it through context menu of uTorrent if he wants the torrent to remain seeded

But most of people just move the resource through windows explorer, therefore the source is lost and quite nobody knows how to reconnect it.

Why?

Half of users just download all their torrents to a same junk folder, the other half put up category folders where they store the downloads 
But after a week, a month or a year, 
Most of them eventualy moves the non-deleted content to another place : archive drives, subcategories, and then the seed is broken
Or Most of them rename the files or directories, and a big proportion of user delete the "junk" files (nfo/sample/...), and then the seed is broken

At that point, let's say one month after initial leech, 50% of the resources that has not been deleted is stored on their computer but not seeded. 
One year after the initial leech, probably 99%.

Quite nobody would have the patience and the know-how to reconnect the broken seeds to the new locations of their resources

Minor implementations

a/ For any currently seeded torrent, allow folder and file rename straight from windows explorer, then record the change to pinpoint the torrent resources to their new name and location

b/ Scan disk to find lost resources that have been renamed or moved somewhere else by end user ; reconnect those files to the currenty seeded torrents 

c/ Scan disk for orphaned .torrent, add them up to the uTorrent queue and apply (b) option to relocate the torrent file list to the resources found.
   Automaticaly re-fetch missing torrents from one or several trackers, according to µTorrent list of missing torrents (see tracker tab), or resume.dat

d/ Always and automaticaly seed uncomplete torrents, and 
    Auto-redownload missing little nfo/cover/sub/sample files, ie. if they've been deleted or found missing - when they represents less than 10% of the total size

Major implementation

1/ a process that scans your disk for big AVI/MKV/MP3/... files, query trackers with their size & MD5 to find & fetch torrents hold by the tracker that include this file(s)

2/ then with all minor implementation stuff : auto-download from one or several trackers all the related torrents and pinpoint them to the resources found on the disk

Since a same resource belongs to many different torrents among the same tracker or among several trackers, this allow to seed multiple torrents from only one root-resource

 

Implementing something like this into µTorrent would dramaticaly make the quantity of seeders explose all over the web, and would benefit all the community.

If there is any plugin that does this feature even partially, i'm interested in your recommandations.

 

Cheers

[DreadWingKnight]

And how exactly would uTorrent detect the move/change of the files?

[rafi]

I think using the context menu, or using the move-to after download feature (when it'll work well) is the only way...

[skyrl]

19 hours ago, DreadWingKnight said:

And how exactly would uTorrent detect the move/change of the files?

Something like that ?

http://stackoverflow.com/questions/5238962/is-it-possible-to-monitor-file-move-eventmove-file-from-a-folder-to-another-on

 

[skyrl]

19 hours ago, rafi said:

I think using the context menu, or using the move-to after download feature (when it'll work well) is the only way...

Yes, i figure so, and that's the big issue here.

Something i should have done in the first place : my own experience

1/ I download torrents from 4 different (private) trackers, using a fiber connection 6-8mb/s download, 1mb/s upload. On each of them i struggle to maintain a ratio between 1.5 and 2.5. Sometimes the files/distrib are the same from one tracker to another, but different torrents so i cannot add both trackers to µTorrent and serve multiple communities, thing i really feel sad about.  I'd love to reach 4-10 ratio (and i may) but i'm also urged to rearrange movies, music, documentaries to share them to my own community. after a few weeks 10% of my files have 10-20 ratio, 20% have a 2 ratio, 70% have 0 ratio (i download many rarities), but i have to move them to another drive/space and i don't have the patience to use the context menu. 

2/ I download directly to my personnal disk, then move them to the community NAS. When my ratio is too low, i try to copy them instead of moving them but that's awful because after a month i don't remember what i've moved or what i've copied, and then we end up with doubles... So i maintain lists, sometimes on paper, to remember what need to be deleted right away, since it has been copied already (the rest having to be moved). I cannot really pinpoint the downloads to the 8TB NAS directly since i'm not always connected to it, since it slows down the access for everybody currently playing movies from it, since it overloads my wifi connexion and therefore slows down browsing. Note that is a problem to download to the NAS at 5-8mb/s, but that would not be a problem to upload from the NAS at 1mb/s speed. But too bad, the 8TB of files stored in there are not linked to any torrent (way too fastidious, don't remember which tracker they came from originaly, many of them miss their nfo files...)

3/ I keep my own copy of 500gb of music I love and 500gb of movies i may watch during the road ; I download the files in a same "download" directory, then dispatch them every few weeks to the community and/or my personnal drive. I used to have different kind of directories (movies, unseen movies, thrillers, etc, music electro/rock/pop/etc.), but i was far from efficient since after discovering the movie/music i often have to move it anyway somewhere else where it really belongs, and in all the case i do rename them with a scheme like this :

music / genre / artist / [yyyy] album / artist - ## track name

movies / genre / [collection (like tetralogies..) / ] [!|^|§]#.# title [-keywords-] [language] \[year\] {°|+|++|+++|++++} / original torrent files

Conclusion : I only share about 10-20gb of resources while I could share about 1TB 100% of time, 8TB 75% of time...

If we are only 10% of users in my situation, we could change the world ... if the world gives us a simple solution to share what we already have...

ThX for your attention

[rafi]

the idea of having any app  track files on disk and correlated them to torrents - is unrealistic IMHO... I is not like a media played discovery... On the other hand, uT as a file manager - is pretty poor, especially when used for multiple torrents.

I think you best bet would be - if they'll improve the multi-selected torrents transfer (using the context menu), plus, find  some script utility that will be able  to do that for you controlling uT.

[skyrl]

On 11/3/2016 at 6:01 PM, rafi said:

the idea of having any app  track files on disk and correlated them to torrents - is unrealistic IMHO... I is not like a media played discovery... On the other hand, uT as a file manager - is pretty poor, especially when used for multiple torrents.

I think you best bet would be - if they'll improve the multi-selected torrents transfer (using the context menu), plus, find  some script utility that will be able  to do that for you controlling uT.

I don't think it's unrealistic to be developed with the WIN API i pointed up (see further).

But I think you're right : it may be unrealistic to hope that core µT developpers would 1/ read this post ; 2/ then realize the wide target of this idea.

They would see that feature as "oddity" related to my own personal user experience, and not see it at a common problem, widely met by the community.

They may miss my point especially if they are not the "collector" type of user but if they are used to put every file into the same directory and leave them here forever, or if they're used to select a directory/label/tag at the time of queuing and leave them here forever. But they would miss that "collector users", that always move & rename their downloads massively, are the ones having the biggest... collections !

 

To the second part of your answer, that's indeed a good hint - Some people did point some solution with scripts here, but :

1/ making those scripts work only talks to "elite" users. It misses the point of simple integration into µT, or having at least a simple plugin, usable by the masses. 

It makes of this idea a "geek" specific request for feature, while it is targeted to be a wide used feature improving the life, ratio and sharing philosophy for millions of users.

2/ seems very far fetch for my needs anyway, since the script is more adapted to massive bulk move/rename from source A to destination B - but in my case i have source A to multiple destination

 

19 hours ago, mozzy said:

This is very doable and a nice idea.

additionally; I dont think undownloaded files need to be completed, uT only needs to seed the finished files.

I do agree that is perfectly doable, it will not transform µT into media player to have minor implementation features, especialy :

• (a) track rename/move changes directly from explorer, and modify the location in µT queue & .torrent 
  Need to create a system event listener on each directory of queued file, then check if the moved/renamed file match one of the resource pointed in the queue list
  Need to bufferize all the reads from a source, and unlock the source file handler between each buffer read, to allow easy user file rename/move
  See those simple implementations of the API here : https://www.raymond.cc/blog/3-portable-tools-monitor-files-folders-changes/
   
• (b) scan disks for moved/renamed resources and reconnect them to µT queue & their original .torrent 
  This is really simple work i guess, recursive disk scanning is not that hard it's 101 of teaching programming
  Then program should match resource not by their name of course, but only by their size, then MD5 if there is a match.
  Recurse routine only need to calculate MD5 from disk, and compare them to original MD5 embedded in .torrent info.
  It is complementary of option (a) because it can allow reconnection of torrents moved through an external server, or made while µTorrent was shut down
  
  (a) either (b) as much as (a) and (b) can be implemented, both methods being as effective to meet the needs.
  
  (a) option would be more popular, intuitive, robust, transparent to user, and would allow to move file while they are seeded
  (b) option would be more "know-how" but would gain popularity rapidly among collection holders.

the (c) minor implementation feature, scan for missing torrents is quite easy to implement also

• update multiple entries of the queue with .torrent files found into a directory pointed by user
• scan disk for new location of a missing .torrent pointed in the queue
• go fetch on a tracker a missing torrent still pointed on queue
  seems this information is kept in the trackers tab, even when torrent is missing
  go check in resume.dat the missing .torrent information ?

But I do agree that the "major implementation" feature may be hard to achieve :
Seeking inside your own trackers' torrent lists the torrents that holds resources of same size and MD5 that the one µT found on your disk
Then download those torrents, point them to your resources location and instantly begin seeding !

• It would probably need to develop tricky way to interrogate a tracker through HTTP queries or magnet, or develop an API improvement to the announce/scrape methods, to query trackers to seek in all their torrent files for the size&MD5 of one their resources
  Then publicize this new API method among known-trackers. Many would implement it I think - it would not be greedy on the bandwidth, and despite the considerable CPU resource it may need for them, they would do it even with limitators (one query every X seconds) because having this query feature would provide them a lot of new seeders for their torrent list.
   
• Alternative method would be to use a third-party "bigdata" server : 1/ for all incoming µT new queuings, µT would send a simple query to the big server in order to associate a unique torrent hash to the many size&MD5 doblets of the files it contains, 2/ then allow anyone to query that big database with one size&MD5 doblet in order to be answered by the server with all the torrent hash codes that would contain that specific resource.  3/ Then µT could try to scrape each tracker on user list with the given hash codes.
  For confidentiality reasons, the database may not store tracker source address (neither IP's of the requests of course !).
  That way no user or private trackers would not oppose to its principle, and a user would be limited to his personal list of public and known-private trackers.
  Though, if a matching .torrent is not found on their favorite trackers, clever users could add multiple well-known public trackers to their list, and for totally desperate situations, very clever users could use the hash code given by the third-party server to do a google search and find semi-public trackers that owns the specific .torrent
   
• But here's the core part of this "revolutionary idea" ;-) : be able to seek into tracker lists for a specific resource, thus you'll be able to serve not one torrent with a same resource, but dozens of different torrents linking to same resource, at the same time, from same and different trackers.
  That will directly benefit to small and private trackers in order to easily keep sustained number of seeders even for rare/old torrents.
   
• Bonus : Those implementations would allow also to find resources from tracker "by association", ie finding other tracks of an album when you have only one, finding back the deleted .sub files of a DVD-RIP, finding missing dll of a package when you do have the .EXE...

concerning (d) seed torrent with missing "small" files, and redownload them :

• you're right, uTorrent can seed uncomplete torrents. It even seems it can seed file parts currently unfinished, while download is still processing.
  But, when a torrent marked "green" begins to be downloaded and a small resource is not found, then the torrent goes to gray "stopped 99.9%".
  Then I need to do a verify/force start. At that point µT will try to download the new files
   
• When you have hundreds of files in queue, I believe this process should be automated :
  if a torrent is broken the available torrent files should automaticaly be seeded neverless, and if it uncomplete because of "small files" (<10% of total size), an option should exist to order µTorrent to redownload the missing resources right away. This option is important also because it allows other clients to have themselves their downloads finished up to 100%. When they stag at 99.9% for days because you are the last one seeder with a missing nfo file, most of the users just end up deleting the torrent - they don't know 99% is enough
   
• Improvement : the small files should be placed at the same location of the main files (not inconvenient when they are stored into a specific folder, given in the torrent), but may optionaly be stored in a UserData/µTorrent/small_files folder if the user checks this option by default or when torrent is being queued into µT.

 

ThX for your attention and of course point me any missing implementation tricky issues i did not see