Transmission takes forever to quit
Re: Transmission takes forever to quit
same trouble 10.6.2x64/ 1.92+ r10389
Re: Transmission takes forever to quit
Transmission v1.92.10363. Transmission v1.76 does not exhibit this problem.
Bug Report:
Here are the details for this "not responding" crash on quit problem that has existed since version 1.8 onward. Further Console logs are included at: http://transmission.pastebin.com/Zm0tAPad.
While active, Transmission operates fine. Upload and download functions normally. The problems present only when quitting. This happens no matter how many torrents are running or paused. I have waited up to 10 minutes before hitting quit and it still happens. Once port forwarding is established, only way to exit Transmission now is to force quit. I am using a 2Wire 3800HGV-B Wi-Fi router to connect to the Internet, which is what AT&T provides for their U-verse TV & Internet service. I have set port forwarding through the router successfully.
Recipe:
If I launch Transmission and I select quit immediately, it quits normally. If I let the port forwarding establish and the port forwarding LED turns green and then try to quit, it hangs and must be force quit.
3/29/10 7:42:27 AM com.apple.quicklook[54595] quicklookd[54595]: [WSX] Will not load into com.apple.QuickLookDaemon as the hard coded exclude list says no.
3/29/10 7:42:27 AM com.apple.quicklook[54595] quicklookd[54595]: [WSX] Will not load into com.apple.QuickLookDaemon as the hard coded exclude list says no.
3/29/10 7:42:27 AM com.apple.quicklook[54595] quicklookd[54595]: [WSX] Will not load into com.apple.QuickLookDaemon as the hard coded exclude list says no.
3/29/10 7:42:34 AM com.apple.launchd[162] ([0x0-0x7a07a].org.m0k.transmission[53003]) Stray process with PGID equal to this dead job: PID 53821 PPID 1 QTKitServer
3/29/10 7:42:34 AM com.apple.launchd[162] ([0x0-0x7a07a].org.m0k.transmission[53003]) Exited: Terminated
3/29/10 7:42:34 AM com.apple.coreservicesd[82] NOTE: Using non-mach-based version of client -> server communication, via direct function calls.
3/29/10 7:42:34 AM com.apple.coreservicesd[82] NOTE: Using non-mach-based version of client -> server communication, via direct function calls.
3/29/10 7:42:34 AM com.apple.UserNotificationCenter[54644] UserNotification[54644]: [WSX] Will not load into com.apple.UserNotificationCenter as the hard coded exclude list says no.
3/29/10 7:42:34 AM com.apple.UserNotificationCenter[54644] UserNotification[54644]: [WSX] Will not load into com.apple.UserNotificationCenter as the hard coded exclude list says no.
3/29/10 7:42:34 AM com.apple.UserNotificationCenter[54644] UserNotification[54644]: [WSX] Will not load into com.apple.UserNotificationCenter as the hard coded exclude list says no.
Bug Report:
Here are the details for this "not responding" crash on quit problem that has existed since version 1.8 onward. Further Console logs are included at: http://transmission.pastebin.com/Zm0tAPad.
While active, Transmission operates fine. Upload and download functions normally. The problems present only when quitting. This happens no matter how many torrents are running or paused. I have waited up to 10 minutes before hitting quit and it still happens. Once port forwarding is established, only way to exit Transmission now is to force quit. I am using a 2Wire 3800HGV-B Wi-Fi router to connect to the Internet, which is what AT&T provides for their U-verse TV & Internet service. I have set port forwarding through the router successfully.
Recipe:
If I launch Transmission and I select quit immediately, it quits normally. If I let the port forwarding establish and the port forwarding LED turns green and then try to quit, it hangs and must be force quit.
3/29/10 7:42:27 AM com.apple.quicklook[54595] quicklookd[54595]: [WSX] Will not load into com.apple.QuickLookDaemon as the hard coded exclude list says no.
3/29/10 7:42:27 AM com.apple.quicklook[54595] quicklookd[54595]: [WSX] Will not load into com.apple.QuickLookDaemon as the hard coded exclude list says no.
3/29/10 7:42:27 AM com.apple.quicklook[54595] quicklookd[54595]: [WSX] Will not load into com.apple.QuickLookDaemon as the hard coded exclude list says no.
3/29/10 7:42:34 AM com.apple.launchd[162] ([0x0-0x7a07a].org.m0k.transmission[53003]) Stray process with PGID equal to this dead job: PID 53821 PPID 1 QTKitServer
3/29/10 7:42:34 AM com.apple.launchd[162] ([0x0-0x7a07a].org.m0k.transmission[53003]) Exited: Terminated
3/29/10 7:42:34 AM com.apple.coreservicesd[82] NOTE: Using non-mach-based version of client -> server communication, via direct function calls.
3/29/10 7:42:34 AM com.apple.coreservicesd[82] NOTE: Using non-mach-based version of client -> server communication, via direct function calls.
3/29/10 7:42:34 AM com.apple.UserNotificationCenter[54644] UserNotification[54644]: [WSX] Will not load into com.apple.UserNotificationCenter as the hard coded exclude list says no.
3/29/10 7:42:34 AM com.apple.UserNotificationCenter[54644] UserNotification[54644]: [WSX] Will not load into com.apple.UserNotificationCenter as the hard coded exclude list says no.
3/29/10 7:42:34 AM com.apple.UserNotificationCenter[54644] UserNotification[54644]: [WSX] Will not load into com.apple.UserNotificationCenter as the hard coded exclude list says no.
Re: Transmission takes forever to quit
What I've noticed in a little experiment:
When I have only one small torrent going (small amount of data in the files that need downloading) time to quit is very small.
When I have large torrents downloading, time to quit is large, but especially the first time I quit, after having added the new torrent.
The more large torrents I have going, the longer it usually takes to quit. But, when only seeding (even with large torrents) it usually quits pretty much instantly.
I have also looked at my system resources when I quit Transmission and here are the findings:
----- Quit Transmission while downloading 1 torrent, multiple files, large size (3GB) ------
This torrent was added in a previous session.
Time it took to quit: About 20 seconds.
CPU activity: Normal (around 7%)
Disk activity: Normal (little bit of IO and data)
Network activity: Low (no data, very few packets)
----- Quit Transmission while downloading 1 torrent, multiple files, large size (3GB) ------
Time it took to quit: About 1 minute.
CPU activity: Normal (around 7%)
Disk activity: HIGH (lots of data write. Between 20 and 40MB/s)
Network activity: Low (no data, very few packets)
So the big difference seems: When a new file is added to Transmissions, it flushes a lot of (temporary?) data out to disk on quit, if the download isn't finished. When files already existed, I suppose it moves some parts around, which causes some wait time, but not that much.
Does that hypothesis seem like something Transmission does in its internals?
Hope this helps!
When I have only one small torrent going (small amount of data in the files that need downloading) time to quit is very small.
When I have large torrents downloading, time to quit is large, but especially the first time I quit, after having added the new torrent.
The more large torrents I have going, the longer it usually takes to quit. But, when only seeding (even with large torrents) it usually quits pretty much instantly.
I have also looked at my system resources when I quit Transmission and here are the findings:
----- Quit Transmission while downloading 1 torrent, multiple files, large size (3GB) ------
This torrent was added in a previous session.
Time it took to quit: About 20 seconds.
CPU activity: Normal (around 7%)
Disk activity: Normal (little bit of IO and data)
Network activity: Low (no data, very few packets)
----- Quit Transmission while downloading 1 torrent, multiple files, large size (3GB) ------
Time it took to quit: About 1 minute.
CPU activity: Normal (around 7%)
Disk activity: HIGH (lots of data write. Between 20 and 40MB/s)
Network activity: Low (no data, very few packets)
So the big difference seems: When a new file is added to Transmissions, it flushes a lot of (temporary?) data out to disk on quit, if the download isn't finished. When files already existed, I suppose it moves some parts around, which causes some wait time, but not that much.
Does that hypothesis seem like something Transmission does in its internals?
Hope this helps!