teslausb
teslausb copied to clipboard
marcone
Teslausb stops mounting in Tesla after a few weeks
Teslausb installed on Pi-Zero works great after a fresh install. After a couple of weeks, the device begins to experience problems with mounting in the Tesla. It's not clear to me whether this is a result of Teslausb being turned off (Tesla Sleeps) during "archiveloop" process when connected at home. When the car wakes from sleep to drive, Teslausb starts back up, but often does not mount in the Tesla. The lights flash - as normal, but no mounting in the car after a few minutes. Sometimes, if I disconnect Teslausb, and reconnect, it will mount (but this is rare). I've tried rebooting the Tesla MCU - but this makes no difference.
However, while connected to the Tesla (not mounted), I can confirm I can connect to the AP, and even access the new webpage/viewer. I can even reboot from the webpage, (I don't think archiveloop can be forced unless it's connected to the home SSID). Is there perhaps a way to force mount the device, as I can SSH into the device via the AP. If there is a command to do this, can it be built into the Viewer?
It should be noted while Teslausb does not mount in the car, I can confirm it mounts when connected to the computer. It takes about 1 min before the CAM and MUSIC drives show up.
Update : TeslaUSB is plugged into the car via a HUB. The device was has not been mounting as described. Ten minutes into the drive, I plugged in a spare USB key into the HUB to ensure dashcam was recording. Surprisingly, this triggered the mounting of TeslaUSB. I confirmed via the viewer some video recorded today, and the music was available to the car. I have not tried replicating this since - but I'll try again tomorrow assuming Teslausb does not mount again.
Any ideas or thoughts on how to troubleshoot would be greatly appreciated. Thanks
archiveloop.log diagnostics.txt teslausb-headless-setup.log
You didn't say when you took the diagnostics, but they show that the attached host mounted the drives less than 2 minutes before. There were a few times on previous days when the "autofs" system service failed to start, blocking teslausb, but I don't know what would cause that.
You didn't say when you took the diagnostics, but they show that the attached host mounted the drives less than 2 minutes before. There were a few times on previous days when the "autofs" system service failed to start, blocking teslausb, but I don't know what would cause that.
Thanks for looking into this @marcone. I pulled those files from the Teslausb Viewer on July 6, 2021 at 4:28PM MT. Is there a way to identify whether the mounting was on the computer versus on the Tesla? I guess if it mounted to the Tesla, it would show files being written/processed in the TeslaCam folders.
It's definitely bizarre that the device works fine for a couple weeks before this mounting issue begins to plague the device.
I got similiar problems after firmware update 2021.12.25.6, worked perfectly before. It worked once after I made a software update via ssh but then it does not show up in the car anymore.
I have updated the car to 2021.12.25.7 but it is still the same behavior, i.e. after a connection to a computer both Music and TeslaCAM is mounted every time. I the do a apt update; apt upgrade and the put the Rasperry PI Zero back in the car. FIrst startup works fine but next time it lokks that the PI is not installed again. Just to be sure I tested with an ordinaru USB-stick and tha works (no surprise). I enclose my diagnostic.txt that was readout 29th of july 2021 at 8 a.m. diagnostics.txt
I have updated the car to 2021.12.25.7 but it is still the same behavior, i.e. after a connection to a computer both Music and TeslaCAM is mounted every time. I the do a apt update; apt upgrade and the put the Rasperry PI Zero back in the car. FIrst startup works fine but next time it lokks that the PI is not installed again. Just to be sure I tested with an ordinaru USB-stick and tha works (no surprise). I enclose my diagnostic.txt that was readout 29th of july 2021 at 8 a.m. diagnostics.txt
@mane-wt Great that you are replicating the steps I did to debug as well. @marcone is there a way to increase logging specifically to the mounting process to see why it works with a computer versus the Tesla? The next test I am going to do is run Teslasub only for TeslaCAM (No Music) - maybe there's something weird going on with handling two drives?
I've been testing running just a normal microsd card in the Tesla without issues for a couples weeks now, and synching my music collection from my NAS to my phone using free Android synching software.
Before removing music, can you check to see if USB is mounted in the car even if the cam isn't working? Mine is doing this and a do the double wheel reboot and the cam starts right up.
From: @.*** Sent: August 1, 2021 12:45 p.m. To: @.*** Reply-to: @.*** Cc: @.*** Subject: Re: [marcone/teslausb] Teslausb stops mounting in Tesla after a few weeks (#654)
I have updated the car to 2021.12.25.7 but it is still the same behavior, i.e. after a connection to a computer both Music and TeslaCAM is mounted every time. I the do a apt update; apt upgrade and the put the Rasperry PI Zero back in the car. FIrst startup works fine but next time it lokks that the PI is not installed again. Just to be sure I tested with an ordinaru USB-stick and tha works (no surprise). I enclose my diagnostic.txt that was readout 29th of july 2021 at 8 a.m. diagnostics.txthttps://github.com/marcone/teslausb/files/6913001/diagnostics.txt
@mane-wthttps://github.com/mane-wt Great that you are replicating the steps I did to debug as well. @marconehttps://github.com/marcone is there a way to increase logging specifically to the mounting process to see why it works with a computer versus the Tesla? The next test I am going to do is run Teslasub only for TeslaCAM (No Music) - maybe there's something weird going on with handling two drives?
I've been testing running just a normal microsd card in the Tesla without issues for a couples weeks now, and synching my music collection from my NAS to my phone using free Android synching software.
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHubhttps://github.com/marcone/teslausb/issues/654#issuecomment-890551975, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AHYTQSKHJUEXIKAZYEPMOJDT2V225ANCNFSM4753E3FQ.
@mane-wt your diagnostics show the Pi is making the drive available to the car, but the car chose not to access it:
USB state (350.4 seconds ago): mass storage ready, but not connected to host (check cable)
@jun3280net The Pi just emulates a USB drive. It has no visibility into whether it's connected to a PC or a car.
Just to add my experience and offer any assistance with logs etc.:
My installation has been working fine for some time but has stopped after my M3 LR was recently upgraded to 2021.12.25.6. I have: Rebooted my M3 both in and out of WiFi range - no change. Tried the Tesla supplied USB drive which works straight away, but re-inserting the TeslaUSB still - no change. Further Info: USB drives mount and work fine when connected to PC. I'm also syncing Music.
Please let me know if I can provide any more information, unfortunately technically I will need guidance, but happy to assist where I can.
Bob
After some more testing: It's enough to put the Pi to the cmputer and let it mount the Music- and TeslaCam drives. Just to be sure the filesystem wasn't corruptet I logged in to the Pi via ssh and issued a "sudo halt" command. After that both music and TeslaCam was woring in the car, but only first time as before. I always get both music and TeslaCam or neither of them. @marcone Strange that the drive was ready but the car didn't use it. Could the reason be that the filesystem is OK the first time after the Pi has been connected to a computer and then the second time in the car the filesystem is corrupted and won't be fixed the same way compared to when it's connected to a computer?
@mane-wt - regarding your "sudo halt" command. Assuming you can SSH into your Teslausb - when it is not mounting in the car, does running the "sudo halt" command, and rebooting the Teslausb get it to mount in the car?
On a separate note, I tried to do a reinstall of the Teslausb on the Pi Zero W - as I am wondering if the Music drive might be part of the problem. It seems all of us posting here - have a music drive. That said - I'm wondering if my issues are deeper, as I am no longer able to reinstall any of the Teslausb images. I chased down a few threads related to the "get_script failed, retrying" and updating the "wpa_supplicant.conf" info as explained. No improvement.
In fact, I do not even see wlan0 when I run "ifconfig". Is there any way to confirm whether the wireless hardware is actually dead? Thanks
Update: Car updated to 2021.12.25.7 this morning, rebooted car and connected Raspberry Pi - No change.
Regarding jun3280net's comment re the music drive, I was also wondering about that and if Tesla had introduced some checks for more than one connected device to prevent the use of hubs etc with the dashcam, it would be good if someone without the Music partition could confirm?
Bob
On Tue, 3 Aug 2021 at 01:32, jun3280net @.***> wrote:
@mane-wt https://github.com/mane-wt - regarding your "sudo halt" command. Assuming you can SSH into your Teslausb - when it is not mounting in the car, does running the "sudo halt" command, and rebooting the Teslausb get it to mount in the car?
On a separate note, I tried to do a reinstall of the Teslausb on the Pi Zero W - as I am wondering if the Music drive might be part of the problem. It seems all of us posting here - have a music drive. That said - I'm wondering if my issues are deeper, as I am no longer able to reinstall any of the Teslausb images. I chased down a few threads related to the "get_script failed, retrying" and updating the "wpa_supplicant.conf" info as explained. No improvement.
In fact, I do not even see wlan0 when I run "ifconfig". Is there any way to confirm whether the wireless hardware is actually dead? Thanks
[image: image] https://user-images.githubusercontent.com/30555695/127939543-79ae4c83-a8cd-4764-b7d1-e00f317453e1.png
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/marcone/teslausb/issues/654#issuecomment-891421283, or unsubscribe https://github.com/notifications/unsubscribe-auth/AEEU3N57QGYYYPUOTSDV6ETT242JRANCNFSM4753E3FQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&utm_campaign=notification-email .
Hello i've been following from the sidelines. I have a Raspberry Pi Zero. I'm currently on 2021.4.18.10 with a 2021 Model 3 and i'm having the same issue as everyone else. I'm only using Pi zero for Dashcam in the glovebox. I have an external HD for just music and boombox in the center console. So i can confirm no music partition here.
I use a music drive, got 2021.12.25.7 yesterday, and everything still works with my Pi0.
@marcone Hi, anything you can suggest for those of us with the issue to try or any further info we can provide, or do you feel it's a case of waiting for a future Tesla update?
After more testing I am almost convinced that the issue is a result from a corrupt file system. I have tried to connect the Pi to a computer and after the Music drive and the TeslaCam drive have been mounted I just unplugged the Pi in a similar way when the car cuts its power. Like this the Pi won't work in the car. If I instead log in to the Pi with ssh and issues a "sudo halt" command to safely take down the Pi, it works once when connecting it to the car. It is known that the file system on the Pi will be corrupted when the car suddenly cuts power to the Pi. Before when everything worked the Pi fixed the filesystem upon startup but not anymore. Unfortunately it will not work to issue a "sudo reboot" command when the Pi sits in the car.
It would be very interesting if it is possible to issue a command to fix the filesystem via ssh when the Pi sits in the car, @marcone do you know such a command? One other theory is that if the Pi, sitting in the car, eventually fixed the filesystem it wont mount the Music drive and the TeslaCam drive even if it has been fixed. Is it possible to repeat the command to try another time to mount the 2 drives, and if so how to do that?
(I have a Tesla Model S 2018 if that makes a difference)
After more testing I am almost convinced that the issue is a result from a corrupt file system.
Which one? Teslausb uses multiple partitions, plus disk images, each with their own filesystem.
CAM and MUSIC are only two of the 6 or more filesystems that could be in use at any given time, hence my question. In any case, those two are checked for errors on every boot, before being presented to the car, so the problem shouldn't be caused by corruption of those two. The fact that you only ever get neither or both also points at that, since it suggests that the Pi got "stuck" on something before publishing the drives to the car, like in the case where autofs wasn't starting up in an earlier comment above.
I have the same issue, which only started since I updated to 25.7. A double wheel reboot of the screen fixes the issue 100% of the time. Power cycling the Pi0 in the car doesn't do anything. I submitted a "bug report" in the car, for whatever good it will do. Sorry for not being more helpful, but just adding another data point. Given that this problem only started for me once I got the 25.7 update, logic suggests that Tesla did something in the update that is causing this issue.
For me the problem started with version 25.6 but I also think Tesla did something unfortunately. Despite if it is due to Tesla or not maybe we can do something about it any way? Would it be possible to check all filesystems upon every boot and/or try to mount more than one time after some delay?
I really do not want to be without this wonderful functionality.
Yesterday, I checked everything was working fine connected to my PC, ejected the Drives and Halted the Pi, placed it back in the GloveBox, I could see the TeslaUSB online, SSH to it, mount and display the folders and sync Music, also (now I know about it) use the web interface. This morning the TeslaUSB was not visible on the network, I went into the Tesla App and once connected confirmed Sentry Mode was active, then when I checked again I could see the TeslaUSB on the network and all the above worked again (I didn't try syncing anything). Just checked in the car, no overnight Sentry Mode events, Dashcam functioning OK, could see/delete events from yesterday/this morning, usual active alert re No USB in GloveBox. Again anything in the way of logs I can provide, just let me know.
The Pi not being on the network and then reappearing on the network kind of sounds like the USB port powered off at some point, and then opening the app caused it to power up again. The archiveloop log would tell if it lost power and restarted.
Not exactly sure what I'm looking for but for the 5th/6th there were these entries regarding car
Thu 5 Aug 08:20:49 BST 2021:00:00 not keeping car awake. Thu 5 Aug 10:54:34 BST 2021:00:00 not keeping car awake. Thu 5 Aug 19:26:57 BST 2021:00:00 not keeping car awake. Fri 6 Aug 08:29:59 BST 2021:00:00 not keeping car awake. Fri 6 Aug 13:08:56 BST 2021:00:00 not keeping car awake.
There was also this weird sequence where the time appeared to go out by just over an hour:
Thu 5 Aug 08:05:19 BST 2021:00:00 low space, deleting /backingfiles/snapshots/snap-000216 Thu 5 Aug 08:05:26 BST 2021:00:00 low space, deleting /backingfiles/snapshots/snap-000217 Thu 5 Aug 08:05:31 BST 2021:00:00 low space, deleting /backingfiles/snapshots/snap-000218 Thu 5 Aug 07:17:02 BST 2021:00:00 Starting archiveloop at 24.11 seconds uptime... Thu 5 Aug 07:17:03 BST 2021:00:00 taking snapshot of cam disk in /backingfiles/snapshots/snap-000229 Thu 5 Aug 07:17:09 BST 2021:00:00 waiting for autofs to be active Thu 5 Aug 07:17:10 BST 2021:00:00 waiting for autofs to be active Thu 5 Aug 07:17:11 BST 2021:00:00 waiting for autofs to be active Thu 5 Aug 07:17:13 BST 2021:00:00 waiting for autofs to be active Thu 5 Aug 07:17:14 BST 2021:00:00 waiting for autofs to be active Thu 5 Aug 07:17:15 BST 2021:00:00 waiting for autofs to be active Thu 5 Aug 07:17:16 BST 2021:00:00 waiting for autofs to be active Thu 5 Aug 07:17:17 BST 2021:00:00 waiting for autofs to be active Thu 5 Aug 07:17:18 BST 2021:00:00 waiting for autofs to be active Thu 5 Aug 07:17:20 BST 2021:00:00 took snapshot Thu 5 Aug 07:17:25 BST 2021:00:00 comparing new snapshot with /backingfiles/snapshots/snap-000228/snap.bin Thu 5 Aug 07:17:25 BST 2021:00:00 making links for /tmp/snapshots/snap-000229, retargeted to /backingfiles/snapshots/snap-000229/mnt Thu 5 Aug 07:17:29 BST 2021:00:00 made all links for /tmp/snapshots/snap-000229 Thu 5 Aug 07:17:29 BST 2021:00:00 Running fsck on /backingfiles/cam_disk.bin... Thu 5 Aug 07:17:30 BST 2021:00:00 | fsck from util-linux 2.33.1 Thu 5 Aug 07:17:33 BST 2021:00:00 | fsck.fat 4.1 (2017-01-24) Thu 5 Aug 07:17:33 BST 2021:00:00 | 0x41: Dirty bit is set. Fs was not properly unmounted and some data may be corrupt. Thu 5 Aug 07:17:33 BST 2021:00:00 | Automatically removing dirty bit. Thu 5 Aug 07:17:33 BST 2021:00:00 | Performing changes. Thu 5 Aug 07:17:33 BST 2021:00:00 | /dev/loop1p1: 264 files, 221882/2888512 clusters Thu 5 Aug 07:17:33 BST 2021:00:00 Finished fsck on /backingfiles/cam_disk.bin. Thu 5 Aug 07:17:33 BST 2021:00:00 Running fsck on /backingfiles/music_disk.bin... Thu 5 Aug 07:17:33 BST 2021:00:00 | fsck from util-linux 2.33.1 Thu 5 Aug 07:17:35 BST 2021:00:00 | fsck.fat 4.1 (2017-01-24) Thu 5 Aug 07:17:35 BST 2021:00:00 | /dev/loop1p1: 685 files, 197463/1443854 clusters Thu 5 Aug 07:17:35 BST 2021:00:00 Finished fsck on /backingfiles/music_disk.bin. Thu 5 Aug 07:17:35 BST 2021:00:00 Trying to set time... Thu 5 Aug 08:20:49 BST 2021:00:00 Time adjusted by 3793.354031 seconds after 0.190000 seconds Thu 5 Aug 08:20:49 BST 2021:00:00 not keeping car awake. Thu 5 Aug 08:20:49 BST 2021:00:00 Archiving...
There are quite a lot of time adjustments, many of quite large amounts throughout my log:
Sat 10 Jul 15:20:48 BST 2021:00:00 Time adjusted by 0.041322 seconds after 0.460000 seconds Sat 10 Jul 16:32:05 BST 2021:00:00 Time adjusted by 2.765470 seconds after 2.390000 seconds Sat 10 Jul 18:32:12 BST 2021:00:00 Time adjusted by 873.085900 seconds after 0.220000 seconds Sun 11 Jul 18:41:11 BST 2021:00:00 Time adjusted by 1417.996986 seconds after 0.180000 seconds Mon 12 Jul 18:50:13 BST 2021:00:00 Time adjusted by 1964.287524 seconds after 0.190000 seconds Mon 12 Jul 20:52:46 BST 2021:00:00 Time adjusted by 0.140406 seconds after 0.190000 seconds Tue 13 Jul 18:59:22 BST 2021:00:00 Time adjusted by 2510.485778 seconds after 0.190000 seconds Tue 13 Jul 21:25:52 BST 2021:00:00 Time adjusted by 5.292144 seconds after 5.340000 seconds Wed 14 Jul 22:13:56 BST 2021:00:00 Time adjusted by 41570.694784 seconds after 0.210000 seconds Thu 15 Jul 15:19:53 BST 2021:00:00 Time adjusted by 3742.877806 seconds after 0.180000 seconds Thu 15 Jul 19:05:37 BST 2021:00:00 Time adjusted by 0.178487 seconds after 0.250000 seconds Fri 16 Jul 00:45:24 BST 2021:00:00 Time adjusted by 1673.035861 seconds after 0.180000 seconds Fri 16 Jul 01:26:09 BST 2021:00:00 Time adjusted by 31.308971 seconds after 0.270000 seconds Tue 20 Jul 12:30:14 BST 2021:00:00 Time adjusted by 52761.069820 seconds after 5.340000 seconds Tue 20 Jul 16:46:43 BST 2021:00:00 Time adjusted by 3988.889017 seconds after 5.230000 seconds Tue 20 Jul 21:02:45 BST 2021:00:00 Time adjusted by 6315.919796 seconds after 0.180000 seconds Wed 21 Jul 00:23:48 BST 2021:00:00 Time adjusted by 11175.889354 seconds after 1.250000 seconds Wed 21 Jul 01:33:07 BST 2021:00:00 Time adjusted by 15338.300939 seconds after 0.150000 seconds Thu 22 Jul 03:12:13 BST 2021:00:00 Time adjusted by 3282.388175 seconds after 0.180000 seconds Thu 22 Jul 21:32:26 BST 2021:00:00 Time adjusted by -0.033865 seconds after 0.270000 seconds Fri 23 Jul 03:21:36 BST 2021:00:00 Time adjusted by 3828.054385 seconds after 0.180000 seconds Fri 23 Jul 15:44:55 BST 2021:00:00 Time adjusted by 0.037149 seconds after 0.300000 seconds Fri 23 Jul 17:56:00 BST 2021:00:00 Time adjusted by 0.203233 seconds after 0.250000 seconds Sat 24 Jul 06:10:27 BST 2021:00:00 Time adjusted by 3174.217884 seconds after 0.180000 seconds Sun 25 Jul 12:41:29 BST 2021:00:00 Time adjusted by 3721.644048 seconds after 0.440000 seconds Mon 26 Jul 07:28:41 BST 2021:00:00 Time adjusted by 664.890364 seconds after 0.200000 seconds Mon 26 Jul 16:40:03 BST 2021:00:00 Time adjusted by 1.216831 seconds after 1.400000 seconds Mon 26 Jul 21:50:41 BST 2021:00:00 Time adjusted by 1970.016565 seconds after 0.200000 seconds Tue 27 Jul 07:38:02 BST 2021:00:00 Time adjusted by 1210.997750 seconds after 0.180000 seconds Tue 27 Jul 20:39:30 BST 2021:00:00 Time adjusted by 2.144754 seconds after 2.410000 seconds Tue 27 Jul 23:01:02 BST 2021:00:00 Time adjusted by 2586.484549 seconds after 0.200000 seconds Wed 28 Jul 09:03:38 BST 2021:00:00 Time adjusted by 35164.274834 seconds after 0.200000 seconds Wed 28 Jul 14:45:31 BST 2021:00:00 Time adjusted by 55678.529582 seconds after 0.220000 seconds Wed 28 Jul 20:31:16 BST 2021:00:00 Time adjusted by 822.576738 seconds after 0.170000 seconds Sat 31 Jul 23:10:05 BST 2021:00:00 Time adjusted by 222749.671463 seconds after 0.180000 seconds Sun 1 Aug 12:25:48 BST 2021:00:00 Time adjusted by 47295.236598 seconds after 0.210000 seconds Tue 3 Aug 08:58:40 BST 2021:00:00 Time adjusted by 207663.604204 seconds after 0.230000 seconds Tue 3 Aug 14:08:34 BST 2021:00:00 Time adjusted by 6661.858932 seconds after 0.200000 seconds Wed 4 Aug 18:37:18 BST 2021:00:00 Time adjusted by 94784.423244 seconds after 0.190000 seconds Wed 4 Aug 19:49:25 BST 2021:00:00 Time adjusted by 0.431548 seconds after 0.450000 seconds Wed 4 Aug 20:33:50 BST 2021:00:00 Time adjusted by 30.856127 seconds after 0.170000 seconds Wed 4 Aug 21:01:51 BST 2021:00:00 Time adjusted by 34.264929 seconds after 0.190000 seconds Wed 4 Aug 21:43:08 BST 2021:00:00 Time adjusted by 1532.565555 seconds after 0.170000 seconds Wed 4 Aug 23:12:02 BST 2021:00:00 Time adjusted by 121.703656 seconds after 0.170000 seconds Wed 4 Aug 23:17:06 BST 2021:00:00 Time adjusted by 0.154188 seconds after 0.150000 seconds Wed 4 Aug 23:21:06 BST 2021:00:00 Time adjusted by 0.149503 seconds after 0.160000 seconds Wed 4 Aug 23:28:13 BST 2021:00:00 Time adjusted by 0.713779 seconds after 0.710000 seconds Thu 5 Aug 08:20:49 BST 2021:00:00 Time adjusted by 3793.354031 seconds after 0.190000 seconds Thu 5 Aug 10:54:33 BST 2021:00:00 Time adjusted by 0.383021 seconds after 0.420000 seconds Thu 5 Aug 19:26:57 BST 2021:00:00 Time adjusted by 0.121718 seconds after 0.240000 seconds Fri 6 Aug 08:29:59 BST 2021:00:00 Time adjusted by 737.210348 seconds after 0.190000 seconds Fri 6 Aug 13:08:56 BST 2021:00:00 Time adjusted by 0.164750 seconds after 0.260000 seconds
Look for something like:
==============================================
Mon 2 Aug 18:44:32 PDT 2021: Starting archiveloop at 23.11 seconds uptime...
That indicates the Pi just booted up.
The time adjustments happen every time the Pi does an archive operation. In your log-excerpt the larger values likely indicate the Pi was powered off for a while. The small values are just corrections for clock-drift.
Quite a few events, but I can't be 100% sure which ones may be where I've been connecting/disconnecting whilst testing on the PC etc., but definitely on the 5th/6th I didn't, so we are thinking potentially a loss of power, I have Sentry Mode enabled and the logs show every hour so doesn't look like a prolonged loss of power.
Hopefully, these extracts help provide some useful information for everyone trying to piece this together and happy to try anything and provide more information, just let me know.
I would add since the Pi has been back in the car, it has been available every time I got in the car and stored a few Sentry Mode events so seems to be behaving itself ATM.
Mon 26 Jul 07:17:03 BST 2021:00:00 Starting archiveloop at 23.36 seconds uptime... Mon 26 Jul 21:17:03 BST 2021:00:00 Starting archiveloop at 23.09 seconds uptime... Tue 27 Jul 07:17:02 BST 2021:00:00 Starting archiveloop at 23.24 seconds uptime... Tue 27 Jul 22:17:04 BST 2021:00:00 Starting archiveloop at 24.73 seconds uptime... Tue 27 Jul 23:17:02 BST 2021:00:00 Starting archiveloop at 23.20 seconds uptime... Tue 27 Jul 23:17:02 BST 2021:00:00 Starting archiveloop at 22.87 seconds uptime... Wed 28 Jul 20:17:03 BST 2021:00:00 Starting archiveloop at 22.91 seconds uptime... Thu 29 Jul 09:17:03 BST 2021:00:00 Starting archiveloop at 22.96 seconds uptime... Thu 29 Jul 09:17:03 BST 2021:00:00 Starting archiveloop at 23.21 seconds uptime... Sat 31 Jul 23:17:03 BST 2021:00:00 Starting archiveloop at 23.24 seconds uptime... Sat 31 Jul 23:17:02 BST 2021:00:00 Starting archiveloop at 23.37 seconds uptime... Sat 31 Jul 23:17:03 BST 2021:00:00 Starting archiveloop at 23.14 seconds uptime... Tue 3 Aug 12:17:03 BST 2021:00:00 Starting archiveloop at 23.24 seconds uptime... Tue 3 Aug 16:17:03 BST 2021:00:00 Starting archiveloop at 22.92 seconds uptime... Tue 3 Aug 16:17:03 BST 2021:00:00 Starting archiveloop at 23.37 seconds uptime... Wed 4 Aug 20:32:49 BST 2021:00:00 Starting archiveloop at 23.01 seconds uptime... Wed 4 Aug 21:00:47 BST 2021:00:00 Starting archiveloop at 23.31 seconds uptime... Wed 4 Aug 21:17:03 BST 2021:00:00 Starting archiveloop at 23.02 seconds uptime... Wed 4 Aug 23:09:32 BST 2021:00:00 Starting archiveloop at 23.07 seconds uptime... Thu 5 Aug 07:17:02 BST 2021:00:00 Starting archiveloop at 24.11 seconds uptime... Fri 6 Aug 08:17:03 BST 2021:00:00 Starting archiveloop at 23.70 seconds uptime...
@marcone I was just thinking about what you said about the large adjustments due to being off for a while but did you notice that the time went back nearly an hour and then adjusted to 15 mins or so of the original time it was logging events at, which indicates to me it wasn't off that long, but I may not be fully understanding?
Thu 5 Aug 08:05:31** BST 2021:00:00 low space, deleting /backingfiles/snapshots/snap-000218 Thu 5 Aug 07:17:02 BST 2021:00:00 Starting archiveloop at 24.11 seconds uptime...
Thu 5 Aug 07:17:35 BST 2021:00:00 Trying to set time... Thu 5 Aug 08:20:49 BST 2021:00:00 Time adjusted by 3793.354031 seconds after 0.190000 seconds
It's really hard to draw any conclusions from what you've posted so far, since it's just been snippets of the log and not the entire log.
Normally every Starting archiveloop line indicates the Pi was powered on after having turned off. I would expect the first "Time adjusted" after power-on to be large, and any subsequent ones to be small.
@marcone Sorry, I was trying to focus on things I thought looked odd, such as this time anomaly to try and make it easier, but happy to supply the full log, shall I just attach it here?
@marcone I've attached both, looking at them briefly it looks like it rebooted again this morning.
archiveloop (1).log diagnostics.txt