Archived

This topic is now archived and is closed to further replies.

Firon

µTorrent 3.2 stable (27568)

Recommended Posts

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>.

Share this post


Link to post
Share on other sites
If we fix that' date=' this problem will still occur for torrents whose metadata has not arrived before you click "OK". (They will use the original name)[/quote']

Not if you make sure this change *holds* and always does not revert to the "original" after the meta-data arrives. Just, always use the name loaded with the magnet (and maybe modified). Torrents' *names* are 99.9% the same (not changed) in the meta-data (like a key), so it is valid to change it before or after the meta-data arrives.

They will just be used as display and folder names per the use convenience.

Yes, I agree we should do this. I'm just giving you the reason that we are not doing it *now*.

1. Automatically start the download metadata with a status of "Metadata Downloading".

+1.

Magnets should' date=' by default, auto-load the meta-data when being added (unless the user presses "stop", or advance-option not to), and should display "Waiting for torrent info" in the status.[/quote']

Another very good idea for 3.2.1

Share this post


Link to post
Share on other sites

I didn't see any mention of this, at least from what I understood from the various technical jargon but...

Ever since I upgraded from 3.1 to 3.2 ( Due to constant disk overload 100% errors which fixed the problem btw) my RSS feeds are seriously screwed up. I have them filtered by date added and the new ones have no date or wrong dates or the feed doesn't show up at all. It could be a coincidence that all 3 stopped working properly right after I upgraded but it seems more likely to me that its a new bug.

Share this post


Link to post
Share on other sites
I didn't see any mention of this, at least from what I understood from the various technical jargon but...

Ever since I upgraded from 3.1 to 3.2 ( Due to constant disk overload 100% errors which fixed the problem btw) my RSS feeds are seriously screwed up. I have them filtered by date added and the new ones have no date or wrong dates or the feed doesn't show up at all. It could be a coincidence that all 3 stopped working properly right after I upgraded but it seems more likely to me that its a new bug.

Can you email me the feed?

Share this post


Link to post
Share on other sites
I didn't see any mention of this' date=' at least from what I understood from the various technical jargon but...

Ever since I upgraded from 3.1 to 3.2 ( Due to constant disk overload 100% errors which fixed the problem btw) my RSS feeds are seriously screwed up. I have them filtered by date added and the new ones have no date or wrong dates or the feed doesn't show up at all. It could be a coincidence that all 3 stopped working properly right after I upgraded but it seems more likely to me that its a new bug.[/quote']

Can you email me the feed?

sent

Share this post


Link to post
Share on other sites

Re-settng column widths still causes uTorrent to CRASH every time!! I thought this issue was fixed on a previous build months ago, but has once again been re-introduced into the Release Candidate builds....

Can others reproduce this crash??

Share this post


Link to post
Share on other sites
Re-settng column widths still causes uTorrent to CRASH every time!! I thought this issue was fixed on a previous build months ago, but has once again been re-introduced into the Release Candidate builds....

Can others reproduce this crash??

I haven't been able to reproduce this yet. Can you give us more information?

Share this post


Link to post
Share on other sites
I haven't been able to reproduce this yet. Can you give us more information?

My guess would be - bad settings.dat file... Simon100: try backing it up and re-try with an empty one.

Share this post


Link to post
Share on other sites

Just thinking to myself a question that I'm sure has been asked MANY times thus far, by MANY people:

Why are you pushing for new versions to be in the "Release Candidate" status when you're still fixing major bugs that, if this were any other software development company, would have been worked out in the BETA phases WAY before the product would even be considered stable enough for a general public release and given the title of "Release Candidate". I mean, you guys are still fixing "Blue Screen of Death" issues caused by your software, general I/O and performance issues, and many other pretty serious bugs. Why not just stay in the BETA phase until the product is stable? You guys shouldn't be anywhere near releasing the next version of uTorrent when the 3.1.3 version is still full of bugs and has much room for growth, especially since there really isn't much of a difference between the versions.

Share this post


Link to post
Share on other sites
Just thinking to myself a question that I'm sure has been asked MANY times thus far, by MANY people:

Why are you pushing for new versions to be in the "Release Candidate" status when you're still fixing major bugs that, if this were any other software development company, would have been worked out in the BETA phases WAY before the product would even be considered stable enough for a general public release and given the title of "Release Candidate". I mean, you guys are still fixing "Blue Screen of Death" issues caused by your software, general I/O and performance issues, and many other pretty serious bugs. Why not just stay in the BETA phase until the product is stable? You guys shouldn't be anywhere near releasing the next version of uTorrent when the 3.1.3 version is still full of bugs and has much room for growth, especially since there really isn't much of a difference between the versions.

I see that you have much experience in software development. Please, enlighten us in the ways we may do things differently. Your suggestions are welcome.

Share this post


Link to post
Share on other sites
I see that you have much experience in software development. Please, enlighten us in the ways we may do things differently. Your suggestions are welcome.

Hehe, that's a little cheeky Adam :) I was going to mention something as well but looking at the uTorrent history of considerable release candidates before a stable release, I thought it was unlikely to change now, so decided against mentioning it. Basically ask Rafi if it's good enough to be an RC ;)

Okay that actually isn't a bad idea, but seriously now it all comes down to what issues are being reported, which is what you're currently doing I guess. I wouldn't think you guys go.. "hey almost time for a release let's make it an RC already!" A release candidate should only go up to say RC3 or so at the highest. People expect an RC to be.. good enough to be released as stable barring no major (or multiple minor) issues, basically IT IS as far as the devs are concerned THE stable release.

Now personally considering all the issues still being fixed, I think 3.2 should still be in beta with an RC being posted once Rafi's posted bugs have all been fixed. Many users might think the same, but it's your software, you don't need to do what people expect, it's just nice if you do :) Thanks!

Share this post


Link to post
Share on other sites
Re-settng column widths still causes uTorrent to CRASH every time!! I thought this issue was fixed on a previous build months ago' date=' but has once again been re-introduced into the Release Candidate builds....

Can others reproduce this crash??[/quote']

I haven't been able to reproduce this yet. Can you give us more information?

Restart uTorrent, you should have 1 more torrents running. On the "Files | Info | Peers | Trackers | Pieces | Speed" window pane, Select "Files", then right-click "Path", "Size", etc... any one of those columns, then select "Reset". uTorrent should crash... If it doesn't crash on the 1st reset, it'll crash if you right click one of the column headings under "Peers", then select Reset again.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
Note: As soon as I started the torrent - it received Seq. #1 and pushed the others down one.

And was that correct ? Was it the only one in the download queue? Or did you check "add to top of queue"?

I think there might still be issues in there.

then select Reset again.
My guess would be - bad settings.dat file... Simon100: try backing it up and re-try with an empty one.

Did you try that?

Basically ask Rafi if ... I think 3.2 should still be in beta with an RC being posted once Rafi's posted bugs have all been fixed

So, someone is actually reading my lists?... ;P I'm honored, but as long as issues are being attended to, I couldn't care less what the version name is: beta, RC, Coke or otherwise (in spite of other conventions)... ;) It is also up to the devs, and not us, to postpone none-critical issues to a future release. People can still benefit from other improvements. Example: #15/16 on my list are not that high priority, and people can live with them being fixed in the next release...

Do you know how many crashes (and I mean BSOD!) I had with FireFox running Abode's Flash 11.3 (stable!) the last few weeks ? And I didn't see any "RC" nor "beta" being mentioned there on Abode's site... (if you don't know - you can Google it ...)

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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. :) )

Share this post


Link to post
Share on other sites

Thank God you were not"going for the record"... :) Seems too long to even try read...

For me - whatever the user modifies and for whatever reason - should be left alone, and acted upon. And he should be given the means to do it in the most convenient way.

Share this post


Link to post
Share on other sites

So, someone is actually reading my lists?... ;P I'm honored

Considering the amount of time you take to test, keep track of and document them I should bloody well hope so. You've done an excellent job of that over the last seven odd years, you're a real asset to the uTorrent development team and the community and come off as a great guy to boot and I respect you a lot for that.

as long as issues are being attended to, I couldn't care less what the version name is: beta, RC, Coke or otherwise (in spite of other conventions)... ;) It is also up to the devs, and not us, to postpone none-critical issues to a future release.

Indeed, RC12, 13 sure.. what's in a name? It doesn't bother me that much but.. it flies in the face of other software development cycles users are experienced with. RCs with uTorrent are more like late beta cycle builds than true release candidates judging from the issues I see being addressed, it just doesn't give a good impression and honestly I really think counts for something.

I think one way of helping to create a good impression would be releasing fewer builds (perhaps with more internal testing) that have more fixes rather than more frequent builds with less fixes. Holding off on the release candidate "phase" and letting the beta receive more thorough testing by the community would give a better overall impression of the project also.

We know a stable build doesn't mean all bugs are fixed, I don't think there are many people that expect that, we'd just hope the more problematic ones that are known about that are be fixed providing they can be done reasonably quickly. It's a question of what's non critical? We've hit RC with 3.2 and there have been some significant issues found. If it's taken this long to find those, why not wait it out a little?

People can still benefit from other improvements. Example: #15/16 on my list are not that high priority, and people can live with them being fixed in the next release...

Yes, sometimes the benefits of the new version outweigh the bugs of the old. I would think that if people are experiencing issues they would switch to the beta build to see if things are improved there. If there stability bug fixes are being committed in a release candidate (if you define a release candidate as being a stable build) it might pay to ask, are we rushing this? Impression and word of mouth.. these things can make a product sink or swim.

Do you know how many crashes (and I mean BSOD!) I had with FireFox running Abode's Flash 11.3 (stable!) the last few weeks ? And I didn't see any "RC" nor "beta" being mentioned there on Abode's site... (if you don't know - you can Google it ...)

I know all about that, pretty appalling testing on Adobe's part. I reverted back within minutes of updating it :lol: Let's hope they learned from that one!

Share this post


Link to post
Share on other sites

RC7,Win 8 RP 32bit. I use magnet links and have problem. When i add torrent use magnet link, he have 1 video file(.mkv),wait when i see name and click ok to download file, program create 2 files first have real name, second have "Name" field from Add Torrent dialog. This 2 files have full size and video work only in file which have "Name" field from Add Torrent dialog.

P.S. I see this problem have .torents files too (.avi).

Share this post


Link to post
Share on other sites
Guest
This topic is now closed to further replies.