why would transmission stop working suddenly?

[metaclam]

What version were you using when you got this message? How long did it persist? Was the torrent paused or resumed?

All versions I've mentioned since this problem started have shown the same thing for all affected torrents, all of which were not paused. In several cases the torrents started hours later, in some cases more than a day passed and they never started.

That's Good News, right?

Yes, thanks, to a degree.

Well as mentioned and also from memory of past threads, .resume files can be an issue. As a general rule across all apps, corrupted preference files can cause problems.

The last successful test showed that the main preference file was not the issue because I retained it without any alteration.

I've heard of private trackers limiting per-user slots. Have you tried to contact any of the problem trackers to see if they have issues with either your account or a particular version of Transmission?

Again, since the same issue is exhibited with more the SIX private trackers, all starting at the same time (several days ago when I first reported it here), I have no reason to think that's an issue. Further, I've received no admin messages on any of those sites.

If you want to do further testing without messing with your 2000+ torrents, here's what to do:

• With Transmission completely quit, rename the following folders/files with a .bak extension.
~/Library/Application Support/Transmission
~/Library/Preferences/org.m0k.transmission.LSSharedFileList.plist
~/Library/Preferences/org.m0k.transmission.plist
~/Library/Caches/org.m0k.transmission

Thanks for the suggestion, but with respect, I don't see how the testing you suggest proves anything more than what I just proved above.

I essentially did that already by only renaming the Application Support folder. (the first one you meniton). The LSSharedFileList.plist, transmission.plist, and the Caches/ folder were all retained (from the non-working environment) in a successful test with the current (nightly) build. Furthermore, as I mentioned, I also had a successful test with the blocklist folder within the Application Support/Transmission folder copied over from the non-working environment.

The problem, therefore, must reside in one of the following files and folders:

dht.dat
Resume/
stats.json
Torrents/
Transfers.plist

[metaclam]

Basically, if the issue persists, you need to at least remove the Resume folder and rebuild it by verifying local data, however, if you are unwilling to do that it would be impossible to help you.

It's not that I'm unwilling, it's just that:

a) given the time it would take it would be a very, very last resort and I couldn't do it for some time

and more importantly:

b) that doesn't help solve what seems to be a rare but serious problem experienced by some, which totally cripples Transmission

I would hope to be able to help isolate the cause, so that an update to T. could cope with whatever is causing this glitch, possibly rebuilding whatever file is damaged when necessary.

Failing that, I wonder if it would be possible to write some kind of script to take a folder of .torrent files and use spotlight to match them to their actual locations in the file system, and re-add them semi-automatically? Or build something like this function into T. itself?

Also, I would think that what I reported that you quoted below would provide a decent clue to where to start? I mean if we can agree that it's not the trackers, what could T. be doing (or failing to do) that would produce this display in the inspector, and why?

Last Announce: N/A
Announce is Queued
Last Scrape: N/A
Seeders: N/A
Leechers: N/A
Downloaded: N/A

I have one more question about this. Did you try a manual pause-resume on any of these "stuck" torrents? What was the result?

Yes, I did, several times, on several different torrents, from several different trackers. Same result.

[macpacs]

2.32 is a disaster on my MacPro, too.

All or many of the torrents will pause for no apparent reason (both seeding and downloading).
The inspector window will open with strange proportions, the about window will not open.
Rebooting the Mac will restore everything to normal for a few minutes, then it goes crazy again.
The main transmission window will go crazy, too. the icons will changes size, the entries overwrite each other
and then it will go back to normal all on its own!

[macpacs]

Hello,

Thank you. I removed the Application Support folder and added some torrents back in
and all is well. I noticed that the "Torrents" folder had torrents from as far back as 2007
which were not in use.

Cheers!

[metaclam]

I'm glad macpacs got it working, and as I said above I'm sure I could too if I was able to add back 2000 torrents manually. Still hoping to help find a fix for the existing broken situation, and/or at least get some ideas about whether a scripted solution for adding back torrents could be possible. Thanks.

[Jordan]

I'm wondering why removing the app support folder, and then re-adding torrents back in, has any affect. Is it a placebo? Is it a side-effect of resetting the settings to the factory defaults? I don't know.

x190, what made you suggest those steps?

[metaclam]

Jordan -- in my case at least as I said, resetting settings is not the issue at all. it seems quite clear to me that there are two possibilities:

1) something is corrupted in one of these files:

Code: Select all

dht.dat
Resume/
stats.json
Transfers.plist

2) 2000 is too many torrents

If MacPacs and my case is the same, then we can presume that we can eliminate #2.

So adding them back will obviously rebuild the .resume files. I don't know about dht.dat, stats.json, and Transfers.plist. Having looked at Transfers.plist, that strikes me as a reasonable candidate as well.

But you're the devs! Suggestions, please? I'd really like to get my full seeding library back up and going. (I figure adding 2000 torrents manually, whose data files are spread around my file system, is going to take > 24 hours of work to do! Hardly thinkable.)

[Weevil]

My current theory is that something in 2.31 or 2.32 corrupted some settings or resume files. Possibly after a forced quit (power interruption or system freeze).

Same here, when returning all the Resume files into a clean install recreates the bug, when experimenting with putting back one Resume file it works fine so far.