Version 0.11.4 Android version 11 Galaxy Tab 8 (2019)
The Play Store indicates that my HAMRS was upgraded last week to 0.11.4. Since the upgrade, there is sever lag in entering callsigns and saving. When I reach somewhere in the area of 50 log entries, every callsign I enter takes about 30 seconds to a minute to save and appear in the log list below. Sometimes the callsign doesn’t get saved or appear in the list.
I turned off Expanded Mode and all live call lookups. No improvement.
I uninstalled and reinstalled, which removed all of my old logs. That is ok. The new log I created seemed to work fine until I reached in the area of 50+ entries in the log. I stopped using that log and created a new one to see if it was just that particular log causing the lag. The new log I created also had the same lag problem with no callsigns in the new log.
No matter what I do, I cannot get the clock to allow for manual typing in the time field. I have tried what others have said with iOS, but doesn’t seem to make a difference with Android.
When the lagging issue begins, entering in a callsign without a bluetooth keyboard will duplicate characters. Sometimes, groups of characters are repeated together. When I use my BT keyboard, the duplication does not occur.
I did a test with HAMRS on my older LG Android phone on Android Version 8.1.0 . I entered 107 contacts into the HAMRS v 0.11.4 . Lag started to happen about 70 contacts logged. But not as bad as in the Samsung tablet. I was able to log all the contacts, but noticed that the time the callsign appears in the log list, took over double the time from when I started. With a nearly empty log, callsigns would take about 5 seconds to appear. After I got up in the log around 70, the callsign took about 13 seconds to appear. While the callsign was being saved and before posting, the callsign field is blank and if I began typing another callsign, the first letter might not make it.
The app on the LG phone time will not allow it to be updated with the time button turned off/black. So that is a problem with the older version of Android as well.
What ever is happening during the save seems to struggle as the list grows. Posting the QSO to the log seems to be doing a lot with the data that already exists. Maybe a database indexing issue?
Thanks for the suggestion. I wish I had the APK to do it. APK is the installer for the app. If I had a backup, I could use that backup apk. But I don’t have it
@Chucktate - So when looking at a bug like this, there are usually one of two culprits. One is a memory leak - as the app stays open and you’re racking up contacts, memory use builds up little by little. An easy test would be to close HAMRS completely, reopen it, and heading to a log that has a lot of contacts and seeing if it’s still slow. If that isn’t the case, then it is truly about the amount of contacts in the log on Android which I need to do some research on.
If you close HAMRS, open it back up is it immediately snappier? Or still slow?
Hi Jarrett, thanks for the response. I rebooted the tablet, launched HAMRS, created a new log for POTA. I began entering my list of call signs into the log. Each entry was 5 seconds by the time it appeared in the list below. That seems to be normal timing. I continued to enter the list and as the list grew near 50, the save time began to climb noticeably. 8 seconds per save. As I passed 50, the time climbed to 13 seconds to save. Also, the clock pause option could not be adjusted. I went back to logbooks screen. Closed the app. Fully closed the app from running. I relaunched it. Loaded the log I was just using. Continued to type and save times were 5 seconds. The clock pause button selected, I was able to enter a time manually. I think your theory of a memory leak seems correct. Thanks for looking into this. 73 W7RTA
I noticed the same happening yesterday on a POTA activation on my iPad mini after about 70 and more so contacts. The app was getting so laggy it also was wiping the callsign field completely and I had to re enter it several times which slow my progress down with the pile up. First time ever having a problem like this.
As of 15:21 EST 10/26 the 0.11.5 update is not available on the Amazon Appstore for my Fire Tablet.
Nor is it available at HAMRS.app in either MacOS or Windows on the download buttons. It only comes up as 0.11.4.
Hi Jarrett , I went into the play store and there was no update button. But I uninstalled and reinstalled and 11.5 was installed. I created a log and entered 110 call signs. The save time was about 2 seconds at first. As the list grew, the save time increased to about 10 seconds (Mostly around the 100 mark). I was able to pause the clock and manually enter a time. When I entered callsign into the callsign field the other fields populated quickly from the hamqth lookup. I closed the log and created a new log without restarting the app. I entered in a few callsigns and they saved in 1-2 seconds each. (last version, I saw a delay even with the new log. Now I don’t) I completely force stopped the app. I opened the log with the 110 callsign and proceeded to enter and save another callsign. It took about 10 seconds to save the record.
It appears as the list grows, the save time is delayed a bit. For me, the way I use the app, this is acceptable. I write a callsign on a pad. As I am reading back the callsign and giving a signal report I enter the callsign in HAMRS. I press enter on my BT keyboard, or press save. By this time, either I am still in the QSO, calling CQ or listening to someone giving me the callsign. I then write it down. So the delay will not interfere with me in the field. I can see it being an issue if folks use HAMRS in data entry mode. Meaning they write all their contacts on paper and enter in the app when they get home.
Thank you for fixing the memory leak. And thank you for responding so quickly. Great app and I love using it.
IMHO, 10 seconds is wayyyy too long. That would be problematic for me. But on my iPad Pro, this delay doesn’t seem to be present. Perhaps my hardware is snappy enough.
Just a thought… Is there something about the field validation function that is cycling through the whole database every time, and therefore causing the delay as the log gets larger? That seems to be one of the primary features introduced between 0.11.3 and 0.11.4 that could be relevant.
Agreed. We aren’t out of the woods just yet. None of this is acceptable. Thank you for the big write up @Chucktate , it’s super helpful.
@KZ3L I don’t think the field validation is the issue. I’m currently looking at the timer function as a suspect for a memory leak, and dupe checking as a suspect for ‘more records slow things down’, because it has to go through the entire log to look for dupes.
Glad to help @Jarrett I enjoy the app and I have lots of time on my hands, so if you need any testing and or input , feel free to reach out to me. I used to work in the hospital software industry supporting software. I am not a developer, but I worked closely with developers helping them understand what is happening to the end users. My email is good on QRZ. I’ll never forget the phrase one developer would ask me every time I would show him a bug. He would look over my shoulder and in his Asian voice “Why it do that?” I would look at him and laugh. He was a fun guy to work with. 73 W7RTA
Did the upgrade appear in the Play Store? I uninstalled and reinstalled and the new version was installed. Of course, that deletes any logs that were created prior. W7RTA
I just downloaded 0.11.5 from the Amazon appstore. (Playstore?) for my Fire Tablet. Just playing around with it at home shows no improvement and another problem. See New Post.
You might also check database indexing. Too many indexes can create problems adding records, especially if the record is being saved as fields are entered. Just a thought, though 200 records seems small for indexing to create an issue.
We also had a problem with applications that built some code for us where the code was trying to store every record in memory and running queries from memory instead of the database. About 200 records is where that will start bogging down
Just thoughts about the issue. I’m currently using the MacOS version but don’t have many records yet. Any way to import a bunch for testing?
Activating a park now and when I hit 50ish in the log, the issue came back it took about 15 seconds to save a callsign. I force stopped the app and started it up again and then saving the callsign was about 2 to 3 seconds. So it appears not fixed
Okay running 0.11.5 today. Seems to have started lagging at about QSO 58 or 60. It seems worse if you get notified that you have been spotted while you are trying to populate fields. You need to wait for the QSO counter to increment before working on the next entry. I usually talk longer between contacts to allow the counter to increment. Much harder to do this on CW.
Another issue I found: I was at a trail that has numerous grids associated with it. I like to use the grid at the particular trail head i am activating so I change the grid after I enter the park I am at. At some point, the grid changes to an incorrect grid and your state field goes blank. Another example where a global editor would come in very handy.
Pete - KW9E
