Traveler 8.5.2.1 on HTC Desire Sync Issues

The situation: Our Domino mail server is 8.5.1 (and has to remain that way because of Quickr) so we have set up an additional Domino Server 8.5.2HF16 to run Traveler 8.5.2.1 connecting through to our mail server.

The Problem: We are connecting 6 handsets to traveler and are having issues syncing 4 of the handsets. 2 of the 6 handsets work ok and are connecting and syncing without any issues. The other 4 handsets are able to connect but will not sync. We are not using SSL and the handsets should be identical as they are organisation handsets all purchased at the same time from the same provider. Our Provider is 3. We are all using the same network and have this issue both internally using WiFi and externally.

Things tried so far:

… We have tried a factory reset on one of the phones and this makes no difference

… When a user who cannot connect using their own handset, connects using a handset that does work - things are fine, so we are thinking that it is less likely to be an issue with the mail file or domino settings

… We have tried to disable HTC Sense (based on another post) but it seems to be locked down. I cannot see any “options” or any way to open the application I can only manage it through settings, manage applications and the only options available to me are force stop and clear data and defaults all of which have been tried but as soon as I return to the homepage it restart sense again.

… We have swapped SIM cards and SD cards, no difference

… The software build numbers and software versions on the phones are all the same

Has anyone else had issues like this as we are now running out of things to look into.

This is a real problem for us as we have just invested in Android phones after successfully using Blackberry’s for a number of years.

Many thanks

Subject: Solution

After hour of research, trial and error we finally found the solution.

After doing a “tell traveler stat show” on the console. It showed that 6 out of the 9 devices were registered for TCP Notifications and 3 for HTTP Notifications. The device documents in the LotusTraveler.nsf all stated that Auto Sync Type is HTTP. So the 3 devices registered for HTTP Notifications works the other 6 don’t.

After changing the following settings on the device Lotus Notes Traveler now works. Note: this seems to be a setting on 3 Mobile Phones as Vodaphone HTC Desires don’t have this setting.

Select Menu from the Home Page

Select Settings

Select Wireless & networks

Select Mobile networks

Select Data roamimg

Select Automatic

Go to Lotus Notes Traveler and sync.

Once this is complete you can change the data roaming setting back if you wish and it will still work.

From the Domino Console enter “tell traveler stat show” and now all devices are registered for HTTP notifications.

Hope this helps someone else.

Subject: RE: Solution

I can explain the TCP/HTTP on the server status, but that wasn’t the real problem.

To maintain backwards compatibility with pre-8.5.2 clients (that only did TCP or SMS push), the default notification type is TCP. When the device connects to the server the first time, it will get set to TCP. Whenever the device actually connects to push, the notification type will be updated to whatever is really in use (TCP or HTTP). Thus, it said TCP because the client had yet to successfully connect via HTTP. As soon as it connected via HTTP, it was uploaded successfully.

The notification type of TCP or HTTP doesn’t really matter (it is mainly informational) as the server can send the message using whatever connection the device has open to the server at the time. Therefore, this wasn’t causing the real problem - it was just an indication that push wasn’t connecting.

Therefore, something in the networking changes you made on the device finally allowed push to connect (over HTTP). Given that you changed the roaming setting, I suspected it might be related to the new 8.5.2 setting for roaming detection which doesn’t allow Traveler to connect when roaming (by default - you can change how Traveler handles roaming in the Traveler settings). But that setting isn’t in the Android client yet (it is for WM and Nokia), so then that cannot be it.

Thus, I suspect it was related to the device and roaming somehow, but I’m not sure exactly how.

If you run into it again (or you still have it), it would be great to get a TPR from when you had the problem. That would tell us if the roaming is involved or not. If not, it might show some other network error that would make sense.

Subject: Driod not ready for prime time yet ???

Likewise, we are using verisign SSL with Domino 8.5.2 FP1 and traveler 8.5.2.1 and not able to get the droid 2.2 + to connect to the Traveler server. We are able to download the installer, just not get any further.

Subject: Still trouble with Traveler and Androids for us :frowning:

Hi !Upgraded Domino servers to 8.5.2 this weekend.

Upgraded Traveler to 8.5.2.1

Installed new Traveler Client on Android - problems.

Then I upgraded Domino 8.5.2 with FP1 - still problems.

Then I read about the problems with Traveler on Androids related to SSL (we are NOT using SSL - yet), but still I tried the interim fix provided.

Installed new client on my Android (HTC Desire, Android 2.2 latest avaialable build) but still I cannot get anything sync’ed to the device.

The server console reports “Unexpected SendActionExceptionException for user…”

I am able to send mail from the device and I am able to wipe the device from the “Lotus Traveler Admin db”.

Traveler server is working fine for all my users running iPhone, iPad or Androids running the 3rd party “TouchDown” client for that matter.

But NOT for us guys actually running the Travele client for Androids :frowning:

Traveler on Anroids has been bad since we started testing it a long while ago. Isn’t about time to get it right ?

Help - anybody ?

Rgds.

Stig-Erik Halvorsen

Subject: RE: Still trouble with Traveler and Androids for us :frowning:

The SendActionExceptionException exception is during the sync process.

You really need to open a PMR so that the logs from the client (TPR) and the server (FINEST for that user) can be analyzed. You are the only customer I know of that is getting this exception so it isn’t a wide spread problem that is causing this exception, but we need the logs to figure out what is going on.

Subject: Same problem

Hi.Upgraded to 8.5.2 FP1

Traveler to 8.5.2.1

22.01.2011 11:52:49 Lotus Traveler: SEVERE CN=xxxxxxxxx/O=xxxxx Unexpected SendActionExceptionException for user=CN=xxxx/O=xxxx#Android_c268019ea48b4e7

Regards

Páll Sveinsson

Subject: RE: Same problem

There is no update on the answer on this one - you need to open a PMR so that logs can be analyzed.

Subject: Same problem here

I also have the problem with android users.Unexpected SendActionExceptinException for user=cn xxx /O=xxx#Android

We run the hotfix, but still the same problem.

Subject: Solved

It turned out I had a few references to an old path in the files in the directory Data\traveler\cfg (We put the domino data directory on a different disk).These files were probably not updated after the new installation of Traveler.

So, after editing the files with notepad, updating all files with the new location and restarting the traveller, synchronization worked.

HTH…

Subject: RE: Same problem here

Without logs, we really cannot tell what is going on and fix it. You need to open a PMR so that logs can be analyzed and the issue fixed.

Subject: Traveler Sync Problem on HTC Phones

Still no resolution to our sync’ing problem, I have contacted 3 Mobile the operator who couldn’t help but tried. Contacted HTC, they suggested I use Exchange or IMAP, I have suggested that they look at supporting Lotus Notes as a business e-mail client.Can anyone at IBM help?

Please find attached some of the logs from my phone.

Log 1:

12-30 10:57:18.541 I/ActivityManager(92)Process com.lotus.sync.traveler (pid 14844) has died.

12-30 10:57:18.541 W/ActivityManager(92)Scheduling restart of crashed service com.lotus.sync.traveler/.android.service.TravelerService in 5000ms

12-30 10:57:18.561 I/ActivityManager(92)Start proc com.lotus.sync.traveler for broadcast com.lotus.sync.traveler/.android.service.BroadcastReceiver: pid=15409 uid=10068 gids={3003, 1007, 1015}

Log 2:

12-23 22:28:21.795 I/ActivityManager(92)Starting activity: Intent { act=android.intent.action.MAIN cat=[android.intent.category.LAUNCHER] flg=0x10200000 cmp=com.lotus.sync.traveler/.LotusMail }

12-23 22:28:21.825 D/SurfaceFlinger(92)Layer::setBuffers(this=0x630fb0), pid=92, w=1, h=1

12-23 22:28:21.825 D/SurfaceFlinger(92)Layer::setBuffers(this=0x630fb0), pid=92, w=1, h=1

12-23 22:28:21.855 D/SurfaceFlinger(92)Layer::requestBuffer(this=0x630fb0), index=0, pid=92, w=480, h=800 success

12-23 22:28:21.895 D/Sensors (92)open_akm, fd=149

12-23 22:28:21.895 D/AK8973 (72)Compass Start

12-23 22:28:21.905 I/WindowManager(92)Setting rotation to 1, animFlags=1

12-23 22:28:21.925 I/ActivityManager(92)Config changed: { scale=1.0 imsi=234/20 loc=en_GB touch=3 keys=1/1/2 nav=3/1 orien=2 layout=34 uiMode=17 seq=68}

12-23 22:28:21.985 D/SurfaceFlinger(92)Layer::requestBuffer(this=0x4929d8), index=1, pid=92, w=800, h=714 success

12-23 22:28:22.015 D/SurfaceFlinger(92)Layer::requestBuffer(this=0x486200), index=0, pid=92, w=800, h=38 success

12-23 22:28:22.035 D/SurfaceFlinger(92)Layer::requestBuffer(this=0x584e08), index=0, pid=182, w=800, h=480 success

12-23 22:28:22.045 D/SurfaceFlinger(92)Layer::requestBuffer(this=0x4929d8), index=0, pid=92, w=800, h=394 success

12-23 22:28:22.075 D/SurfaceFlinger(92)Layer::requestBuffer(this=0x4929d8), index=1, pid=92, w=800, h=394 success

12-23 22:28:22.155 I/ActivityManager(92)Starting activity: Intent { cmp=com.lotus.sync.traveler/.android.common.LaunchSequenceActivity (has extras) }

12-23 22:28:22.175 I/ActivityManager(92)Starting activity: Intent { flg=0x10000 cmp=com.lotus.sync.traveler/.MailLaunchSequence }

12-23 22:28:22.205 I/ActivityManager(92)Starting activity: Intent { flg=0x10000 cmp=com.lotus.sync.traveler/.MainFoldersListView }

12-23 22:28:22.205 I/ActivityManager(92)Starting activity: Intent { flg=0x10000 cmp=com.lotus.sync.traveler/.FolderMailView (has extras) }

12-23 22:28:22.315 D/SurfaceFlinger(92)Layer::setBuffers(this=0x645040), pid=298, w=1, h=1

12-23 22:28:22.315 D/SurfaceFlinger(92)Layer::setBuffers(this=0x645040), pid=298, w=1, h=1

12-23 22:28:22.365 D/SurfaceFlinger(92)Layer::requestBuffer(this=0x645040), index=0, pid=298, w=800, h=480 success

12-23 22:28:22.385 I/WindowManager(92)Setting rotation to 0, animFlags=0

12-23 22:28:22.405 I/ActivityManager(92)Config changed: { scale=1.0 imsi=234/20 loc=en_GB touch=3 keys=1/1/2 nav=3/1 orien=1 layout=34 uiMode=17 seq=69}

12-23 22:28:22.445 I/ActivityManager(92)Displayed activity com.lotus.sync.traveler/.FolderMailView: 231 ms (total 544 ms)

12-23 22:28:22.465 D/SurfaceFlinger(92)Layer::requestBuffer(this=0x4929d8), index=1, pid=92, w=480, h=394 success

12-23 22:28:22.485 D/SurfaceFlinger(92)Layer::requestBuffer(this=0x486200), index=1, pid=92, w=480, h=38 success

12-23 22:28:22.525 D/SurfaceFlinger(92)Layer::requestBuffer(this=0x4929d8), index=0, pid=92, w=480, h=714 success

12-23 22:28:22.545 D/SurfaceFlinger(92)Layer::requestBuffer(this=0x4929d8), index=1, pid=92, w=480, h=714 success

12-23 22:28:22.565 D/SurfaceFlinger(92)Layer::requestBuffer(this=0x645040), index=1, pid=298, w=480, h=800 success

12-23 22:28:22.605 D/SurfaceFlinger(92)Layer::requestBuffer(this=0x645040), index=0, pid=298, w=480, h=800 success

12-23 22:28:22.685 D/dalvikvm(298)GC_FOR_MALLOC freed 6863 objects / 386568 bytes in 49ms

12-23 22:28:23.515 D/dalvikvm(298)GC_FOR_MALLOC freed 10685 objects / 475072 bytes in 46ms

12-23 22:28:23.785 W/Rosie (201)mAddHtcWidgetByOtherActivity = false, mIsOpenSlideWhenLeaveLaunch = true

12-23 22:28:23.785 W/InputManagerService(92)Ignoring hideSoftInput of: com.android.internal.view.IInputMethodClient$Stub$Proxy@467079a8

12-23 22:28:24.185 I/global (298)Default buffer size used in BufferedReader constructor. It would be better to be explicit if an 8k-char buffer is required.

12-23 22:28:24.375 D/dalvikvm(298)GC_FOR_MALLOC freed 10795 objects / 540224 bytes in 73ms

12-23 22:28:24.545 D/dalvikvm(298)GC_FOR_MALLOC freed 10083 objects / 512424 bytes in 42ms

12-23 22:28:24.765 D/dalvikvm(92)GC_EXPLICIT freed 44805 objects / 2344664 bytes in 144ms

12-23 22:28:24.845 D/dalvikvm(298)GC_FOR_MALLOC freed 10009 objects / 530400 bytes in 72ms

12-23 22:28:25.005 D/dalvikvm(298)GC_FOR_MALLOC freed 10105 objects / 519712 bytes in 43ms

12-23 22:28:25.155 D/dalvikvm(298)GC_FOR_MALLOC freed 10172 objects / 524304 bytes in 45ms

12-23 22:28:25.205 I/global (298)Default buffer size used in BufferedReader constructor. It would be better to be explicit if an 8k-char buffer is required.

12-23 22:28:25.915 I/ProblemReporterService.run:550(298)Problem reports sent: 1

12-23 22:28:25.925 D/SurfaceFlinger(92)Layer::setBuffers(this=0x63bbd0), pid=298, w=1, h=1

12-23 22:28:25.925 D/SurfaceFlinger(92)Layer::setBuffers(this=0x63bbd0), pid=298, w=1, h=1

12-23 22:28:25.945 D/SurfaceFlinger(92)Layer::requestBuffer(this=0x63bbd0), index=0, pid=298, w=300, h=85 success

12-23 22:28:36.665 D/dalvikvm(311)GC_EXPLICIT freed 1015 objects / 45448 bytes in 68ms

12-23 22:28:42.685 D/dalvikvm(201)GC_EXPLICIT freed 1586 objects / 87616 bytes in 85ms

12-23 22:28:51.509 V/AlarmManager(92)Alarm triggering: Alarm{464f9088 type 2 android}

12-23 22:28:51.565 D/SyncManager(92)canceling and rescheduling sync because it ran too long: authority: com.android.contacts account: Account {name=mike cain, type=com.lotus.sync.notes.android} extras: [ignore_backoff=true force=true ignore_settings=true ] syncSource: 3 when: 189158780 expedited: false

12-23 22:28:51.565 V/AlarmManager(92)Adding Alarm{466a2bc0 type 2 android} Jan 03 05:37:40 am

12-23 22:28:51.565 V/AlarmManager(92)Alarm triggering: Alarm{466a2bc0 type 2 android}

Thanks in advance for any assistance.