Checking existing data goes beyond 100%

[Ranko]

When Transmission forces an existing data check, (after a crash), data check percentage number does not start from zero, it will be at 70% for example, and will not change until the actual check reaches that point, then it will count up as normal. After reaching 100%, the number hangs, (client is still responsive), while disk activity remains high, as if still checking data. Checks take approximately twice as long when left unattended, and pausing the torrent and resuming after it has reached 100% stops the check and starts the torrent normally.

Problem existed in 1.9, exists in 1.91 and 1.91 daily build 10297.

The crashes leading up to the forced checks appear to be related to starting a large number of large torrents simultaneously, but I currently have no crash data. If it crashes again I'll post the crash log.

[livings124]

Which number do you refer to, the number above the progress bar or the one below showing the percent verified?

[Ranko]

Replying to livings124:

Which number do you refer to, the number above the progress bar or the one below showing the percent verified?

Percent verified.

[livings124]

I cannot replicate that, but that value is simply tr_stat's recheckProgress.

[mukke]

might have a similar problem here my version is 1.92 (10363) on Mac OS X 10.6.2 on a MacBook?

it stops at checking data on a percentage between 90% and 99%. If i pause and resume it stays at the same number If i quit and restart Transmission it retries the checking but it will end up at another value between 90 and 99% and this for a 300 MB single file.

After leaving it open for like an hour it starts checking it slowly. Is this the checking display wrong error and take the 95.3% as absolute zero and starting from there or is there a reason why it it just slow as hell.

I had it with 1.91 aswell and did the update to try to resolve it. I have a screenshot of it.

this is from my console.log

25/03/10 04:50:46 [0x0-0x685fd595].org.m0k.transmission[32458] [04:50:46.205] Starting libevent thread 25/03/10 04:51:01 Transmission[32458] Error loading /Library/Audio/Plug?-Ins/HAL/DVCPROHDAudio.plugin/Contents/MacOS/DVCPROHDAudio: dlopen(/Library/Audio/Plug?-Ins/HAL/DVCPROHDAudio.plugin/Contents/MacOS/DVCPROHDAudio, 262): no suitable image found. Did find:

/Library/Audio/Plug?-Ins/HAL/DVCPROHDAudio.plugin/Contents/MacOS/DVCPROHDAudio: no matching architecture in universal wrapper

25/03/10 04:51:01 Transmission[32458] Cannot find function pointer NewPlugIn? for factory C5A4CE5B-0BB8-11D8-9D75-0003939615B6 in CFBundle/CFPlugIn 0x1003f7560 </Library/Audio/Plug?-Ins/HAL/DVCPROHDAudio.plugin> (bundle, not loaded) 25/03/10 04:52:39 [0x0-0x686375cf].org.m0k.transmission[32523] [04:52:39.823] Starting libevent thread 25/03/10 04:53:09 Transmission[32523] Sparkle Error: An error occurred while downloading the update. Please try again later. 25/03/10 04:53:09 Transmission[32523] Sparkle Error (continued): unsupported URL 25/03/10 04:53:53 [0x0-0x686375cf].org.m0k.transmission[32523] "disk3" unmounted. 25/03/10 04:53:53 [0x0-0x686375cf].org.m0k.transmission[32523] "disk3" ejected. 25/03/10 04:54:19 [0x0-0x6865c5f4].org.m0k.transmission[32590] [04:54:19.214] Starting libevent thread 25/03/10 04:54:52 com.apple.launchd.peruser.501[555] ([0x0-0x5474c6f8].org.m0k.transmission[49934]) Exited: Killed 25/03/10 04:54:52 Transmission[32590] Error loading /Library/Audio/Plug?-Ins/HAL/DVCPROHDAudio.plugin/Contents/MacOS/DVCPROHDAudio: dlopen(/Library/Audio/Plug?-Ins/HAL/DVCPROHDAudio.plugin/Contents/MacOS/DVCPROHDAudio, 262): no suitable image found. Did find:

/Library/Audio/Plug?-Ins/HAL/DVCPROHDAudio.plugin/Contents/MacOS/DVCPROHDAudio: no matching architecture in universal wrapper

25/03/10 04:54:52 Transmission[32590] Cannot find function pointer NewPlugIn? for factory C5A4CE5B-0BB8-11D8-9D75-0003939615B6 in CFBundle/CFPlugIn 0x1003f4c60 </Library/Audio/Plug?-Ins/HAL/DVCPROHDAudio.plugin> (bundle, not loaded) 25/03/10 04:54:52 Transmission[32590] Error loading /Library/Audio/Plug?-Ins/HAL/DVCPROHDAudio.plugin/Contents/MacOS/DVCPROHDAudio: dlopen(/Library/Audio/Plug?-Ins/HAL/DVCPROHDAudio.plugin/Contents/MacOS/DVCPROHDAudio, 262): no suitable image found. Did find:

/Library/Audio/Plug?-Ins/HAL/DVCPROHDAudio.plugin/Contents/MacOS/DVCPROHDAudio: no matching architecture in universal wrapper

25/03/10 04:54:52 Transmission[32590] Cannot find function pointer NewPlugIn? for factory C5A4CE5B-0BB8-11D8-9D75-0003939615B6 in CFBundle/CFPlugIn 0x1003f4c60 </Library/Audio/Plug?-Ins/HAL/DVCPROHDAudio.plugin> (bundle, not loaded) 25/03/10 04:55:09 [0x0-0x686a9641].org.m0k.transmission[32669] [04:55:09.057] Starting libevent thread 25/03/10 04:58:59 [0x0-0x68a449dc].org.m0k.transmission[33597] [04:58:59.807] Starting libevent thread

doubt it has anything to do with it though anyway, it just anoying, hope it helps some1

[charles]

I'm having difficulty reproducing this error. Please answer these questions:

• Is this reproducible?
• If so, what specific steps should we take to recreate this bug?

This will help us to find and resolve the problem.

[charles]

We'd like to figure out what's causing this bug for you, but we haven't heard back from you in a while. Could you please provide the requested information? Thanks!

[tonin]

I have the same behaviour as the original poster (Ranko) with 1.93 on MacOSX 10.6.3. The way to reproduce this on my machine is as follows:

• start a downloading torrent
• crash transmission
• restart transmission and let the verify process begin for a while
• crash transmission before the verify process completes (waiting for it to be close to the end of the verifying process, let's say about 90%)
• restart transmission and restart the torrent that was in verifying mode, you'll then see
  • the verify percentage displayed is not 0% but the same value it was when the crash happened in the middle of the verify process
  • the verifying process seems to be slower than before the crash (if you look at the verifying percentage displayed), suggesting that the verify process actually restarted at 0% and that the displayed percentage is wrong,
  • when the verify percentage displays 100%, the verify process doesn't stop, even if left for some minutes (so doesn't seem to be a rounding effect),
    • if you then (when displaying 100% but still in the verify mode) stop the torrent and then restart it right away, the torrent just start downloading again as if the verify mode was completed,
    • if you don't touch it but let it continue the verifying, it will eventually ends, but stays a very long time displaying 100%.

Does this better describes the behaviour? This is better seen with big (many GB) downloads.

What is actually the correct behaviour when transmission crashes in the middle of a verifying process: restart verify at some checkpoint before crash or restart verify from 0%?

[charles]

This is describing the same issue as #3234, which is fixed by r10695

Thanks for listing out the steps required to make this behavior happen... I wouldn't've been able to figure out what was causing the problem half as easily without them. :)