Can you provide some background on why you want the rapid push enabled by default? It increases server load, server storage needs, as well as SG bandwidth consumption. If it’s off and you turn it on it essentially uploads all logs within an hour (bandwidth permitting), is that not sufficient?
There have been a lot of issues with cell connectivity still and often a station will only briefly connect again before blinking out. Seems that sending the logs as quickly as possible makes sense so that diagnostic information is available. I didn’t think there was much data involved and that sending it in one shot vs spread over (how long?) made that much difference. But perhaps that’s not the case…
I’m not sure I understand the “time of last download/upload” issue. It seems you are saying that you initiated a download but something failed in the browser so you couldn’t save the file and then the UI updated? That’s unfortunately quite possible as there is no real “download complete and file saved successfully” feedback from the browser. The UI has a button to retry the last download and then as fall-back a button to download all data. I’m not sure what else I can provide but am open to suggestions.
That’s correct. I only realized this when a download very conspicuously failed but the “last downloaded” time was updated nonetheless. The risk with this is that data is missed, but there is no indication that that had happened. The safe bet may just be to select “download all” every time to ensure that everything is downloaded, but that can take a while and would be unnecessary in most cases…
One thing I really liked about the previous method of downloading via SFTP is that you could browse the folder structure and choose when to download from. What about an option to select the start date of the data to download? Via calendar picker or something. That way you could always ensure you are downloading data from the appropriate data, without downloading more than needed. And yes, having all of these on cell or otherwise connected would be great, but in reality that will be a while and there will always be some manual only stations…
About the download file name, which OS/browser combo are you using so I can reproduce? I’ll see whether I can fix this, I remember struggling with some stuff around the file naming but not the details. I had not noticed the save-as issue…
This is mostly on Vivaldi/ Win 10. However I just tried right now and though it’s displayed as “foo.zip”, it saved with the correct name with both methods.
![image](https://community.motus.org/uploads/db1524/original/1X/c2b1fc49c6c5a95b1d3c506f402672311ab40444.png)
FWIW I’ve been having a lot of issues downloading on various browsers. Often it just fails or there is a “server not found” message (while still connected). On various browsers and devices, but it’s all been quite intermittent so difficult to replicate. On my last trip, though, downloads went much better generally.
I can look into the folder structure, I don’t know what it entails. The software creates the zip archive on the fly (it never hits the SDcard) and there were some limitations.
It’s not worth spending time on if it’s not super simple! But maybe you can clarify since I’m not following Wouldn’t the files already be stored on the SD card with that folder structure