Multiple UI (and other) issues

[LTF]

Hi, long term fan (LTF!) and user since 1.7.7 or before, but this problem (#1) has been driving me crazy for months.

I'm running uTorrent version 3.3 (build 29625) [32-bit] [EDIT: have now updated to latest Beta and retested, see below for follow up], on Windows 7 Ultimate 64 bit SP1, fully up to date, on an Intel Pentium D 3.40 GHz (two cores) with 8Gb ram - it's not the fastest setup, and sometimes there's a brief CPU 'freeze' when it's heavily stressed, but it gets the job done - connected by Lan cable to a router and then an ADSL connection of about 1Mbit down and 0.25Mbit up. I use AVG Free antivirus, Peerblock 1.1, and have no weird apps running. I can provide more info if needed.

The problems:

1) Unexpected shutdowns/power offs lead to the torrent list being massively reordered. Start/Stop status is also sometimes affected.To replicate (and note that a simpler procedure may well produce the same results):

- Have uTorrent running on Windows Startup, and have torrents loading automatically (no properties window on load) and being 'Queued' automatically.

- Order Torrents list by number (#)

- load a bunch of torrents (I'd suggest about 50-100, but that's not hard and fast - your numbers may vary, perhaps according to your computer's capabilities or the individual torrents, my torrents are mostly single files in the range 250Mb to 1Gb, with one or two larger torrents of 5-20Gb containing multiple files of about 350Mb). You can stop some or all of them, and have others queued.

- Place them in some order other than the one in which they were added (move some up and down).

- Close uTorrent, then run uTorrent again (should save the order of the list).

- Add some more torrents (I'd suggest about 50-100, but that's not hard and fast)

- Place the new torrents in some order other than the one in which they were added, preferably but not essentially interleaved with the first lot. Optionally change some from Stopped to Queued, or vice versa.

- Make a note of the current file order.

- Optionally close and then run uTorrent again. (I find that doing this does not seem to prevent the issue occurring, though it does seem to ensure the the Stopped/Queued status is correct)

- Shut down uTorrent unexpectedly. I suggest turning off the computer using the power switch on the back, or unplugging the power cable. In my case this is normally due to power cuts, overheat and computer lock, or similar. I don't know if a computer shutdown will still produce the issue, though in the past it has.

- Start computer up.

- Look at the list of torrents and notice they are not in the order you put them in, but in a fairly unpredictable way, being sort of 'interleaved', with the first load of torrents scattered through the second load, like cards shuffled together. Any torrents added after the last legitimate uTorrent stop and restart will probably but not definitely have reverted to their initial Stopped/Queued state too.

Personally I think the above is a combination of uTorrent not storing the file order before the shutdown, or storing it in an unpredictable way, and multiple threads populating the list in an unpredictable fashion, but I'm not sure. Strangely I haven't had any torrents not be in the list, it's just the order of them.

2) If you have a large number of torrents loaded (eg after the test of #1 above) and you close down uTorrent legitimately, then downloading and running a torrent from a web site will cause uTorrent to run, but the torrent list order will again be mixed up, as in #1, and the new torrent will often not be last in the list.

3) Pieces from files marked as priority 'Low (1)' and perhaps other priorities, show up in the Pieces tab as 'Skip'. I'm also pretty sure 'Normal (5)' is listed as 'Low', too. I guess this will be fixed when the code for the Pieces tab is updated to reflect the increased number of Priority settings.

4) On the Files tab, when right click menu closes then sometimes the Tabs menu (as seen when you right click the tabs, eg Files, Info, Peers, etc) opens up. It happens less than in previous versions, but still happens sometimes. I've not been able to quantify exactly under what conditions this occurs.

5) 'Prioritize by File Order' doesn't seem to do exactly that - it seems to pay attention to the order of the files in the file list too. If I select a bunch of files that are partially downloaded and already in some kind of sort order based on first Priority and then %age completed, then 'Prioritize by File Order' will renumber the selected files but often in the order of the file list, or a combination of that and the actual file order as defined by number of the first piece in each file, I'm not sure. Surely it should go by the piece order so that well made torrents will prioritize as per the order in the file (eg first episode first, second episode second, and so on) - it certainly seems to do that some of the time.

Some other possible (non-UI) bugs, comments or strangenesses:

6) High v Low: I'd love it if you guys would take a fresh look at the algorithm for this. If I have a large torrent with a large number of files, eg 125 video files, I will generally set the priorities of the files to download eg the beginning of a season first before letting the rest download in a random order. Often uTorrent spends far too much time downloading everything but the High Priority files. I get why this is done, to avoid everyone downloading the first files in a torrent first, and so messing up the swarm or something, but it seems to me that the system is quite unbalanced. At a guess it takes into account the number of Mb or pieces in each priority category, the priority of each file, and the availability of the files (and indirectly the speed of file download from individual users since if one user provides certain files fast while other users provide the rest of the torrent slowly then the former will be the ones that will complete fastest), but I think the number of Mb/pieces in each category is too heavily weighted in the algorithm; if I have 125 similar sized files and I set 10 to high and the rest to low, the high priority pieces downloaded will be in the minority compared to the low priority pieces. Could you consider tweaking that a bit to rebalance it?

7) On one torrent I'm downloading (it's big, and from a public tracker, and contains multiple video files, I can point you to the file to you if you wish) the downloading of the first/last piece of each file has been really bad. The pieces show up with dark green all over each of them, and the individual piece download seems to fail and retry multiple times, to the point where pieces appear and disappear over and over again from the pieces list as it tries and fails to download the first blocks of the piece (and that is reflected in the file list too), and multiple blocks (eg 5 to 50 per piece) flick back and forth between Dark Green and either green or white, the same blocks on-off over and over and over again, and the actual download speed (about 100Kb/s) was not even slightly reflected in the data downloaded, perhaps in part due to a large number of pieces being stuck at about 253 out of 256 blocks, or perhaps because of a high number of blocks download fails - I'm not sure. Nothing unusual shows up in the Log, but I noticed that at one point I had 75 pieces being downloaded at the same time (or rather, not), which is far from usual behaviour for my setup, as is the whole 'bubbling' dark green blocks thing. I have not noticed this before on other torrents, though I can't say for sure it's never happened since I don't often download such large torrents.

8) Lastly, why do pieces in the piece list containing eg 256 blocks and showing 256 blocks completed not actually complete and disappear from the piece list immediately? There seems to sometimes be a delay, sometimes as much as several minutes.

Anyway, love the app, hope the above is helpful, and pray that at least the unexpected shutdown issue is quickly addressed (it's driving me CRAZY with all the power cuts recently!).

All the best,

LTF

[ciaobaby]

I'm running uTorrent version 3.3 (build 29625) [32-bit]

And is NOT the current stable build, never mind >>> Use the latest beta before reporting anything!.

[LTF]

Thanks, ciaobaby, for pointing that out.

I've installed the latest Beta, and tested again. Points

(1) unexpected shutdown shuffles list

(3) Low (1) pieces listed as Skip in Pieces List

(4) Closing right click menu in files list sometimes opens tabs menu.

(5) Prioritize by File Order ignores file order

all still exist and apply.

Further testing on (2) [reshuffle list on torrent load when shut down] will be needed (it didn't happen yet but that doesn't rule it out in the future)

For (1) I saw the list was definitely shuffled when I killed uTorrent with the Task Manager, though not too bad (the files moved but stayed together better), perhaps because I only added a few files as opposed to my usual 10 or so, or perhaps because I used Task Manager, or maybe it has been improved - the list filling certainly seems faster, which might factor in. Still, the behaviour is still there.

I would also add that in (1) the list reorganizing on unexpected shutdown, it may be exacerbated by a trick I use for torrent positioning. Rather than press 'Move Up' 50+ times to move a group of 10 files further up the list, I select the file directly above the first file I want to move up, and then hold Shift and select the file directly below where I want the files to move (ie I select all the files between but not including the files to move and the position to move to) and then move them down, and the files I want to move are moved up with much less clicking. That may have something to do with it, though that should work absolutely fine.

Funnily enough while testing I've figured at least one time (4) happens. It seems when you left click on the files list menu (ie choose a menu item) the menu closes, but then the click occurs again as a right click in the same place, ie on whatever is under the menu. To reproduce: If you open the file list menu lower down on the window, and then go to the priority list sub-menu, so that the priority list is positioned so it overlaps the tabs bar, and if you left click the appropriate priority that is positioned over the tabs bar then you will see the behaviour I'm talking about.

From the second list,

(6) High v Low priority balancing still applies, it would seem, though more time would be needed to be sure since I've just restarted uTorrent.

(7) 'Bubbling' pieces will need time to reconfirm since I will have to wait for it to occur (and I'd just finished downloading the blocks that were causing problems, so I've deleted some of the files and will keep an eye on it. If anyone would like to test it, google 'Angel complete dvdrip x264' and you'll find the torrent in question, first link with the word 'bay' in it (I already own a legit copy of the DVDs, in case anyone was wondering)..

(8) completed pieces not completing will need time to reconfirm since I will have to wait for it to occur.

I will check further on the two unconfirmed items and get back, though I'd bet they'll still be there. Alternatively if someone else who has been using the beta longer could reproduce or confirm some or all of them, that would be great.

Hope that helps and clarifies,

LTF

[ciaobaby]

I've installed the latest Beta,

And which exact version and build is that??

[LTF]

3.3.2 Beta (build 29976) [32-bit]

[ciaobaby]

(1) unexpected shutdown shuffles list

When sorted by what column?

(4) Closing right click menu in files list sometimes opens tabs menu.

Explain 'closing the context menu'?

(5) Prioritize by File Order ignores file order

You do know that "Prioritize by File Order" only applies to the files in the list that are selected.

[LTF]

(1) unexpected shutdown shuffles list

When sorted by what column?

As per my 'how to replicate': 'Order Torrents list by number (#)'

(4) Closing right click menu in files list sometimes opens tabs menu.

Explain 'closing the context menu'?

Selecting one of the menu items. I expand on this in my second post and explain how to replicate it. It seems that in some cases a left click on a menu item that closes the menu is then followed by the effect of a right click in the same place.

(5) Prioritize by File Order ignores file order

You do know that "Prioritize by File Order" only applies to the files in the list that are selected.

Yes, I do know that. But it ignores the starting pieces of the selected files and instead goes by list order. For example, files ordered by Priority (and sub-ordered by Percentage Completed) listed as follows, in the following order:

File Name         :         First Piece
A                 :         100
B                 :         200
C                 :         300
D                 :         400
G                 :         700
F                 :         600
E                 :         500

If you selected all those files and did 'Prioritize by File Order' then the order will not change, whereas surely it should be in the order A,B,C,D,E,F,G because of the order of the first pieces. This holds true with more files in and around the selected files.

Hope that clarifies.

[ciaobaby]

But it ignores the starting pieces of the selected files and instead goes by list order

That's probably why it's called "Prioritize by file order" rather than "Prioritize by first piece order"!

As per my 'how to replicate': 'Order Torrents list by number (#)'

I'll rephrase my question as it was ambiguous. When the client restarts what column is it sorted by?

Selecting one of the menu items. I expand on this in my second post and explain how to replicate it. It seems that in some cases a left click on a menu item that closes the menu is then followed by the effect of a right click in the same place.

Something like this. >> http://forum.utorrent.com/viewtopic.php?id=128562 that only occured under the specific conditions outlined?

EDIT to add.

Just tested on 3.4.29998 and YES it is the same bug, needing exactly the same conditions.

[LTF]

But it ignores the starting pieces of the selected files and instead goes by list order

That's probably why it's called "Prioritize by file order" rather than "Prioritize by first piece order"!

...oookay' date=' if you say that's how it's meant to behave then I guess that's how it's meant to behave. You see, I thought it was meant to order the list by the order the files are in in the torrent (ie first piece order), hence 'file order', as opposed to the current behavior of 'file list order'. But if that's how it should be, then fair enough. It would then be handy then to have a 'Prioritize by first piece order' so that you can do that, very helpful for well made torrents (most of the ones I get nowadays) as you could just select all the unfinished files and prioritize them in the meaningful order automatically no matter how they are sorted in the list. For example, I currently have several seasons of Angel downloading (and yes, I own the legit DVDs), and the file list order of the later seasons does not follow the broadcast order because I sort by priority and then percentage completed, and they have downloaded at different speeds and so are at different percentages; it would be great to just select them all and get them prioritized by broadcast date (the same as the first piece order).

I'll rephrase my question as it was ambiguous. When the client restarts what column is it sorted by?

After the restart, it is still sorted by number (#). The torrents have changed number and so are in different places.

I'm curious, do you get this behavior when you follow the steps I outlined? Or is it just me and my install?

Just tested on 3.4.29998 and YES it is the same bug, needing exactly the same conditions.

Yes, you're right, that is the same issue; I didn't find that when I searched for previous reports of this, probably because (when I wrote my first post) I had not worked out exactly what conditions caused the behavior, I only worked that out subsequently. Thanks for tracking that down, that's very helpful.

[ciaobaby]

and the file list order of the later seasons does not follow the broadcast order because I sort by priority and then percentage completed, and they have downloaded at different speeds and so are at different percentages; it would be great to just select them all and get them prioritized by broadcast date (the same as the first piece order).

Never likely to happen because of the "rarest pieces first" algorithm, you can try and set a "fixed download order" but the protocol will take the pieces as and when they are available from peers.

I'm curious, do you get this behavior when you follow the steps I outlined? Or is it just me and my install?

I'll test it but I don't run ver 3 with more than 20 or 30 jobs because it just gets quite 'flaky' ( the same job list does run happily if I put it on 2.2/2.2.1 though) but that's progress I suppose.

[LTF]

it would be great to just select them all and get them prioritized by broadcast date (the same as the first piece order).

Never likely to happen because of the "rarest pieces first" algorithm' date=' you can try and set a "fixed download order" but the protocol will take the pieces as and when they are available from peers. [/quote']

I know that the 'rarest pieces first' algorithm somewhat or totally ignores the priority (I'm not sure of the exact details), but still, there are prioritizations. The first/last piece of each file is downloaded before almost anything else, and later on, the priority of the file has an effect. So while I take your point, the fact that there is a prioritization system at all means that it has some value, and given that, it would be good to get an alternative (and in my opinion more useful) way of automatically prioritizing files.

I'll test it but I don't run ver 3 with more than 20 or 30 jobs because it just gets quite 'flaky' ( the same job list does run happily if I put it on 2.2/2.2.1 though) but that's progress I suppose.

Thanks for testing it. I agree, the new torrent list system seems to be pretty flaky, has been since version 3. I normally try to keep the list lower than 50 jobs, but even then it can be flaky. I'm pretty sure the threaded system for filling the list is problematic, though I can't be sure. Anyway, I miss the old file list, if I'm honest, it was faster and worked better.

I look forward to hearing if you get the same results.

[ciaobaby]

I'm curious, do you get this behavior when you follow the steps I outlined? Or is it just me and my install?

Tested several times with 3.3.1.30003 and what is happening is to be expected.

When the client is restarted it comes back up with the list ordered by the column that was in use for sort order and direction at the last 'clean' shutdown.

This behaviour is expected because the GUI only 'saves state' on a user requested close event, not on child object change events.

Possibly what may be throwing your observations 'off' is that the sort column header is not flagged as 'in use' when the GUI restarts.

[LTF]

Thank you for testing that.

But it's definitely not an issue with the sort column - I never change that, it's always sorted by number, before and after the unexpected shutdown. Categorically, the numbers associated with the torrents are changing, and thus their position in the queue (or vice versa). Despite my not seeing the requirement to test on the latest beta at the start of this process (the perils of posting at 5am!) I am far from an idiot or a newbie, and I've seen this often enough (tens of times) that I am sure of what is happening.

I don't really know what to add, though I will gladly provide further information, images, etc. to substantiate this issue. I guess all I can do is wait and see if others report this, and hope that the bug can be found.

[LTF]

I wonder if it is something to do with processor/memory speed - since it seems like the list is populated by multiple threads, with some files taking longer than others to be put into the list, I wonder if my computer has some threads being slower than others, or being 'held up', and so the order is being mixed up.

That might explain why it is not seen by some people, and is by others (or at least me). My computer is prone to occasional 'pauses' when over-stressed, where processing on some processes or threads pauses temporarily (or rather, is used by some other process) leading to short pauses in some cases.