Sync prohibitively slow to start, freezes Firefox (D111192413)

mark
Since recently I find that the sync is prohibitively slow, to the extent that it freezes Firefox for a few minutes. This is not the actual syncing operation however, which — including files — is actually completed quite quickly.

Here is a debug log for the operation: D111192413. I'm not sure how to locate the source of the lag, but hopefully you can see something. I'm on FF3.5.1/Windows XP.

I do see a lot of messages like "Mod time didn't match but hash did for Cameron - 2006 - Verbal Hygiene.pdf -- ignoring". I wonder whether this is related to this issue.
  • dstillman
    It's likely the same issue.

    I've added some additional debugging info to the latest dev build. If you wanted to install that build and provide a new Debug ID, we might be able to figure out why you're getting this. (We're about to release the next version, so the trunk should be pretty stable, but you obviously should make sure you have a backup.)
  • mark
    Sorry, too busy to mess with installing another version etc. now or in the coming days. Will it be included in the new version when released? Then I'd rather wait until that version.
  • dstillman
    Yes, that's fine.
  • mark
    Okay, I checked first without debug logging and it was still slow.
    Then I restarted an ran a sync with debug logging. D2002571250.
  • dstillman
    OK, those times are indeed all off by a second, so it's the same issue. We'll see if we can fix this for 2.0 Final.
  • dstillman
    This should be fixed in 2.0rc3, which now uses millisecond resolution for timestamps.
  • mark
    Okay. Will check over the weekend.
  • bardophile
    I seem to be having a similar problem, using 2.0rc5. Something like 944 conflicts to resolve, where there are only a handful of actual changes, mostly filename changes.
  • dstillman
    Provide a Debug ID for the sync attempt, up to the conflict resolution window.
  • mark
    Okay, here's my debug ID: D1273422249
  • mark
    Sorry, that was short because I had to run. But anyway, the most recent version didn't make the sync any faster I'm afraid.
  • dstillman
    Actually, 2.0rc3 would only have fixed the cause of this, but it wouldn't have addressed existing files. The latest dev build should.
  • szarka
    I seem to be seeing this same problem with 2.0rc5. Debug ID# D2046331054.
  • dstillman
    szarka: See my previous message.
  • adamsmith
    and in case that's not clear - "the latest dev build" refers to changes that will be in the next update of Zotero.
  • szarka
    OK, I got confused by the reference to rc3, but I hear you guys saying that this will be fixed in rc6 (or whatever comes after rc5) and I should just hang tight...
  • mark
    Ah, thanks Adam, I didn't realize that. I'll wait.
  • szarka
    Hmm... the first time I brought up the new 2.0 release, I got the usual slowness. But upon restarting, everything seems spiffy and I see lines like this in the logfile:

    File mod times are within one-second precision (1206062801468 ≅ 1206062801000) for 0.pdf -- ignoring

    So far, so good... :)
  • dstillman
    the first time I brought up the new 2.0 release, I got the usual slowness. But upon restarting, everything seems spiffy
    Yup. That's the expected behavior.
  • szarka
    *sigh* Still something weird going on, though I'm not sure yet whether it's the "same" issue. I just had 27 conflicts crop up out of the blue in my latest update, and they weren't due to some other installation syncing in between updates. These were things that have been in my database for ages, but seem to have had timestamps just magically update themselves to newer dates than what's in my local database (but not in the very recent past--dates like January 2010, or even back in 2009). Very weird...
  • mark
    I also had a couple of those (six or so). Never know where they come from. But I can confirm that the sync is back to normal speed in 2.0!
  • szarka
    I'm sorry to say that something possibly related to this issue just refuses to go away in the 2.0 final release. :( I have a recurring, annoying problem where I get about 30 sync errors at a time (seems to be the same items each time) where there doesn't seem to be any difference between the local and remote versions, and the problem crops back up even after I've gone through the resolution (but not every time). I'm guessing it has something to do with <1 second differences that have crept in somehow, but I don't have any evidence of that.

    Unfortunately, I can't submit the debug output. By the time I get to the end of the process, I have about 750000 lines of debug output, and submit to server fails every time I try to submit--I'm guessing due to size limitations? I'm not sure how to provide more information to try to help solve this. :(
  • mh
    Regarding : "I'm sorry to say that something possibly related to this issue just refuses to go away in the 2.0 final release. :( I have a recurring, annoying problem where I get about 30 sync errors at a time (seems to be the same items each time) where there doesn't seem to be any difference between the local and remote versions..."

    I have the same problem. Not so many sync errors -- only half a dozen -- but in each case the two versions look identical to me. More critically, I discovered today on an auxiliary machine that no actual syncs have completed from the main machine that I use since 2/22, thee days ago.

    At the moment the green arrow is still spinning away on it, as it has been doing for the last hour. No error messages. But probably no syncing is going on, if the last three days are any evidence.

    At least Firefox is not freezing up today, as it has in the last several days. CPU demand for it is relatively low -- not the usual 50% that froze it before.

    A progress meter of some sort would help, to show when the sync was actually working and when not.
Sign In or Register to comment.