Email auto sending does not work as set

[kunago]

I am using the latest version of GPS logger (130 RC2) and unless I have something wrong in the settings, the app suffers from an issue with auto sending.

Currently the app is managed with Tasker; once the car bluetooth is connected, gpslogger is launched and starts recording the ride. As soon as bluetooth is disconnected, the app is requested to send the logged ride to a predefined email and terminate itself.

This setup works fine, however, each GPS point is logged individually and sent as the output, so I receive an email in an interval, which is likely to be set in the "Absolute time to GPS fix". Previously it was set to 60 s, now it is set to 120 s, and each point was sent either in a minute or two. GPS signal is fine; even though phone can see over 30 satellites, it still behaves the same. The aim is to receive a ride log in a single ZIP file.

Is there something wrong in the setting or is it likely to be a bug?

[mendhak]

In your screenshot I see the Auto Send How Often is set to 0 minutes, I think that's "as soon as possible" or to be more clear, I don't think I've ever tested that with 0 minutes!

[kunago]

I tested to set the value to 7200 minutes the other day and the result was the same. As the description regarding this field says though, "0" should disable the auto send as such.

The auto send is triggered in Tasker once the bluetooth is disconnected so no repeated reports are needed.

[mendhak]

I've just checked the code and I think it must be that the logic for testing 0 and 'disabling' has been lost over time. I'll include a bugfix for that in a future release. That would explain the emails kind of matching almost every point being logged in terms of timing. It's best not to leave it at 0 for now.

I've tried various settings with the app, tried different versions, but at large values I'm not seeing this problem. Does the file get emailed too-frequently at other values like 3600, 60, 10, 15? Are you stopping and restarting logging when changing the value. Does it happen with v129?

[kunago]

I tested today with a longer auto sending period set, which I set to 1400 (equals to a whole day). As you can see in the picture, it says there is a whole bunch of satellites visible, there are 6 points in the log ... etc., yet I received an email every 2 minutes.

Should I downgrade to v129 as suggested?

[mendhak]

There's something wrong with one of the timers but I can't tell what.

A few things you can try.

You can try recording a debug log. There might be a clue in there that indicates why the sending timer is kicking off so early.

You can try an app reset and see if it still happens, while still on the same version. You'll lose all your files and settings so you'll have to start over.

You can try v129 and see if it still happens, but even if v129 helps, I don't know if it's due to the 're' install or not.

[kunago]

I can already give an answer to an app reset - I already tried that to no avail. So I will see the debug log and share it.

[mendhak]

Aaaaah how did I not notice this earlier:

It's sending it because the file name is changing every minute. The app isn't smart enough to gather up everything in the past hour, that isn't kept track of anywhere. So actually the auto send is not clearly described, it's "every 60 minutes or when the file name changes".

[kunago]

Oh, I see. The aim was to have a log file creted with a specific timestamp and keep the name until the logging is stopped.

Is this not feasible? Unticking the "Allow custom file name to change dynamically" optional does not parse the replacement patterns. Then having it ask for a file name on every start" prevents the auto start via Tasker.

Could that be that replacement tags are always parsed, as it is unlikely anyone would like to name a file literally as %HOUR for instance?

[mendhak]

Are you sure you're not seeing that already? I just tried gpslogger_%HOUR and "Allow custom file name..." is unchecked, and "ask for a file name..." is unchecked. I started logging and I got a gpslogger_07 file as it's 07AM here.

[kunago]

After some time of testing I wanted to give a feedback. Apparently you were right. The file name is parsed fine with placeholders included and all GPS points are gathered in a single file. Just perfect.

I am not sure about the 0 logic in the code but in the case I set the interval to 0, no repeated logs are sent.

Just one thing but likely out of scope. When the phone is not connected to internet and email was to be sent, it does not wait for internet connection and simply drops the email. I realize this is not likely to be handled as some message queue is a big extra. Just thought I could mention it.

Other than that, it works excellently.

[mendhak]

Thanks for testing. So, I'm not sure how that happens but I've seen intermittent reports of background jobs not waiting ro an internet connection. The problem of course is that 'it works on my ~machine~ devices' 😆

In the background jobs, I've added a requireNetwork() check, so it's supposed to be waiting for a network connection, but I've had to implement some logic to 'ensure' that there's a network connection, so I wonder if that's going wrong.

That said, I'm working on replacing all the background jobs with Android WorkManager, which comes with its own network checking logic, so I just put a constraint like this and I don't have to write custom checks.

[kunago]

The problem of course is that 'it works on my ~machine~ devices' 😆

I tried and it does not reliably work on mine. :-) For instance I called while the function was triggered and did not receive any email. Also I noticed my DNS server went down one day and again, it would not send anything.

Does the internet connection test rely on IP ping or a domain name ping?

[mendhak]

I don't know the answer to that, how the OS figures out if internet is available or not, it seems quite opaque to me.

That said I am currently doing a big library change for the background tasks (using WorkManager) which has a direct impact on this issue.

In WorkManager I should be able to simply say this:

.setRequiredNetworkType(PreferenceHelper.getInstance().shouldAutoSendOnWifiOnly() ? NetworkType.UNMETERED: NetworkType.CONNECTED)

And I hope it should be able to detect if it's a proper working connection or not before meeting that constraint. The definition is quite sparse, for CONNECTED the documentation says "Any working network connection is required for this work.". So I think it should be ensuring there's a proper connection.

If you want/able to test it with your setup, the APK is here: https://github.com/mendhak/gpslogger/releases/tag/v131-rc1

[kunago]

I am running the version you suggested and since the update I no longer receive any emails. The config has not changed in any way and test email passes fine.

Is there anything I need to check, any new setting?

[mendhak]

There is an APK here if needed: https://github.com/mendhak/gpslogger/releases/tag/v131-rc2 It is using the new WorkManager instead of the old JobQueue. I'll probably release this to F-Droid in a week or so.

I missed your latest message. I think you'd probably want to do a debug log to see if anything pops in there, the first being, does it schedule and attempt to do an auto send every X minutes, and after that if any error messages appear.

[mendhak]

v131 is in the releases and FDroid