jbebad

Better error handling on the client side would be a big step forward on reduction of traffic. There are several cases where the retry timer shoulld not be set and the tracker disabled: 1. The tracker does not exist (http error 404?). 2. The tracker is not authorized for that specific torrent. (This may be not from a user adding a specific tracker to the list, but rather the tracker removing it torrent because of copyright issues.) 3. The tracker is private and the user is not authorized to use that tracker. There are very old torrents out there that are still in demand, but (some) trackers inside the torrent no longer exist, or changed their port, changed or added a new protocol - such as udp.). I cannot see how uTorrent (or any client) can handle this unless there was a site that maintained a list of valid and current trackers (perhaps like DHT). Then the list of trackers within a torrent would not be necessary. Creators of a torrent would not be adding old tracker addresses, (Of course all you would need to do to stop sharing is to kill that site - that would only leave DHT.) Until there is a method to insure a valid list of trackers the user must be able to edit/correct the list. So I would like to see better error handling on the client side. The elimination of duplicate tracker entries. But the user is still able to add trackers - there are to many old torrents out there that are still in demand that do not have valid trackers and are not DHT enabled.

Deathstalker: The article does not say what the specific proposal is. Is it to remove the cability of adding trackers to a torrent list? What about when creating a torrent? Is it to check the list to insure that the client does not allow the adding of an http: tracker entry for their specific site? What about programs outside the torrent client that allow the user to edit torrent? Is it to provide better handling of errors from the tracker? If I get errors concerning a tracker I remove it (depending on the error). "overloaded with bogus announcements". I fail to see how the announcements are "bogus" - in a general sense. I can see the point that a request for peers for a torrent that is not in their database can be considered bogus. But that may not have been the intent of the torrent creator. What is the error ratio of valid to bogus requests? BitTorrent may feel it is not their responsibilty to clean up torrents that are loaded by replacing a specific url with another. It surely would slow the loading of a torrent into a client - and as more trackers change their url - slower again. I do know a site several months ago that posted they were reducing the number of tracker url(s) to a single url. I did not see them recommend that clients be modified to automatically make that change.

Meddio - sorry I did not read the full message.

The name field in the Add dialog box should never be blank. It also should never be used to create a sub-folder for the path in a multifile torrent. Use the Save In to create your sub-folder. The Name field should only be used for the Name of the torrent and the physical filename for a single file torrent or a multifile torrent with a single file. The Name field should never be blank. For me, having the name field used as part of the path to create a sub-directory is convenent. But I can see where a person would want to store all of the episodes of a television show (regardless of the seasons) in a single sub-folder. The name of the file with the tag of S01E01, S02E02, etc. would be enough for them to keep the shows in order. Therefor the Name of the torrent would reflect the contents of the torrent NOT the sub-folder where the files are located. The only way to accomplish this is NOT to use the Name field in the Add dialog box as a sub-folder when adding the torrent and when using Set Download Location. (There may/must be an exception for those who put the torrent in an auto-load folder and start when added enabled. Without a new sub-folder when loading multiple torrents into the auto-load folder you could/would have torrents steping on top of each other. Some trackers put text files in the torrent "Download from xxx". You would get an error "File in use xxxx".) Just a thought

Registered: How does uTorrent know you moved them/it manually? uTorrent cannot simply go by the name of the file, nor its size or file type. Any file can have any name. uTorrent cannot know if you have downloaded multiple torrents that include the same subject file, same size, but perhaps with a different codec or frame rate, etc. And if you now point to a different location - to what uTorrent thinks is a new file - uTorrent must do a re-check. If you want to move files - move them within uTorrent then you do not need to do a re-check.

I do not know about incomplete design, but incomplete implementation - yeah.

Ok. I would like to give an example why the Name field should not be appended (or at least only be append when the user enters/appends a "\" to the SaveIn path. Using television shows as an example: 1. There are cases where the entire show is in one torrent. Generally in this case you would want to use the name the show as the name of the torrent. You have two methods: a. You can select a root directory and since uTorrent appends the Name, uTorrent will create the sub-directory for you. The problem with that is you generally must modifiy each filename within a multifile torrent to follow your own naming convention/standard and will be forced to create the sub-directory anyway prior to start so you can perform the relocate command. Appending it by entering a "\" (or always appending the name) does not really solve anything (the directory/sub-folder is not created until the start of the download and only works if you are not going to make any changes/relocate any of the physical files (name/location/etc.) b. The Name field is NOT appended to the Save In Path. You can create the sub-directory when you select the folder. All additional sub-folders are created at that point (assuming you did not need to make any changes/relocate of files). This works well for a completed series or single season. But it also works for those cases when for example you have a series that covers 6 years. You find a torrent that has the first 3 seasons, another torrent that has the 4th season, and a third torrent that has season 5 and 6. The Name of the torrent would be something like <show name> - Season 1-3, <show name> - Season 4, and <show name> - Season 5-6. Now if you append the Name field to the Save As Path (even in Set Download Location), then it push the data farther down the path. What you would like is a root directory <show name> sub folder <show name> - Season 1 sub folder <show name> - Season 2 sub folder <show name> - Season 3 sub folder <show name> - Season 4 sub folder <show name> - Season 5 sub folder <show name> - Season 6 Not <show name> sub folder <show name> - Season 1-3 sub folder <show name> - Season 1 sub folder <show name> - Season 2 sub folder <show name> - Season 3 sub folder <show name> - Season 4 sub folder <show name> - Season 5-6 sub folder <show name> - Season 5 sub folder <show name> - Season 6 What you (I am) are forced to do is change the name in the previous example to <show name> for all three torrents. Do a Set Download Location to point to the correct folder <show name>. Then rename the torrent back to something meaningful <show name> - Season 1-3. The appending of the Name field to the path causes extra work. (And at best case should only be done when the user enters "\" to the Save In path string.) I do realize that you can have a torrent pointing to a path that you are NOT going to use simply relocate every file up a folder level. Then the file names can get very long because they must have the full directory path and cannot take advantage of the Save As in the Torrent contents. Ok. I am out of breath. (I know some are saying/thinking Thank God. )

I am going for the record. My 3rd magnet with RC7: 10m 9s to download the metadata with 209 Seeders and 231 leechers. Boy I love this stuff. This is getting confusing. A magnet I download, loaded the metadata, started the torrent, and downloaded some data (files where created, some of the files were marked green with pieces download, etc.). I decided the following: 1. I made a mistake downloading that magnet. I really did not want it, but another one. Anyway that Torrent did not have a seq #. So I downloaded another magnet, That is the one I wated 10m 9s to get. So I renamed the new torrent, and decided to delete the previous one. (Remember neither of these last two had a seq. #.) So I stopped first one. Hit the Remove and Delete Torrent. Now while I am performing a relocate files on the last (magnet turned) torrent, I look up and see a seq. # for it. So when did that happen? I do not know. It must be in a separate thread and finally caught up. And yes it was placed at the top of the list and No I did not check the box to place it there.

Ok. I tried a magnet in RC7. I followed the same steps above (my previous post). I modified the Name field to conform to my standard. Once the torrent was downloaded I hit OK. The torrent is still placed at the top of the queue without a seq. #. The Name field is modified to the name in the torrent - replacing what I entered. In this case, the original magnet name was all lower case. I modified to my standard. The site had same name as the magnet but upper and lower case. The Name field was then replaced with the name inside of the torrent. The Save As path on the Info tab did NOT include the Name I entered, nor the name from the Torrent. I then used Set Download Location to correct the path (this is a multifile torrent). Although the Save As did point to a valid directory, when I opened the Select Folder dialog box, it opened at the root directory of the drive - ignoring the current path in Save As (Info Tab). The Set Download location works correctly(?) by appending the Name to the folder to create a sub-folder. (I would rather have created the sub-folder in the Select Folder dialog box myself and therefor would not want the name appended to the Save As path. The reason is, if the path does not exist and you want to do a relocate on the files (rename them to conform to your standard) then uTorrent will open the last directory it opened that was valid. Which can be on another drive, under a complete different parent directory, etc., you must go back to the torrents root directory, create the subdirectory - which will be usually the same as the Name of the torrent and save the file under its new (or existing) name.) I hope all that was not too confusing. Elapsed time 2m 26 sec for uTorrent to get the metadata (with 8 seeders, 18 leechers). Time flys when you are having fun. PS. rafti: No, I did not have that box checked. I also have 117 other torrents in the queue and they were pushed down the list. (Now 118 counting that first magnet.) The only thing I change on the Add dialog box is the Save In and the Name fields. Oh, boy. I misspoke with RC7. It did not push it down the list like RC6. It still has a blank #. Sorry.

rafti: I am using RC6 - and need to try RC7. But I just loaded a magnet. I then changed the Name field to conform to my standard. I then saw the spinning arrows - which seems to mean - getting metadata - and decided to wait. After about a min. (I was not watching the clock), I noticed the metadata downloaded. The Name Field was still the name I typed in. I hit the ok button. And low and behold, The torrent was listed. It is listed in the Downloading category at the top of the list (since I have the list sorted by #) - BUT without a Seq #. The Name was changed - NOT to the name I received when I initially loaded the magnet, but a completely different string without all the extranious stuff (HDTV, xvid, mp3, etc) in the title and closer to my naming convention. So the name magnet and the name in the torrent have a very loose relationship - if any at all. And if it is supposed to have one - be the same - then it is not enforced. There is another bug/feature that I saw concerning magnets and the download location - but I was caught up in the Name stuff and lost track of it. I will do another test on RC7. Note: As soon as I started the torrent - it received Seq. #1 and pushed the others down one.

rafti: The name cannot be much of a key or if it is then it allows duplicates. I have been to several torrent sites and I have seen multiple torrents listed with the same name. I have also download a torrent, changed the name and if I download the torrent again, uTorrent must be using some other key because it will state I already loaded the torrent and do I wish to update trackers. I would say 99%+ of the users of a P2P client want to have the names of their torrents comform to their naming convention - NOT the creater of the torrent, nor the site where the torrent is downloaded from. So if I specify a name when I add a magnet - that is the name I want to use to represent the torrent once the metadata is downloaded. I do not wish to change the field twice, just because uTorrent resets it back to <whatever>.

Zarggg: The point of the Name field being used as the torrent name is to facilitate the user in locating it later in the main window (sorting by name, etc.). There is no reason why the Name needs to be modified by uTorrent upon completion of downloading the metadata. There is no counting the number of variations used in the naming a torrent when the content is the same. Look at how many names are used to represent a single tv show season, a set of documentaries, etc. (Some sites like to put there www.<theresite> in the beginning of the torrent name. Some put special characters such as "[","]", etc. in the name. All stuff that makes it hard(er) to organize torrents and the data associated with them.) My feelings are magnets require unique processing and should be classified as such. Initially they should have a "Get Metadata" classification and should NOT use the current Add dialog box since 99% of the data on the screen is blank until the metadata is downloaded. The amount of time to download the metadata is undetermined and depends on the number of seeders/peers who already have the torrent and all the other issues concerning upload/download performance. Waiting a minute+ in the Add dialog box is unacceptable. If there as a classification "ready for download" (or something like that) utorrent could: 1. Automatically start the download metadata with a status of "Metadata Downloading". 2. Upon completion of the metadata download "Ready for Download" or "Stopped" status. I would rather the "Ready for Download" because it helps identify those torrents where the user may desire to change the download location (filenames, etc.) prior to the actual start of the download. 3. Users can use "Set Download location" and/or "Relocate" to move files if desired. otherwise defaults are used. 4. User Starts the download of the torrent. In this case directories (folder, sub-folders) are not created until the start of the Download. Even for a normal torrent where you would use the current Add box, uTorrent could delay creating the folders until the initial start download command (and probably does). Oh well.

Meddio: I don't think it is as easy as it sounds (removing a file or a subset of files) from a completed torrent. The problem is cross file pieces. Part files would have to be created for all files removed that have a piece that is also part of the file being retained. And if you deleted a file and its piece crossed into a part file, the part file (even one just created) would also have to be removed. A lot of processing.

Meddio: Of course there are many different checks that need to be made, but they are all done (or should be done) at the ok_on_click event. If you got the impression that I wanted to delete or change the sub-folders defined in a multifile torrent - then I was not clear enough. I was only changing the filename on a singlefile torrent or a multifile with only a single file. True multifle would keep all of its sub-folders. (There is no way multple sub-folders and and associated files could be changed unless they allowed modification on that grid.) I was going to say - I do not think you should require the user to enter the "\" to determine whether you will create a sub-directory using the Name field. (I would not use it.) But I can see where it would save you a few key strokes if you selected the parent directory via the Select Folder dialog box , modified the return path to add the "\" (or typed in the entire path and included the "\") to flag uTorrent to create the sub-directory with Save In path + Name field.

Meddio: I have not tried typing in the Save In path. But it would seem that a check to see if it exists and then create it if it doesn't would be simple to implement. I would hope that the Name filed (on a multifile torrent) would only be used to create a sub-directory when the Save In field = the default save downloads field - since a lot of different torrent downloads are stored there. You can assume the user has selected (or created) the sub-directory where they want it stored. To always add the Name field can (from time to time until you are very experienced) can cause another redundent sub-directory - such as ...\tv-show - Season 01\tv-show - Season 01. They could check the end of the Path string to see if it is NOT the same as the Name field the append it to the Save In string and create it. That would solve that problem.

Well I do not know which release Meddio is using, but I agree the SingleFile torrent is still messed up in RC6. The Save In works as it should - it picks a folder where in the past you selected a physical filename. However the Name field is now ignored. When you change the value of the Name field, the Add dialog box DOES NOT replace the name of the torrent, nor the physical filename where the file is to be stored. It would be so much simpler if you got someone who understands how the Add dialog box is suppose to work, the flow of the use cases, and new how to code. Since the developer did not understand my suggestion here some pseudo code: proc SingleFile Torrent.Filename = AddDialog.Name; Torrent.Path = AddDialog.SaveInPath + AddDialog.Name; proc MultiFile if SingleFile_MultiFile SingleFile else if DefaultTorrentDownloadSaveIn = "" DefaultTorrentDownloadSaveIn = "C:\Users ..... etc." if AddDialog.SaveInPath = DefaultTorrentDownloadSaveIn Torrent.Path = Create Directory (AddDialog.SaveInPath + AddDialog.Name) else Torrent.Path = AddDialog.SaveInPath proc On_Click_Add_Dialog if Torrent_multifile Multifile else Singlefile; Torrent.Name = AddDialog.Name If there are side issues I will let you figure it out.

AdamK: I will upgrade to RC6 (now that it is available) and check the add torrent box again - I was using RC4.

The Add Torrent dialog box creates more problems because of the method to solve the problem in each case. If the Save In was strictly a folder selection process. The following could be done: 1. The Name field is always moved to the display Name in the list of torrents. 2. Single File torrent: The Name field is used as the filename. 3. Multifile (with single or multiple files): a. For a torrent with multiple files: The Name field is ignored for the purpose of sub-directory creation - UNLESS the Save In field is the same as the Preferences -> "Put new Downloads in". The assumption is if the user selects a sub-directory different then defined in the Preferences then that is where he/she wants to store all (or majority of) the files. Individual files then can be moved via the relocate function. b. Multifile with a single file in the torrent: The Name field is ignored for the purpose of sub-directory creation. It is used to replaced filename just as if it was classified as a single file torrent. So I see two general cases where the multifile torrent has two sub-cases. That should not be hard to implement.

rafi: Assuming a person wanted to remove a torrent they were seeding, I can understand that part files should be removed from the system. Otherwise, aren't they necessary to support seeding? Cross file pieces - when a user does not download the entire torrent.

Well - single file torrents via the "Save In" is still messed up. When you open the "Save As" dialog box. the path located in the Save In box is moved to the Filename box. For example "TorrentsDownloaded.*" It completely ignores the name field or the file name specified in the Torrent Contents. The file type is *.* rather than the filetype in the Name field. So you are forced to modify the filename in the Save As dialogbox. (I would anyway since I do not like the format, but now I need to replace the entire name rather than editing it to conform to my standard.) Don't you guys have peer review?

I fail to understand why it is so difficult for the developers to solve the Add Torrent dialog box issue. It seems now (in RC4) the name field is ignored on a single file torrent. It seems to be back to the old way You need to use the "Save In" (I have yet to add a second torrent to be sure). It would seem to me the easiest and simplest method would be the "Save In" to be a folder selection - and thats it. In Single file torrents - the "Name" field is the name of the (to be) stored file and the "Name" displayed in utorrent. In Multi-file torrents - the "Name" field is the name of the Sub-Directory/Folder where the files in the torrent are stored and ALSO the "Name" displayed in utorrent. (The user would select the parent directory in the "Save In" field.) If you are going to ignore the "Name" field on single file torrents - at least hide the field.

zhial: There is no such thing as "safe". You may be able to reduce your risk. But you will never be 100% "safe". Encryption of your disk means very little. If they can prove you download a specific torrent based on your IP or force the VPN host to give you up - thats it. A court can order you to give up your encryption key of your disks. You coud destroy your disks - but they do not need to prove that you have the data, only that you got it. And they can do that just by being part of the peer group that seeds to you. There are plenty of ligitimate reasons for using a P2P client. And none of them involve anything illegal. There isn't a software company out there that will recommend or support anyone doing anything illegal with their software.

eddieray: This question should be posted in Chat or General Threads. That being said, you can search for a movie, tv show, etc * torrent in google. It will list a ton of sites. Some are private sites and some are public. A private site has rules that you must adhere to inorder to keep your membership. Some sites have a lot of torrents - some don't. You need to find those sites that will provide you with what you want to download. Public sites are free. Private sites may require you to pay a fee - I do not know, because I do not join private sites. The danger in torrents is you may download copyright material. If you do and you get caught - you may be forced to pay alot more than if you bought it in a store. You may lose access to your internet provider. What you download, you do at your own risk. If you are having problems - pose the question in the correct thread.

Still getting a lot of errors on the log file concerning "Error opening ... .Torrent" of torrents that have completed. I have the completed torrents automatically moved to a completed directory in my preferences. The torrent is moved but uTorrent still thinks the torrent is in the "Store Torrents In" Directory. It would be interesting to know how this affects seeding - whether uTorrent uses what info hit has in memory or what - the torrents in question are in a seeding status and show a value in the Up Speed column.

SquareSoft: Didn't you see the post where it was reported there are bad settings.dat and settings.dat.old with older versions (pre beta) of uTorrent? Didn't you see the post where if your settings ... are larger then 150KB shutdown uTorrent and delete them? With those posts - nobody should be posting with large settings.dat and settings.dat.old Delete them. Start uTorrent again and see if that clears up your problem.