4
Calendar problems after upgrade to Version 14.5.5871
Problem reported by Mark Thornton - April 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.

22 Replies

Reply to Thread
1
Mark Thornton Replied
April 13, 2016 at 11:02 AM
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
April 14, 2016 at 4:39 AM
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
April 14, 2016 at 7:45 AM
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.
1
Paul Blank Replied
April 14, 2016 at 8:22 AM
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.
2
Mark Thornton Replied
April 20, 2016 at 10:23 AM
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?
1
Paul Blank Replied
April 24, 2016 at 9:01 AM
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
May 5, 2016 at 7:53 AM
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
May 5, 2016 at 8:09 AM
Quite a serious issue.  If you do open a ticket, would you kindly let us know if anything comes of it? Thank you.
1
Mark Thornton Replied
May 5, 2016 at 11:31 AM
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
May 5, 2016 at 11:35 AM
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
May 5, 2016 at 10:09 PM
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
May 6, 2016 at 5:34 AM
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
May 6, 2016 at 10:03 AM
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
Assin Ontivi Replied
May 8, 2016 at 10:50 AM
... I have also asked for an update on the speed issue ...
 
Still waiting on ANY word from ST about this issue.
2
Mark Thornton Replied
May 17, 2016 at 12:04 PM
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
Mark Thornton Replied
May 18, 2016 at 12:38 AM
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
May 18, 2016 at 1:38 AM
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
Assin Ontivi Replied
May 19, 2016 at 4:33 AM
**  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
May 19, 2016 at 7:52 AM
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
May 20, 2016 at 8:43 PM
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
Paul Blank Replied
May 22, 2016 at 6:44 AM
I am watching this thread with great interest. Hoping for some good news from ST.
 
0
Paul Blank Replied
May 23, 2016 at 11:05 AM
I am cross-referencing another thread (in which I've cross-referenced this thread as well)...
 
 
 

Reply to Thread