4
Calendar problems after upgrade to Version 14.5.5871
Problem reported by Mark Thornton - 4/10/2016 at 5:06 PM
Submitted
Moved from version 11.x to 14.5.5871 and ran into several problems in the calendar portion of the app.
 
1. Switching to the calendar mode or updating the calendar display while in month display mode is VERY slow, between 15 to 30 seconds to display. Under version 11 was a couple of seconds like updating in weekly display mode. Any idea why?
 
2. Adding attendees to a shared calendar does not send out invitations. Is there a setting we've missed? Personal calendars do send out invites.

38 Replies

Reply to Thread
1
Mark Thornton Replied
I opened a ticket on this and it is being looked at.
 
The speed problem appears to be associated with the shared calendar. ours is 1,180 KB in size. One of the users most impacted has a personal calendar that is 435 KB in size. If I turn the shared calendar display off, the monthly calendar updates in two seconds or less. If I enable the shared calendar it takes 15 or so seconds to update. It doesn't seem the time is related to the size of the file. 
 
I did notice that the problem doesn't seem to occur when we select the All Appointments tab. It populates very quickly and updates as you scroll. It seems like the disk access is working OK in that case. It appears the problem is when the calendar display routines are trying to merge the calendars for display in a calendar format. I'm going to talk to the users about possibly deleting old, past dated appointments.
1
Paul Blank Replied
1,180KB? That's one megabyte, not one gigabyte (I had to read your post again to be sure). Not a very large file here in the 21st century. As you've said, doesn't look as if this should be the cause of the delays you're talking about. Either way, it seems to need some attention on the programming side.
1
Mark Thornton Replied
Yep, 1,180KB. Today it is 1,183KB because little miss calendar user keeps adding to it. Her personal calendar has grown to 456KB in a couple of days. It is by far the largest personal calendar.
 
You are right, 1,180KB isn't much. It is 1200 or so appointments. I think the problem is in the routine that shuffles the appointments into the calendar display, particularly whatever portion of that routine deals with a shared calendar. I can't imagine why that would be different from reading a personal calendar but I'm not looking at the code.
 
I'm getting a bit of pushback on the idea of deleting old appointments from the user. They like having this as a record of meeting dates.
0
Paul Blank Replied
>>I'm getting a bit of pushback on the idea of deleting old appointments from the user. They like having this as a record of meeting dates<<

And that is completely understandable! Hoping ST can do something about those delays,
1
Paul Blank Replied
Just thought of this: You can try having the user keep the calendar open in another browser tab or a different browser session entirely.  This way it only needs to load once. Takes a little bit of getting used to, but it may help the situation; wouldn't help much for updating, I know, but still.
0
Mark Thornton Replied
The complaints tend to come from the delay involved when they add an appointment, or edit an appointment, which in turn updates the display. Good idea for reference only, but miss calendar girl is trying to save the world via appointments.
0
Paul Blank Replied
The user does have a point, unfortunately. But so do you! If the delays weren't bad in the last version, it stands to reason that it really shouldn't be worse in the newer version.
0
That is what i do. Keep a seperate window open with my calendar. But even with that, it still takes forever (sometimes as much as 45 seconds) to post an appointment once i save it, and then switching to another month takes forever and a day yet (sometimes over a minute)
www.HawaiianHope.org - Providing technology services to non profit organizations, low income families, homeless shelters, clean and sober houses and prisoner reentry programs. Since 2015, We have refurbished over 11,000 Computers !
2
Mark Thornton Replied
Update on this issue: My client contacted me today and clarified their concerns. While the speed of update in the calendar is ugly, it can be somewhat dealt with my staying in the week display mode. What has not been resolved is the lack of invitations from the version 14 shared calendar. This is ramping up to be a deal breaker. We are currently looking at scheduling downtime for a complete downgrade to version 11 to address this specific issue. I'm trying to avoid that as the issue is supposed to be in front of the developers, but in reading through the threads here it appears there are a lot if issues more critical before the developers right now. My client uses the webmail exclusively on computers and has generally been happy with it. I've considered looking at Outlook as a client to get around the calendar issue but now I am reconsidering that based on the problems reported on that front. I understand it is affecting only a small number but I know my luck. My client would be one of those affected. They have a cloud over them and can imagine a problem if given enough time. Version 11 worked in most respects so that may be safest for me.
 
The thing I have been trying to figure out is how I can test a new version under similar load and configuration for my client before deploying it. There are licensing issues, as well as port conflicts to be dealt with. How are others dealing with testing a new version prior to deployment?
0
Mark Thornton Replied
If we were to choose to move to Outlook as a client to version 14, would that resolve the invitation problem in the shared calendars? Does outlook handle generating the notifications or is SmarterMail still doing that?
1
Paul Blank Replied
I am hoping for a fix to this problem as well.  SM Version 11 has been working wonderfully for one client of mine; the only real issue being occasional disconnection of the webmail client (even directly on the same LAN as the mail server), but most users have been set up for one-click login to webmail while in-office, so it's no big deal. This installation uses Symantec email security.cloud for external spam filtering, so that overhead is eliminated - both in greatly reduced incoming email volume and server processing time.  And NOBODY uses Outlook (yay).
 
Since ST is (rightfully) promoting the use of their webmail client, the calendar issue is a biggy. When this is resolved - OK and a few other things - the customer just might move to v15 (or greater).
 
2
Simon Collingridge Replied
I have precisely the same issue, also with a shared calendar although my users file is 14MB - still not that big.
 
They had no problems with it when they were running version 5.x (yes I meant 5.x), it worked fine for them in that version but now they're using v 14.6 they have really slooowwwww speeds.
 
Over 65 seconds to save a new appointment!
 
I've uninstalled and reinstalled, deleted and recreated index files etc. but to no avail. Users who have an empty calendar have no issues saving new appointments.
 
I too think I'll have to go down the support ticket route, but doesn't sound like I'll get a resolution soon.
 
Poor users are pulling their hair out and I can understand why.
 
1
Assin Ontivi Replied
Quite a serious issue.  If you do open a ticket, would you kindly let us know if anything comes of it? Thank you.
0
Simon Collingridge Replied
Of course, ticket has already been opened and I'm now waiting for their reply.
1
Mark Thornton Replied
I have a ticket open on both of the issues I mentioned in the original post. I am now testing a patch for the invitations issue and should have some confidence in the solution soon. I was told they are now looking into the speed issue. I provided them with the calendar files that were causing the issue so they can replicate it.
 
As an interim fix, I did go into the shared calendar xml file and deleted all of the old appointments. I made a copy of the file so I can past them back in when they have the problem resolved. The monthly calendar updates much faster now, though still not as fast as we were used to in version 11. Most of the users at my client now operate in the weekly calendar mode which is much faster.
0
Assin Ontivi Replied
Thanks, Simon and Mark. These issues have been reported for some time now, and ST has been a bit quiet on this. 
1
Simon Collingridge Replied
Thanks Mark. I'm don't know if my users are having the invitation issues, but where did you get the patch? Are you still running v14. 5? If ST take too long to figure it out, my plan was to script moving all old appointments from the live calendar XML to a new archive calendar each night (anything over 30 days old) and in doing so hoping that the performance improves for the live calendar, but leaving them still with the ability to review their appointment history whenever they need to, which is important to them. It's good to hear deleting the old appointments has made some improvement for your users.
0
Paul Blank Replied
I can't do that kind of fix (even temporary) here. Folks would be quite miffed if they couldn't have all their old calendar data in the same place as the current data. Heck, it would even bother me, big time. Hoping for a real fix here.
2
Mark Thornton Replied
Simon, the fix came from ST and it is actually a later test build. My client is still beating it up but I am hoping to get some good word from them today as to whether they could break it.
 
Paul, I agree with you. The exception is my client and the apparent fact they don't use or care about past appointments at this time so it allowed me to do the experiment. In my place of business past appointments and invitations are important records.
 
I'm hoping it won't be too long before there is a resolution. I don't know if this has been brought to the attention of the developers before. It may have been discussed here or with some support folks but I have found if it doesn't reach the developers there isn't much chance of a resolution. In truth, SmarterTools is only the third company I've worked with in my career of 30+ years where the developers took an interest, much less actually worked on a problem I have reported. Cisco was the best at it. For some reason my Cisco DSL aggregation router found three different bugs in the code. Cisco support was phenomenal back then, and when they confirmed it wasn't working as expected a developer was quickly pulled onto the ticket.
 
0
Mark Thornton Replied
Update: my client confirmed the fix for the invitations from a shared calendar is working and I have reported that back to ST support. I have also asked for an update on the speed issue. I have no idea when or how the invitations fix will be rolled out in the general release.
0
Assin Ontivi Replied
... I have also asked for an update on the speed issue ...
 
Still waiting on ANY word from ST about this issue.
0
Simon Collingridge Replied
Yeah, all I've had is the following response from support:

Hello Simon,
I'm going to need to review this with our developers. I will let you know as soon as I have any more information. In the meantime, please let me know if you have any other questions.

That's worth $50 of anyone;s money..........
2
Mark Thornton Replied
I've got an update to test this evening on the speed issue. I will let you know the results ASAP. I actually got the update last week but have been out on vacation. Sorry for the delay.
0
Paul Blank Replied
Thanks, Mark!
0
Simon Collingridge Replied
Sorry, I should have posted an update. I received a custom build to address the speed issue last week.

I've installed it and it made no difference whatsoever.

I've reported it to ST but not had a response.
0
Mark Thornton Replied
I installed the custom build provided by SmarterTools and did see a significant performance improvement. I edited my shared calendar xml file to add back in the appointments I had removed, taking the file back up to 1,223 KB. The screen refreshes when changing between weekly and monthly views is now 3 seconds for both. Before installing the new build the monthly view took 15 or more seconds to update. An added improvement is the busy bar now appears when the new view is loading, where the previous builds had nothing indicating the system was processing the view change at all.
 
We will be running more tests in the morning, such as adding appointments in the monthly view. That was very tedious before. I will also be reporting to support and the developers in a few minutes. 
 
I'm sorry to hear Simon didn't have similar results. Not sure what may be going on there.
1
Simon Collingridge Replied
Hi Mark What version number was your custom build? Ours was They did say it should improve the month view page last times, but this is what we're currently experiencing (our customer's calendar xml is 14mb) : Save new or edited appointment : 1 min 6 seconds Open appointment : 13 seconds  Delete appointment : 40 seconds  Open day view : 2 seconds  Open week view : 6 seconds  Open month view : 30 seconds  Open all appointment view : 2 seconds
0
Simon Collingridge Replied
Our custom build version is 14.6.5974
0
Mark Thornton Replied
That was the version I installed as well. My calendar.xml file is much smaller but I did see a difference. The performance is pretty close to what I remember on version 11.X before I upgraded. Other users are saying it is a little slower but I always remember it being about 3 seconds to move between views. I just added a new shared calendar appointment and it also took about 3 seconds.
0
Mark Thornton Replied
I just communicated with support and they acknowledge there are still issues with big calendar files and they are continuing to work on the problem.
0
Simon Collingridge Replied
Yeah, I've just had an email from them saying that it is a big file, but they're still looking into it.

I suggested they started by looking at v5.x because that manged a file of that size perfectly well when they are using that version earlier this year.

Fingers crossed they find something soon.
0
Assin Ontivi Replied
**  I suggested they started by looking at v5.x because that managed a file of that size perfectly well when they are using that version earlier this year. **  (Simon Collingridge)
 
Hear that, ST?
 
 
 
0
Mark Thornton Replied
I think it is HIGHLY unlikely SmarterTools will go back and look at version 5 code. There will be so few similarities, and the programming tools and libraries will have changed so much that comparison would likely yield dubious results. A more valuable metric would be to determine at what recent major version upgrade the problem occurred. I noticed it when moving from version 11.x to 14.x. I don't have a spare machine I can load up server versions on to test this, nor do I have a big enough calendar file to make the issue obvious for me. It would be MUCH more helpful to identify if the problem occured at version 12 or whatever.
 
0
Assin Ontivi Replied
If course you are right, Mark. My point is that in regard to this problem, SM is regressing; this is in my opinion an issue of some magnitude, that needs to be resolved quickly. The lack of response by ST is disconcerting.
0
Simon Collingridge Replied
I'm with you Assin.

No one is actually expecting ST to dust off and reuse code from years ago, and certainly I have no intention of trawling through every version just so I can tell them what version it started to go wrong - surely that's for ST to do.

But it can't be considered progress that in this day and age, with all the advances in technology and improvements in server hardware, RAM and disk arrays, something that worked efficiently has become so slow and laggy when handling exactly the same data.

Surely they could look at v5.x to review the approach they had then, and see what efficiencies they have lost in more recent developments.
0
Paul Blank Replied
I am watching this thread with great interest. Hoping for some good news from ST.
 
0
Paul Blank Replied
I am cross-referencing another thread (in which I've cross-referenced this thread as well)...
 
 
 
0
Giorgio Borra Replied
Thank you Paul for cross-referencing my thread.
I opened a ticket, I'm waiting for the resolution.

Giorgio

Reply to Thread