signe

(Build 27226) I swear that I've been reporting this since before 3.0 was finalized, but certainly since before 3.1. The "Bandwidth Allocation" context menu is off by one. If Normal is selected (as default) the highlight is shown on Low. If you select High, it shows on Normal. If you select Low, it doesn't show at all.

1. Completed Date is consistently ~45 days ahead. Files completed today are listed as 2012-01-31. 2. The "Bandwidth Allocation" submenu is off-by-one. I reported this on previous builds, but it hasn't been addressed. Selecting High shows Normal selected. Selecting Normal shows Low selected. Selecting Low shows Low selected.

B25835: The 'Bandwidth Allocation' context menu selection is off-by-one. Selecting High shows Normal selected. Normal shows Low selected. Low also appears to show Low selected.

(24979) Seeding is causing directory modification timestamps to be updated. ex: Two multifile torrents are set to seed with no leechers currently downloading. Both directory timestamps are set to 2011-01-01 00:00:00. When a leech begins downloading, the directory modification timestamp is updated to now. (2011-03-02 21:31:00) This doesn't affect single file torrents.

Build 21887: Crashity crashity crash crash. I can't tie it to any specific cause - simply downloading as normal. Not finishing files, etc. (Maybe finishing parts? Who knows.) All dumps submitted, but it's crashing every few minutes at most. Sometimes almost immediately after startup.

Right - I'm not talking about move upon completion. Using "Set Download Location" (i.e. Right click, Advanced, Set Download Location...) which just started moving files when used (a long requested feature) is doing this. What I'm saying is that when the file was downloading I either forgot, or didn't have enough time, to set the label - so, the file ended up in my root torrents directory. (i.e. D:\Torrents\) I set the label now that it's finished so I can keep track of it, and then I use Set Download Location to move the files into the proper location (e.g. D:\Torrents\Label\) The Set Download Location functionality is appending the label to whatever directory I select. So, if I move a file from D:\Torrents\ to D:\Torrents\Label\, and the file's label is "Label", then the file *actually* gets moved to D:\Torrents\Label\Label\ Make sense now? It's a little confusing to explain, much easier to see happening.

b21340: Still experiencing the issue with Set Download Location where if "Append the Torrent's Label" is enabled, the label is appended to the directory set using "Set Download Location" as well. This means that if I have a file in "D:\Torrents\", and it's labelled "Downloads" (which I, of course, set after it finished, otherwise it would already in the right place) Using Set Download Location to move the file to D:\Torrents\Downloads\ actually moves the files to D:\Torrents\Downloads\Downloads\ This is of course even more messed up if you use multi-level labels, like I do. (e.g. labels like "Downloads\Home", "Downloads\Work", "Foo\Bar\Baz" ... ) This turns into things like D:\Torrents\Foo\Bar\Baz\Foo\Bar\Baz\[file]

21169 - Set Download Location prepends the torrent label to the new location. While moving several of the crashed files from the 'freeze on complete' issue to my 'Television' folder, it actually moved them to 'Television\Television'

21169 freezes every time a torrent completes. The file move finishes, but the torrent info is never updated with the new location so after forcing a close/restart, it begins downloading the files all over again because they're not in the downloading directory.

Ditto - crash within 30 seconds of startup. No crash dump - app just exits without warning.

Just following up... No change in the File Locking/Move On Complete issues in 18683.

@Firon Yes, it began in 18581 when the O_EXCL and lazy close were introduced. There's another user who reported this same issue in the Found Bugs forum.

@pixie2 Sounds like the exact issue I was describing in #461

I'm seeing repeated issues where files are not being unlocked: Stopping a torrent doesn't unlock files. Torrents that complete normally are frequently (though not 100% of the time) failing to move into their target directory. When this happens, (in multi-file torrents) some of the files will move, then then it will hit one that's still locked, and the torrent will enter an "OS couldn't find the file" state. This causes great grief because you have to stop the torrent (which doesn't unlock the files, as noted above), or exit ut entirely, move the files by hand, then Set Download Location and do a forced recheck of the pieces before it will work again.

Disabling write caching does resolve the "torrents all eventually drop to sub-1kbps transfer rates" issue. Couldn't tell you why.