Hi, again...
On 05/31/12 10:47 am, Michael Secord thus wrote :
<snip>
>>>>
>>> As such problems usually are, can easily be attributed to multiple
>>> causes, some of which we have no control over...
>>>
>>> The only thing I can add to this, is I've had it happen on 3 different
>>> machines, across 2 different operating systems, 2 different locations,
>>> and 4 different network setups, and it always comes back to the same
>>> issue.
>>>
>> Well, that probably eliminates hardware, operating systems, network
>> connections, and broadband. Are the TB, Lighting, and Provider versions
>> the same between the two? I'm assuming (dangerous to assume) that both
>> of these systems are connecting to the same Google calendar(s) and that
>> other elements of their configuration are similar (number of email
>> accounts, extension mix, etc.).
> Versions are the same between them all, one of the machines and the
> alternate os (OSX) runs a different setup than the other machines (I
> use TBird portable across them all), in that it only has 1 account and
> hardly any extensions outside of Lightning and Provider.
>
That's good (few extensions). Invariably, I need to either disable all
of mine for testing or use a fresh profile, which is always a pain to
set up.
> It is a good assumption that it's all with the same google calendar on
> the same google account though.
>
Good. The more similarities, the better (obviously).
<snip>
>> Do you have a number of alarms set or
>> recurring events?
> I almost never use alarms in the calendar, but there are a few
> recurring events scattered throughout the calendar. It just seems to
> happen after I open the calendar, then double-click to add a new entry
> and after I enter 1 or 2 characters (not sure if this is actually a
> trigger, I Just start typing right away so I don't know for sure) it
> will hang for ~10s, then come back for ~1-2s, then hang again. At this
> point though I'm usually done entering and just save it, so I don't
> know if the loop continues.
>
Interesting. I'll keep an eye on mine to see if I experience anything
similar. Thanks for the additional detail, which always helps.
I use a fair amount of alarms, and I have a couple monthly recurring
events. Calendar startup can be slow for me - at times. The
inconsistency of it leads me to believe that the problem is on Google's
side of the connection (ditto for gContactSync, which seems to be
behaving well thus far today).
If you open the calendar and then just browse around, without making an
entry, how does it behave? When you switch views to say, weekly or
monthly, and then back again, does that make a difference?
Finally (as I'm thinking about it), do you have any read-only remote
calendars which are using CalDAV and not Provider? I have several of
these for holidays and such. Loading these up sometimes can take some
resources (but would have little or no bearing on entering events,
obviously). I should turn these off and see how calendar startup time is
after a restart of SeaMonkey. This might account for doifferences
between the two of us insofar as startup is concerned (which is where I
see the greatest lag, and you apparently don't).
<snip>
>>>> Also, for both of you, what version of Provider are you running, and
>>>> what version of Lightning?
>>> Lightning 1.4
>>> Provider for Google Calendar 0.13
>>>
>> You might want to try a nightly build, just for the heck of it. Frankly,
>> though, I haven't seen much performance difference between 0.11 and
>> 0.16pre.
> The last few times I've tried nightly builds of Lightning/Provider, it
> all just stopped working entirely...so I'm a bit hesitant, though it's
> likely that the Lightning nightly was the cause, not Provider..
>
I understand. I agree, however, that upgrading Provider is probably less
problematic (at least to 0.16pre, as I'm using) than a new Lightning
build. On OS/2, our latest Lightning is 1.2.3, and Provider 0.16pre runs
fine under that. I'm fairly certain that you should have no issues with it.