jbebad

Established Members
  • Content Count

    305
  • Joined

  • Last visited

Community Reputation

1 Neutral

About jbebad

  • Rank
    Advanced Member
  1. 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.
  2. 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.
  3. Meddio - sorry I did not read the full message.
  4. 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
  5. 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.
  6. I do not know about incomplete design, but incomplete implementation - yeah.
  7. 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. )
  8. 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.
  9. 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.
  10. 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.
  11. 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>.
  12. 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.
  13. 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.
  14. 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.
  15. 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.