Many tiny log files created while downloading logs

ArduCopter Copter 4.2
,
1

I have been experiencing this issue for a while but haven’t been able to find a solution or any info about it. The only similar post I could find is - Lots log files after downloading

CONFIG:
ArduCopter 4.6.0-dev (i have experienced the same with 4.2.3 and others)
LOG_BACKEND_TYPE = 1
LOG_BITMASK = 180222
LOG_DARM_RATEMAX = 2
LOG_DISARMED = 1
LOG_FILE_BUFSIZE = 200
LOG_FILE_DSRMROT = 0
LOG_FILE_MB_FREE = 500
LOG_FILE_RATEMAX = 0
LOG_FILE_TIMEOUT = 5
LOG_MAV_BUFSIZE = 8
LOG_MAV_RATEMAX = 0
LOG_MAX_FILES = 500
LOG_REPLAY = 0

THE PROBLEM:
Using Mission Planner I downloaded logs 7, 8 and 9 (log 10 was the currently increasing in size log). After downloading the logs, the list showed 56 logs - 46 extra logs created

Screenshot from 2025-05-02 17-28-10
Screenshot from 2025-05-02 17-28-10664×1064 217 KB

I then tried downloading those same logs (7, 8, 9) using QGC. Similar issue but much smaller, only 3 extra files were created - see below

Screenshot from 2025-05-02 17-31-45
Screenshot from 2025-05-02 17-31-45664×1064 228 KB

IT IS REPRODUCIBLE
I can reproduce the issue every time and I believe the number of tiny logs created is related to the size of the log files being downloaded and how long it takes.

It’s not a huge issue but it is annoying.
Anyone experience the same? Any remedies?

2

set

LOG_DISARMED,0

With it set to 1 it’s creating a new log every time you power the controller by USB or battery.

3

I think this is a bug that got fixed in 4.4.x but I am not sure. It was released a long time ago already

4.6.0-dev is too old. Use 4.6.0-beta6 instead.

4

Thank you, this does circumvent the problem but there are reasons we like to log disarmed and will likely forget to turn it off or back on when downloading the logs.

QGC uses FTP in the background to download (I think), so possibly that’s why it doesn’t suffer from this problem as much,.

5

Thank you, we will be switching to a stable soon.

I just wanted to report that the log file corruptions causing the timestamps to be read erroneously by APM Planner or to display bogus data entries in plot.arducopter.org, seems to have been the SD card.

A scan didn’t reveal any problems but replacing the card seems to have resolved this problem for now.