The Infamous List

[metaclam]

Hi again, yep it's me. I'm not sure you you meant to post this as a new thread?

I've done quite a lot of experimentation this morning. One thing I tried was to resurrect my entire corrupt Application Support folder, but remove the entire "Resume" folder within it. Doing that once again allowed a test transfer to start normally and right away. So again, I've confirmed here that the problem is in that "Resume" folder somewhere. Note: I retained all other files within Application Support, including blocklists, and Transfers.plist, from the problem version.

HOWEVER, and this is a massive however for me, forcing the regeneration of the resume files meant that all data file locations were lost. Torrents started downloading that I already had. I needed to pause them all ASAP. I regularly move torrents all around several external volumes (depending on what the data is). So that means again all data for 2000 torrents needs to be re-verified. This will take hours and hours and hours.

In addition, let me point out there A) there is no key equivalent for "Move Data File To..." and "Verify Local Data..." both of which would be helpful in this case; B) a little AppleScript support would go a long way here.

OK, buckling down here.

(By the way, if there were a menu command in Transmission to rebuild all resume files, that would be swell, no? then it would retain path locations, and re-check all data. So easy... )

[metaclam]

as it, to me at least, doesn't seem to make sense that old corrupt .resume files would affect new torrents. Also, you could test again with the latest nightly before proceeding.

And yet that was the case. Sure seems like a bug to me -- something unexpected in those .resume files caused T. to stop connecting to the trackers, for downloads. I feel like I have provided enough evidence here to investigate this.

I have now completed my "restoration" (better part of 2 days later As specified before, I retained the original preferences file, and all files and folders in Application Support except the Resume/ directory.

It's working now with 1771 transfers. 2 are going normally right now, including a 3.75 GB xfer.

However there were some very strange glitches, as follows:

1. a handful of torrents did not verify to 100% even tho I'm totally sure they were 100% before. Those were all 98%+.

2. My "incomplete torrent" directory simply disappeared, twice. The last time I noticed it a downloaded stopped mid-stream, with the error:

Code: Select all

No data found! Ensure your drives are connected or use "Move Data File To…". To re-download, remove the torrent and re-add it.

I recreated the directory, with a slightly different name, and changed the setting. T. then crashed. I relaunched it again and now again it is working normally.

That may be related to #2:

all data file locations were lost. Torrents started downloading that I already had. I needed to pause them all ASAP

Ouch! Not sure how far you got with this, but you might want to check /Volumes on your internal drive to ensure that nothing got created there with a name like your external drive(s) with maybe a "1" after the name.

Nothing unusual in /Volumes/

But this does beg the question, where do those .part files go if it cannot find the incomplete folder?? I did a spotlight search for .part files but turned up nothing (apart from ones I expected), during the period above where everything started, many in the wrong location. It was as if those files were going into a void. Could very well be related to second problem mentioned above, because I also noticed the Incomplete folder was simply gone.

All of this was with 2.32+ (12545)

[metaclam]

CR here:

http://pastebin.com/1aVpY5LT

Yes, only a handful, thankfully. It wasn't missing text files, individual (in this case media) files were shown at 98 or 99%.

This is all that's in the Console log:

Code: Select all

7/20/11 4:42:34 PM	[0x0-0x2b32b3].org.m0k.transmission[72497]	Assertion failed: (compare( t->items[i], t->items[i + 1] ) < 0), function assertSortedAndUnique, file /Users/sheila/transmission/trunk/libtransmission/ptrarray.c, line 212.
7/20/11 4:42:40 PM	com.apple.launchd.peruser.501[244]	([0x0-0x2b32b3].org.m0k.transmission[72497]) Job appears to have crashed: Abort trap
7/20/11 4:42:42 PM	ReportCrash[52063]	Saved crash report for Transmission[72497] version 2.32+ (12545) to /Users/myuser/Library/Logs/DiagnosticReports/Transmission_2011-07-20-164241_MacPro.crash

Unfortunately the Message Log doesn't go back far enough to look now.

[metaclam]

I notice the incomplete folder is GONE again. This must have happened AFTER successfully downloading the 3.45 GB file mentioned above. I bet this is a bug in the nightly. My incomplete folder always starts with a space, as a sub-folder of my complete folder. Starts with space so near top.

edit: tested with incomplete folder at same level as download folder and no space. did not happen after one dl test.

[metaclam]

Could you test with your incomplete folder in the original location as a sub-folder of your complete folder but without the space. Try a couple of runs with small files if you can. Thanks!

OK. I used a "!" instead of a space to put it near the top. in original location as a sub-folder of complete folder. ran one test. This time T. did not remove it when complete.******** ---> EDIT <-----

Although it seems unlikely, I now wonder whether the original problem could have related to this issue.

I'd still like to know where the temp/.part files are supposed to go if T. cannot locate the designated incomplete folder.

******* several hours later, came back to start a few new torrents, and that folder is gone too.

[metaclam]

OK, trac ticket submitted for this one issue, as you recommended.

The other issue about choking on bad resume files is also a problem but I as yet do not know what to report (in a trac ticket that is). I hope with all the info I've given in the forums that someone can look into it.

[metaclam]

When I submitted the ticket it said it was awaiting moderation. Now when I click on "My Tickets" I get this error, even though I'm logged in:

Code: Select all

This report demonstrates the use of the automatically set $USER dynamic variable, replaced with the username of the logged in user when executed.

Were you able to seed from your ~2000 torrents or were they also disabled, as well as being unable to d/l new torrents? Prior to first noticing this issue, had you done any version regression/re-update? If so, what versions were involved?

I was able to seed. Prior to noticing issue, I don't believe I had updated anything (hence "why would T. suddenly stop working"), though I can't be absolutely sure anymore. I am pretty sure it was on the release of 2.32. After that I moved up and down among 2.31, and 2.32+, and 2.32. Never lower than 2.31.

[captain]

I have a solution to at least part of this problem (which persists under OSX Mavericks 10.9.5 and Transmission 2.84)

It appears that there is some mechanism in the "watch for torrent files in" tool (and/or the add to Transmission feature) that is broken, and/or just cannot handle more than a very few "new" (old--i.e. already downloaded and just needing to be added and verified) torrents at one time.

To get around this since no one seems to be addressing the bugs, HERE'S THE KLUDGE:

Instead of using Finder to open all the .torrent files at once, or to manually do a few a a time, use the shell! Open ONE at a time, with a ten second pause between each. If your torrents are large and/or your drives slow, increase the sleep time to something close to the average verify-time (i.e. if the time it takes Transmission to verify your torrents is an average of 50sec each, set "sleep 50"), thereby keeping only a few torrents in the verify queue at a time. I'm using zsh. Obviously cd into your .torrent file directory before running this:

Code: Select all

foreach file in *.torrent
open -a Transmission $file
sleep 10
end

EDIT: this seems to work, albeit there are still a handful of torrents that require manual verifying. Just keep re-verifying until it's all done. THIS SEEMS TO BE YET ANOTHER BUG IN TRANSMISSION! 9:10 of torrents only partially verify, and then have to be manually re-verified! Be sure to turn OFF "Start transfers when added" or you'll end up having all your good data overwritten and have to download everything all over again. MAJOR BUG HERE!!