V10 - Changes to Sentry Mode

[bladec59]

From early view of release notes it looks like Tesla is changing/adding a folder to store Sentry Mode clips:

“Sentry Mode video clips are now saved in a separate folder on your USB drive to make them easier to review and manage. Also, the older Sentry mode video clips will now be automatically deleted if there is not enough space on the USB drive and Sentry Mode clips are using more than 5 Gigabytes of space.”

Not sure this impacts teslausb code or not.

[fatfurrycat]

@carleeno @marcone Thought there was footage to be uploaded, as I made sure to trigger a sentry event before returning home. The logs would seem to indicate that I hadn't, which is borne out by the fact that it has uploaded new footage after a drive today.

However, the uploads from today's drive include not only sentry events but dashcam footage for my entire drive. This is not what I expected, as no dashcam events have been triggered, and I haven't attempted to save any manually. My previous uploads have only ever contained sentry mode clips.

The logs contains this: Wed 2 Oct 13:33:35 BST 2019: There are 34 event folder(s) with 598 file(s) to move. Wed 2 Oct 13:33:35 BST 2019: Starting recording archiving: 34 event folder(s) with 598 file(s) Wed 2 Oct 13:33:35 BST 2019: Moving clips to archive... Wed 2 Oct 13:33:35 BST 2019: Creating output directory '2019-10-02_09-08-11'

Given that the car only reported 7 sentry events, this seems like an awful lot of files to be moving? I don't have sentry mode enabled when I'm at home, as the car is secure. I've attached some more diagnose output.

I'm also seeing some anomalies with regards to timestamps on the files in /mnt/cam. The current contents of SavedClips looks like: root@teslausb:/mnt/cam/TeslaCam/SavedClips# ls -la total 576 drwxrwxrwx 36 root root 16384 Oct 2 06:05 . drwxrwxrwx 4 root root 16384 Oct 2 06:32 .. drwxrwxrwx 2 root root 16384 Oct 2 15:04 2019-10-02_09-08-11 drwxrwxrwx 2 root root 16384 Oct 2 15:23 2019-10-02_09-11-10 drwxrwxrwx 2 root root 16384 Oct 2 15:37 2019-10-02_09-14-21 drwxrwxrwx 2 root root 16384 Oct 2 02:15 2019-10-02_09-15-42 drwxrwxrwx 2 root root 16384 Oct 2 02:17 2019-10-02_09-17-51 drwxrwxrwx 2 root root 16384 Oct 2 02:32 2019-10-02_09-32-41 drwxrwxrwx 2 root root 16384 Oct 2 02:40 2019-10-02_09-40-31 drwxrwxrwx 2 root root 16384 Oct 2 02:59 2019-10-02_09-59-44 drwxrwxrwx 2 root root 16384 Oct 2 03:03 2019-10-02_10-03-55 drwxrwxrwx 2 root root 16384 Oct 2 03:07 2019-10-02_10-07-44 drwxrwxrwx 2 root root 16384 Oct 2 03:10 2019-10-02_10-10-22 drwxrwxrwx 2 root root 16384 Oct 2 03:12 2019-10-02_10-12-08 drwxrwxrwx 2 root root 16384 Oct 2 03:24 2019-10-02_10-24-05 drwxrwxrwx 2 root root 16384 Oct 2 03:25 2019-10-02_10-25-19 drwxrwxrwx 2 root root 16384 Oct 2 03:26 2019-10-02_10-26-47 drwxrwxrwx 2 root root 16384 Oct 2 03:42 2019-10-02_10-42-49 drwxrwxrwx 2 root root 16384 Oct 2 04:14 2019-10-02_11-14-42 drwxrwxrwx 2 root root 16384 Oct 2 04:18 2019-10-02_11-18-09 drwxrwxrwx 2 root root 16384 Oct 2 04:19 2019-10-02_11-19-46 drwxrwxrwx 2 root root 16384 Oct 2 04:24 2019-10-02_11-24-09 drwxrwxrwx 2 root root 16384 Oct 2 04:32 2019-10-02_11-32-01 drwxrwxrwx 2 root root 16384 Oct 2 04:36 2019-10-02_11-36-35 drwxrwxrwx 2 root root 16384 Oct 2 04:38 2019-10-02_11-38-19 drwxrwxrwx 2 root root 16384 Oct 2 04:48 2019-10-02_11-48-15 drwxrwxrwx 2 root root 16384 Oct 2 04:53 2019-10-02_11-53-27 drwxrwxrwx 2 root root 16384 Oct 2 04:56 2019-10-02_11-56-30 drwxrwxrwx 2 root root 16384 Oct 2 05:29 2019-10-02_12-29-36 drwxrwxrwx 2 root root 16384 Oct 2 05:47 2019-10-02_12-47-06 drwxrwxrwx 2 root root 16384 Oct 2 05:55 2019-10-02_12-55-34 drwxrwxrwx 2 root root 16384 Oct 2 05:58 2019-10-02_12-58-01 drwxrwxrwx 2 root root 16384 Oct 2 06:00 2019-10-02_13-00-00 drwxrwxrwx 2 root root 16384 Oct 2 06:01 2019-10-02_13-01-29 drwxrwxrwx 2 root root 16384 Oct 2 06:03 2019-10-02_13-03-12 drwxrwxrwx 2 root root 16384 Oct 2 06:05 2019-10-02_13-05-21 root@teslausb:/mnt/cam/TeslaCam/SavedClips# date Wed 2 Oct 15:39:43 BST 2019

I'm assuming that the Pi can only have sensible date/time information if it's able to make a NTP request following boot up. However, for the entire duration of the captures above, it should have had accurate date/time as the car hadn't entered deep sleep overnight (proven by TeslaFi data), and so the Pi wouldn't have been shutdown. Am I wrong, or possibly, missing something obvious?

diagnose2.txt

[carleeno]

If your drive was less than 10 minutes it would have recorded the entire drive because when you tap the camera icon to save footage, it saves the last 10 minutes. Of the 34 folders backed up, how many are in the SentryClips folder vs in the SavedClips folder?

It sounds like maybe you had something trigger a lot of sentry mode events.

On Wed, Oct 2, 2019, 10:38 AM fatfurrycat notifications@github.com wrote:

@carleeno https://github.com/carleeno @marcone https://github.com/marcone Thought there was footage to be uploaded, as I made sure to trigger a sentry event before returning home. The logs would seem to indicate that I hadn't, which is borne out by the fact that it has uploaded new footage after a drive today.

However, the uploads from today's drive include not only sentry events but dashcam footage for my entire drive. This is not what I expected, as no dashcam events have been triggered, and I haven't attempted to save any manually. My previous uploads have only ever contained sentry mode clips.

The logs contains this: Wed 2 Oct 13:33:35 BST 2019: There are 34 event folder(s) with 598 file(s) to move. Wed 2 Oct 13:33:35 BST 2019: Starting recording archiving: 34 event folder(s) with 598 file(s) Wed 2 Oct 13:33:35 BST 2019: Moving clips to archive... Wed 2 Oct 13:33:35 BST 2019: Creating output directory '2019-10-02_09-08-11'

Given that the car only reported 7 sentry events, this seems like an awful lot of files to be moving? I've attached some more diagnose output. diagnose2.txt https://github.com/marcone/teslausb/files/3681640/diagnose2.txt

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/marcone/teslausb/issues/260?email_source=notifications&email_token=ANAO4LQQ7X3ZBXY2CFYBT33QMSW7TA5CNFSM4IW3ZYZKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEAE7P3Q#issuecomment-537524206, or mute the thread https://github.com/notifications/unsubscribe-auth/ANAO4LQ2HN2DJZNEUIBWX53QMSW7TANCNFSM4IW3ZYZA .

[fatfurrycat]

@carleeno They're all in the SavedClips folder, as I don't have v10 yet. I've also never tapped the camera icon to save a clip. The car reported only 7 sentry events on my whole journey. The footage is still uploading at the moment, so I'll review the clips and see if it's all dashcam shortly.

[carleeno]

Sentry events don't happen on a journey, only when the car is parked. However it sounds like the car recorded more than 7 sentry events. It's not uncommon for a rainy night to trigger a hundred events, for example.

On Wed, Oct 2, 2019, 11:01 AM fatfurrycat notifications@github.com wrote:

@carleeno https://github.com/carleeno They're all in the SavedClips folder, as I don't have v10 yet. I've also never tapped the camera icon to save a clip. The car reported only 7 sentry events on my whole journey. The footage is still uploading at the moment, so I'll review the clips and see if it's all dashcam shortly.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/marcone/teslausb/issues/260?email_source=notifications&email_token=ANAO4LRH6YG5GRHGCQIEB2LQMSZVZA5CNFSM4IW3ZYZKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEAFCF4Y#issuecomment-537535219, or mute the thread https://github.com/notifications/unsubscribe-auth/ANAO4LW2FFV5BAUBCUJ7ADDQMSZVZANCNFSM4IW3ZYZA .

[th3fallen]

Silly question but is there a way for it to sync but keep the root Sentry events folder, so when i sync them up to gdrive i can quickly find what came from sentry?

[carleeno]

Yes if you self update and run setup again, it'll update to the latest version which supports keeping the folder structure.

On Wed, Oct 2, 2019, 11:23 AM Clark Tomlinson notifications@github.com wrote:

Silly question but is there a way for it to sync but keep the root Sentry events folder, so when i sync them up to gdrive i can quickly find what came from sentry?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/marcone/teslausb/issues/260?email_source=notifications&email_token=ANAO4LSK6447EKX4VTKEZP3QMS4IXA5CNFSM4IW3ZYZKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEAFESMI#issuecomment-537545009, or mute the thread https://github.com/notifications/unsubscribe-auth/ANAO4LSM32IHNAKBLMDHKS3QMS4IXANCNFSM4IW3ZYZA .

[th3fallen]

Sweet i just did that update i'll wait and see how it turns out. thanks

[fatfurrycat]

@carleeno Totally understand. I'm at a loss to explain how it's behaved today. The vast majority of the files it's uploaded today are dashcam of my journeys, which it's never done before. It's still syncing, so I'll wait for it to finish and report back.

[miles267]

Just setup teslausb with v10 using the buster build. Dashcam icon no longer displayed. Can confirm I'm connected to correct data port of RP0 and also a compatible data connection as I previously had a usb SSD drive attached to the same cable.

[acraigl]

Just setup teslausb with v10 using the buster build. Dashcam icon no longer displayed. Can confirm I'm connected to correct data port of RP0 and also a compatible data connection as I previously had a usb SSD drive attached to the same cable.

Do you use a splitter? If so try without it just to eliminate it as the problem (mine worked prior to v10 for whatever reason, but not after). Do an MCU reboot and then SSH to the Pi and follow the instructions at the link below. Rerunning setup in this way got mine working.

https://github.com/marcone/teslausb/wiki

[miles267]

Do you use a splitter? If so try without it just to eliminate it as the problem (mine worked prior to v10 for whatever reason, but not after). Do an MCU reboot and then SSH to the Pi and follow the instructions at the link below. Rerunning setup in this way got mine working.

https://github.com/marcone/teslausb/wiki

Thanks @acraigl for the help. No, not using any splitter. Followed the instructions in the link you provided. Even though I was SSH'd into the PI and there wasn't a *.conf file in the /boot folder any longer (since doing the initial headless setup), I did the following steps. Please let me know if I did that correctly; particularly how I responded to both y/n/cancel prompts?

sudo -i /root/bin/remountfs_rw /root/bin/setup-teslausb selfupdate (when asked to load info from .conf file, I said YES) /root/bin/setup-teslausb (when asked to load info from *.conf file, I said YES) reboot

[acraigl]

Thanks @acraigl for the help. No, not using any splitter. Followed the instructions in the link you provided. Even though I was SSH'd into the PI and there wasn't a *.conf file in the /boot folder any longer (since doing the initial headless setup), I did the following steps. Please let me know if I did that correctly; particularly how I responded to both y/n/cancel prompts?

sudo -i /root/bin/remountfs_rw /root/bin/setup-teslausb selfupdate (when asked to load info from .conf file, I said YES) /root/bin/setup-teslausb (when asked to load info from *.conf file, I said YES) reboot

That's correct. The .conf file still exists but gets moved to the root directory after a successful install. YES was the proper response in both cases. Is it working now?

[miles267]

Unfortunately, no. The Dashcam icon doesn’t appear when running this buster base image and configuration. The RP0 is connecting to WiFi and I’m able to SSH to it.

[acraigl]

Unfortunately, no. The Dashcam icon doesn’t appear when running this buster base image and configuration. The RP0 is connecting to WiFi and I’m able to SSH to it.

Are you using the v10 branch or main-dev (default)? FWIW, my dashcam was not showing up this morning. I unplugged/replugged it from the USB port and then did the two-finger salute (reset MCU with the 2 steering buttons) and when it came back up, so did the dashcam. I'd try that and see if it helps. In the meantime, I'll see if it repeats tomorrow morning as well.

[miles267]

Are you using the v10 branch or main-dev (default)? FWIW, my dashcam was not showing up this morning. I unplugged/replugged it from the USB port and then did the two-finger salute (reset MCU with the 2 steering buttons) and when it came back up, so did the dashcam. I'd try that and see if it helps. In the meantime, I'll see if it repeats tomorrow morning as well.

I installed the teslausb-buster-20190922 base image. However I did not make any modifications to these commented lines of the .conf file and perhaps I should have?

• Uncomment and change if you want a different branch than main-dev
• export BRANCH=main-dev

[acraigl]

I installed the teslausb-buster-20190922 base image. However I did not make any modifications to these commented lines of the .conf file and perhaps I should have?

• Uncomment and change if you want a different branch than main-dev
• export BRANCH=main-dev

No, you're good. I think the only deviation I made other than the obvious was to enable CIFS 3.0. But none of this should impact the ability for the dashcam icon to come up in the car. Unplug/plug the Pi and reset the MCU and see if that makes it appear (more curious than anything else, as it worked for me this AM)

[fatfurrycat]

Done some more research overnight, and am finding that there are saved clips in snapshots, which aren't being archived. I had a road rage incident last night, where someone brake checked me several times. I tapped the icon to save the last 10 minutes of dashcam footage.

If I look at the diagnose logs, I see the following attempt at archiving, which occurred roughly 30 minutes after the incident:

Wed 2 Oct 22:19:31 BST 2019: There are 34 event folder(s) with 426 file(s) to move. Wed 2 Oct 22:19:31 BST 2019: Starting recording archiving: 34 event folder(s) with 426 file(s) Wed 2 Oct 22:19:31 BST 2019: Moving clips to archive... Wed 2 Oct 22:19:31 BST 2019: Creating output directory '2019-10-02_09-08-11' Wed 2 Oct 22:19:31 BST 2019: Creating output directory '2019-10-02_09-11-10' Wed 2 Oct 22:19:31 BST 2019: Creating output directory '2019-10-02_09-14-21' Wed 2 Oct 22:19:31 BST 2019: Creating output directory '2019-10-02_09-15-42' Wed 2 Oct 22:19:31 BST 2019: Creating output directory '2019-10-02_09-17-51' Wed 2 Oct 22:19:31 BST 2019: Creating output directory '2019-10-02_09-32-41' Wed 2 Oct 22:19:31 BST 2019: Creating output directory '2019-10-02_09-40-31' Wed 2 Oct 22:19:31 BST 2019: Creating output directory '2019-10-02_09-59-44' Wed 2 Oct 22:19:31 BST 2019: Creating output directory '2019-10-02_10-03-55' Wed 2 Oct 22:19:31 BST 2019: Creating output directory '2019-10-02_10-07-44'

This covers the driving I did during the morning yesterday, but there's no sign of any footage from my evening drives.

However, if I look at the snapshots on the card, then I see that snap-000095 contains the files I'm wanting to see archived:

36610533 SavedClips/2019-10-02_21-43-37/2019-10-02_21-33-20-front.mp4 36942948 SavedClips/2019-10-02_21-43-37/2019-10-02_21-33-20-left_repeater.mp4 37589093 SavedClips/2019-10-02_21-43-37/2019-10-02_21-33-20-right_repeater.mp4 36823625 SavedClips/2019-10-02_21-43-37/2019-10-02_21-34-20-front.mp4 37429495 SavedClips/2019-10-02_21-43-37/2019-10-02_21-34-20-left_repeater.mp4 37109500 SavedClips/2019-10-02_21-43-37/2019-10-02_21-34-20-right_repeater.mp4 36349024 SavedClips/2019-10-02_21-43-37/2019-10-02_21-35-21-front.mp4 36972043 SavedClips/2019-10-02_21-43-37/2019-10-02_21-35-21-left_repeater.mp4 35974200 SavedClips/2019-10-02_21-43-37/2019-10-02_21-35-21-right_repeater.mp4 37366014 SavedClips/2019-10-02_21-43-37/2019-10-02_21-36-21-front.mp4 37328261 SavedClips/2019-10-02_21-43-37/2019-10-02_21-36-21-left_repeater.mp4 36011772 SavedClips/2019-10-02_21-43-37/2019-10-02_21-36-21-right_repeater.mp4 36880939 SavedClips/2019-10-02_21-43-37/2019-10-02_21-37-22-front.mp4 36806367 SavedClips/2019-10-02_21-43-37/2019-10-02_21-37-22-left_repeater.mp4 37129101 SavedClips/2019-10-02_21-43-37/2019-10-02_21-37-22-right_repeater.mp4 36937383 SavedClips/2019-10-02_21-43-37/2019-10-02_21-38-22-front.mp4 36905183 SavedClips/2019-10-02_21-43-37/2019-10-02_21-38-22-left_repeater.mp4 36889796 SavedClips/2019-10-02_21-43-37/2019-10-02_21-38-22-right_repeater.mp4 36951196 SavedClips/2019-10-02_21-43-37/2019-10-02_21-39-23-front.mp4 36272413 SavedClips/2019-10-02_21-43-37/2019-10-02_21-39-23-left_repeater.mp4 36930798 SavedClips/2019-10-02_21-43-37/2019-10-02_21-39-23-right_repeater.mp4 36547309 SavedClips/2019-10-02_21-43-37/2019-10-02_21-40-24-front.mp4 36162210 SavedClips/2019-10-02_21-43-37/2019-10-02_21-40-24-left_repeater.mp4 36785988 SavedClips/2019-10-02_21-43-37/2019-10-02_21-40-24-right_repeater.mp4 37490185 SavedClips/2019-10-02_21-43-37/2019-10-02_21-41-25-front.mp4 36484932 SavedClips/2019-10-02_21-43-37/2019-10-02_21-41-25-left_repeater.mp4 36809420 SavedClips/2019-10-02_21-43-37/2019-10-02_21-41-25-right_repeater.mp4 35916279 SavedClips/2019-10-02_21-43-37/2019-10-02_21-42-25-front.mp4 36203958 SavedClips/2019-10-02_21-43-37/2019-10-02_21-42-25-left_repeater.mp4 36531215 SavedClips/2019-10-02_21-43-37/2019-10-02_21-42-25-right_repeater.mp4

It also contains the SavedClips that directly follow on from the morning's driving.

I tried to get the Pi to synchronise these clips by connecting it to WiFi this morning, but all I see in the logs is: Thu 3 Oct 09:42:50 BST 2019: There are 0 event folder(s) with 0 file(s) to move. Thu 3 Oct 09:42:50 BST 2019: Unmounting /mnt/cam... Thu 3 Oct 09:42:51 BST 2019: Unmounted /mnt/cam. Thu 3 Oct 09:42:51 BST 2019: Finished archiving. Thu 3 Oct 09:42:51 BST 2019: Music archive not configured or unreachable Thu 3 Oct 09:42:51 BST 2019: unmounting /mnt/archive

This doesn't seem right, as there are definitely saved clips in a snapshot that need to be archived. Am I right in thinking that saved clips in snapshots should be archived? diagnose3.txt

[miles267]

Was curious whether there's a command you can run from SSH that will manually trigger a sync if you want to test it in the garage. I've not yet seen anything copy to my NAS despite setting up the share, credentials and including in the .conf file accordingly.

[DMBlakeley]

SSH into RPi, then:

sudo -i
/root/bin/remountfs_rw
touch /tmp/archive_is_unreachable

Check /mutable/archiveloop.log for details.

[miles267]

Thanks @DMBlakeley. Is the time not set error an issue?

Thu 3 Oct 09:02:46 CDT 2019: Music archive not configured or unreachable Thu 3 Oct 09:02:46 CDT 2019: unmounting /mnt/archive Thu 3 Oct 09:02:46 CDT 2019: Connecting usb to host... Thu 3 Oct 09:02:46 CDT 2019: Connected usb to host. Thu 3 Oct 09:02:46 CDT 2019: Waiting for archive to be unreachable... Thu 3 Oct 09:04:32 CDT 2019: Simulating archive being unreachable. Thu 3 Oct 09:04:32 CDT 2019: Waiting for archive to be reachable... Thu 3 Oct 09:04:32 CDT 2019: Archive is reachable. Thu 3 Oct 09:04:32 CDT 2019: Waiting for time to be set by ntpd... Thu 3 Oct 09:04:59 CDT 2019: Time still not set, attempting to force it

[th3fallen]

Anyone else getting a message like....

Thu  3 Oct 10:09:52 EDT 2019: '2019-10-03_10-08-45/2019-10-03_09-58-20-left_repeater.mp4' is only 595 bytes
Thu  3 Oct 10:09:52 EDT 2019: '2019-10-03_10-08-45/2019-10-03_09-58-20-right_repeater.mp4' is only 595 bytes
Thu  3 Oct 10:09:53 EDT 2019: '2019-10-03_10-08-45/2019-10-03_09-58-20-back.mp4' is only 595 bytes
Thu  3 Oct 10:09:53 EDT 2019: '2019-10-03_10-08-45/2019-10-03_09-59-21-front.mp4' is only 595 bytes
Thu  3 Oct 10:09:53 EDT 2019: '2019-10-03_10-08-45/2019-10-03_09-59-21-left_repeater.mp4' is only 595 bytes
Thu  3 Oct 10:09:53 EDT 2019: '2019-10-03_10-08-45/2019-10-03_09-59-21-right_repeater.mp4' is only 595 bytes
Thu  3 Oct 10:09:53 EDT 2019: '2019-10-03_10-08-45/2019-10-03_09-59-21-back.mp4' is only 595 bytes
Thu  3 Oct 10:09:53 EDT 2019: '2019-10-03_10-08-45/2019-10-03_10-00-21-front.mp4' is only 595 bytes
Thu  3 Oct 10:09:53 EDT 2019: '2019-10-03_10-08-45/2019-10-03_10-00-21-left_repeater.mp4' is only 595 bytes
Thu  3 Oct 10:09:53 EDT 2019: '2019-10-03_10-08-45/2019-10-03_10-00-21-right_repeater.mp4' is only 595 bytes
Thu  3 Oct 10:09:53 EDT 2019: '2019-10-03_10-08-45/2019-10-03_10-00-21-back.mp4' is only 595 bytes
Thu  3 Oct 10:09:53 EDT 2019: '2019-10-03_10-08-45/2019-10-03_10-01-21-front.mp4' is only 595 bytes
Thu  3 Oct 10:09:53 EDT 2019: '2019-10-03_10-08-45/2019-10-03_10-01-21-left_repeater.mp4' is only 595 bytes
Thu  3 Oct 10:09:53 EDT 2019: '2019-10-03_10-08-45/2019-10-03_10-01-21-right_repeater.mp4' is only 595 bytes
Thu  3 Oct 10:09:53 EDT 2019: '2019-10-03_10-08-45/2019-10-03_10-01-21-back.mp4' is only 595 bytes
Thu  3 Oct 10:09:53 EDT 2019: '2019-10-03_10-08-45/2019-10-03_10-02-22-front.mp4' is only 595 bytes
Thu  3 Oct 10:09:53 EDT 2019: '2019-10-03_10-08-45/2019-10-03_10-02-22-left_repeater.mp4' is only 595 bytes
Thu  3 Oct 10:09:53 EDT 2019: '2019-10-03_10-08-45/2019-10-03_10-02-22-right_repeater.mp4' is only 595 bytes
Thu  3 Oct 10:09:53 EDT 2019: '2019-10-03_10-08-45/2019-10-03_10-02-22-back.mp4' is only 595 bytes
Thu  3 Oct 10:09:53 EDT 2019: '2019-10-03_10-08-45/2019-10-03_10-03-22-front.mp4' is only 595 bytes
Thu  3 Oct 10:09:53 EDT 2019: '2019-10-03_10-08-45/2019-10-03_10-03-22-left_repeater.mp4' is only 595 bytes
Thu  3 Oct 10:09:53 EDT 2019: '2019-10-03_10-08-45/2019-10-03_10-03-22-right_repeater.mp4' is only 595 bytes
Thu  3 Oct 10:09:53 EDT 2019: '2019-10-03_10-08-45/2019-10-03_10-03-22-back.mp4' is only 595 bytes
Thu  3 Oct 10:09:53 EDT 2019: '2019-10-03_10-08-45/2019-10-03_10-04-22-front.mp4' is only 595 bytes
Thu  3 Oct 10:09:53 EDT 2019: '2019-10-03_10-08-45/2019-10-03_10-04-22-left_repeater.mp4' is only 595 bytes
Thu  3 Oct 10:09:53 EDT 2019: '2019-10-03_10-08-45/2019-10-03_10-04-22-right_repeater.mp4' is only 595 bytes
Thu  3 Oct 10:09:53 EDT 2019: '2019-10-03_10-08-45/2019-10-03_10-04-22-back.mp4' is only 595 bytes
Thu  3 Oct 10:09:54 EDT 2019: '2019-10-03_10-08-45/2019-10-03_10-05-23-front.mp4' is only 595 bytes
Thu  3 Oct 10:09:54 EDT 2019: '2019-10-03_10-08-45/2019-10-03_10-05-23-left_repeater.mp4' is only 595 bytes
Thu  3 Oct 10:09:54 EDT 2019: '2019-10-03_10-08-45/2019-10-03_10-05-23-right_repeater.mp4' is only 595 bytes
Thu  3 Oct 10:09:54 EDT 2019: '2019-10-03_10-08-45/2019-10-03_10-05-23-back.mp4' is only 595 bytes
Thu  3 Oct 10:09:54 EDT 2019: '2019-10-03_10-08-45/2019-10-03_10-06-23-front.mp4' is only 595 bytes
Thu  3 Oct 10:09:54 EDT 2019: '2019-10-03_10-08-45/2019-10-03_10-06-23-left_repeater.mp4' is only 595 bytes
Thu  3 Oct 10:09:54 EDT 2019: '2019-10-03_10-08-45/2019-10-03_10-06-23-right_repeater.mp4' is only 595 bytes
Thu  3 Oct 10:09:54 EDT 2019: '2019-10-03_10-08-45/2019-10-03_10-06-23-back.mp4' is only 595 bytes
Thu  3 Oct 10:09:54 EDT 2019: '2019-10-03_10-08-45/2019-10-03_10-07-36-front.mp4' is only 595 bytes
Thu  3 Oct 10:09:54 EDT 2019: '2019-10-03_10-08-45/2019-10-03_10-07-36-left_repeater.mp4' is only 595 bytes
Thu  3 Oct 10:09:54 EDT 2019: '2019-10-03_10-08-45/2019-10-03_10-07-36-right_repeater.mp4' is only 595 bytes
Thu  3 Oct 10:09:54 EDT 2019: '2019-10-03_10-08-45/2019-10-03_10-07-36-back.mp4' is only 595 bytes
Thu  3 Oct 10:09:54 EDT 2019: '2019-10-03_10-08-45/2019-10-03_10-08-37-front.mp4' is only 595 bytes
Thu  3 Oct 10:09:54 EDT 2019: '2019-10-03_10-08-45/2019-10-03_10-08-37-left_repeater.mp4' is only 595 bytes
Thu  3 Oct 10:09:54 EDT 2019: '2019-10-03_10-08-45/2019-10-03_10-08-37-right_repeater.mp4' is only 595 bytes
Thu  3 Oct 10:09:54 EDT 2019: '2019-10-03_10-08-45/2019-10-03_10-08-37-back.mp4' is only 595 bytes
Thu  3 Oct 10:09:54 EDT 2019: Moved 0 file(s), failed to copy 0, deleted 44.

im getting no files uploaded since the update i ran yesterday...

[DMBlakeley]

The RPi0w does not have a real time clock capability. When the RPi wakes up time is at the default and then needs to sync and why you are getting the message. The buster version seems to need to sync each time a sync is called even if already synced while the stretch version does not. If you are using rclone options the time does need to be correct.

[marcone]

@fatfurrycat the snapshots are a history of files that existed in the main disk image at some point in time. If archiveable files exist in a snapshot, they should have been archived because the main disk image (which is what actually gets archived) will have contained those files. If they didn't get archived, you can check /mutable/archiveloop.log to see what went wrong (though normally files that didn't get archived would still exist on the main disk image).

@th3fallen 595-byte files is a car problem, and resetting the MCU should resolve it.

[miles267]

I installed the teslausb-buster-20190922 base image. However I did not make any modifications to these commented lines of the .conf file and perhaps I should have?

• Uncomment and change if you want a different branch than main-dev
• export BRANCH=main-dev

No, you're good. I think the only deviation I made other than the obvious was to enable CIFS 3.0. But none of this should impact the ability for the dashcam icon to come up in the car. Unplug/plug the Pi and reset the MCU and see if that makes it appear (more curious than anything else, as it worked for me this AM)

@acraigl unfortunately that didn't work. Am using a 128 GB microSD card and used the defaults in the .conf file. One of which is to use 100% of the card. Are there any small nuances I should make to the .conf? I'm not planning to use it for music or anything other than sentry, dashcam videos.

[fatfurrycat]

@marcone The only obvious errors in the log are: Wed 2 Oct 21:52:15 BST 2019: Archiving... Wed 2 Oct 21:52:15 BST 2019: Disconnecting usb from host... Wed 2 Oct 21:52:15 BST 2019: Disconnected usb from host. Wed 2 Oct 21:52:15 BST 2019: Ensuring cam archive is mounted... Wed 2 Oct 21:52:15 BST 2019: Mounting /mnt/archive... Wed 2 Oct 21:52:16 BST 2019: Mounted /mnt/archive. Wed 2 Oct 21:52:16 BST 2019: Ensured cam archive is mounted. Wed 2 Oct 21:52:16 BST 2019: Checking saved folder count... Wed 2 Oct 21:52:16 BST 2019: Ensuring cam file is mounted... Wed 2 Oct 21:52:16 BST 2019: Mounting /mnt/cam... Wed 2 Oct 21:52:16 BST 2019: Mounted /mnt/cam. Wed 2 Oct 21:52:16 BST 2019: Ensured cam file is mounted. Wed 2 Oct 21:52:16 BST 2019: Running fsck on /mnt/cam... Wed 2 Oct 21:52:16 BST 2019: | fsck from util-linux 2.29.2 Wed 2 Oct 21:52:18 BST 2019: | fsck.fat 4.1 (2017-01-24) Wed 2 Oct 21:52:18 BST 2019: | 0x41: Dirty bit is set. Fs was not properly unmounted and some data may be corrupt. Wed 2 Oct 21:52:18 BST 2019: | Automatically removing dirty bit. Wed 2 Oct 21:52:18 BST 2019: | FATs differ but appear to be intact. Using first FAT. Wed 2 Oct 21:52:18 BST 2019: | /TeslaCam/RecentClips/2019-10-02_13-08-24-front.mp4 Wed 2 Oct 21:52:18 BST 2019: | Contains a free cluster (589824). Assuming EOF. Wed 2 Oct 21:52:18 BST 2019: | /TeslaCam/RecentClips/2019-10-02_13-08-24-front.mp4 Wed 2 Oct 21:52:18 BST 2019: | File size is 38137681 bytes, cluster chain length is 13336576 bytes. Wed 2 Oct 21:52:19 BST 2019: | Truncating file to 13336576 bytes. Wed 2 Oct 21:52:19 BST 2019: | /TeslaCam/RecentClips/2019-10-02_13-09-24-right_repeater.mp4 Wed 2 Oct 21:52:19 BST 2019: | Contains a free cluster (601088). Assuming EOF. Wed 2 Oct 21:52:19 BST 2019: | /TeslaCam/RecentClips/2019-10-02_13-09-24-right_repeater.mp4 Wed 2 Oct 21:52:19 BST 2019: | File size is 37949802 bytes, cluster chain length is 10371072 bytes. Wed 2 Oct 21:52:19 BST 2019: | Truncating file to 10371072 bytes. Wed 2 Oct 21:52:19 BST 2019: | /TeslaCam/RecentClips/2019-10-02_13-13-26-front.mp4 Wed 2 Oct 21:52:19 BST 2019: | Contains a free cluster (624640). Assuming EOF. Wed 2 Oct 21:52:19 BST 2019: | /TeslaCam/RecentClips/2019-10-02_13-13-26-front.mp4 Wed 2 Oct 21:52:19 BST 2019: | File size is 37980918 bytes, cluster chain length is 25182208 bytes. Wed 2 Oct 21:52:19 BST 2019: | Truncating file to 25182208 bytes. Wed 2 Oct 21:52:19 BST 2019: | /TeslaCam/RecentClips/2019-10-02_13-13-26-left_repeater.mp4 Wed 2 Oct 21:52:19 BST 2019: | Contains a free cluster (625422). Assuming EOF. Wed 2 Oct 21:52:19 BST 2019: | /TeslaCam/RecentClips/2019-10-02_13-13-26-left_repeater.mp4 Wed 2 Oct 21:52:19 BST 2019: | File size is 37815180 bytes, cluster chain length is 0 bytes. Wed 2 Oct 21:52:19 BST 2019: | Truncating file to 0 bytes. Wed 2 Oct 21:52:19 BST 2019: | /TeslaCam/RecentClips/2019-10-02_13-17-28-front.mp4 Wed 2 Oct 21:52:19 BST 2019: | Contains a free cluster (652288). Assuming EOF. Wed 2 Oct 21:52:19 BST 2019: | /TeslaCam/RecentClips/2019-10-02_13-17-28-front.mp4 Wed 2 Oct 21:52:19 BST 2019: | File size is 37002682 bytes, cluster chain length is 29278208 bytes. Wed 2 Oct 21:52:19 BST 2019: | Truncating file to 29278208 bytes. Wed 2 Oct 21:52:19 BST 2019: | /TeslaCam/RecentClips/2019-10-02_13-17-28-left_repeater.mp4 Wed 2 Oct 21:52:19 BST 2019: | Contains a free cluster (652760). Assuming EOF. Wed 2 Oct 21:52:19 BST 2019: | /TeslaCam/RecentClips/2019-10-02_13-17-28-left_repeater.mp4 Wed 2 Oct 21:52:19 BST 2019: | File size is 37262649 bytes, cluster chain length is 0 bytes. Wed 2 Oct 21:52:19 BST 2019: | Truncating file to 0 bytes. Wed 2 Oct 21:52:19 BST 2019: | /TeslaCam/RecentClips/2019-10-02_13-18-29-front.mp4 Wed 2 Oct 21:52:19 BST 2019: | Contains a free cluster (659456). Assuming EOF. Wed 2 Oct 21:52:19 BST 2019: | /TeslaCam/RecentClips/2019-10-02_13-18-29-front.mp4 Wed 2 Oct 21:52:19 BST 2019: | File size is 38241682 bytes, cluster chain length is 34848768 bytes. Wed 2 Oct 21:52:19 BST 2019: | Truncating file to 34848768 bytes. Wed 2 Oct 21:52:19 BST 2019: | /TeslaCam/RecentClips/2019-10-02_13-18-29-left_repeater.mp4 Wed 2 Oct 21:52:19 BST 2019: | Contains a free cluster (659664). Assuming EOF. Wed 2 Oct 21:52:19 BST 2019: | /TeslaCam/RecentClips/2019-10-02_13-18-29-left_repeater.mp4 Wed 2 Oct 21:52:19 BST 2019: | File size is 35858493 bytes, cluster chain length is 0 bytes. Wed 2 Oct 21:52:19 BST 2019: | Truncating file to 0 bytes. Wed 2 Oct 21:52:19 BST 2019: | Reclaimed 6313 unused clusters (103432192 bytes) in 5 chains. Wed 2 Oct 21:52:19 BST 2019: | Free cluster summary wrong (891083 vs. really 1103807) Wed 2 Oct 21:52:19 BST 2019: | Auto-correcting. Wed 2 Oct 21:52:19 BST 2019: | Performing changes. Wed 2 Oct 21:52:19 BST 2019: | /dev/loop8: 552 files, 968077/2071884 clusters Wed 2 Oct 21:52:19 BST 2019: Finished fsck on /mnt/cam. Wed 2 Oct 21:52:19 BST 2019: There are 34 event folder(s) with 441 file(s) to move. Wed 2 Oct 21:52:19 BST 2019: Starting recording archiving: 34 event folder(s) with 441 file(s)

and then: Wed 2 Oct 22:19:26 BST 2019: Archiving... Wed 2 Oct 22:19:26 BST 2019: Disconnecting usb from host... Wed 2 Oct 22:19:26 BST 2019: Disconnected usb from host. Wed 2 Oct 22:19:26 BST 2019: Ensuring cam archive is mounted... Wed 2 Oct 22:19:26 BST 2019: Mounting /mnt/archive... Wed 2 Oct 22:19:26 BST 2019: Mounted /mnt/archive. Wed 2 Oct 22:19:26 BST 2019: Ensured cam archive is mounted. Wed 2 Oct 22:19:27 BST 2019: Checking saved folder count... Wed 2 Oct 22:19:27 BST 2019: Ensuring cam file is mounted... Wed 2 Oct 22:19:27 BST 2019: Mounting /mnt/cam... Wed 2 Oct 22:19:27 BST 2019: Mounted /mnt/cam. Wed 2 Oct 22:19:27 BST 2019: Ensured cam file is mounted. Wed 2 Oct 22:19:27 BST 2019: Running fsck on /mnt/cam... Wed 2 Oct 22:19:27 BST 2019: | fsck from util-linux 2.29.2 Wed 2 Oct 22:19:30 BST 2019: | fsck.fat 4.1 (2017-01-24) Wed 2 Oct 22:19:30 BST 2019: | FATs differ but appear to be intact. Using first FAT. Wed 2 Oct 22:19:30 BST 2019: | /TeslaCam/RecentClips/2019-10-02_13-05-22-front.mp4 Wed 2 Oct 22:19:30 BST 2019: | Contains a free cluster (569078). Assuming EOF. Wed 2 Oct 22:19:30 BST 2019: | /TeslaCam/RecentClips/2019-10-02_13-05-22-front.mp4 Wed 2 Oct 22:19:30 BST 2019: | File size is 38365913 bytes, cluster chain length is 0 bytes. Wed 2 Oct 22:19:30 BST 2019: | Truncating file to 0 bytes. Wed 2 Oct 22:19:30 BST 2019: | Reclaimed 43723 unused clusters (716357632 bytes) in 20 chains. Wed 2 Oct 22:19:30 BST 2019: | Free cluster summary wrong (1123601 vs. really 1087340) Wed 2 Oct 22:19:30 BST 2019: | Auto-correcting. Wed 2 Oct 22:19:30 BST 2019: | Performing changes. Wed 2 Oct 22:19:30 BST 2019: | /dev/loop8: 557 files, 984544/2071884 clusters Wed 2 Oct 22:19:30 BST 2019: Finished fsck on /mnt/cam. Wed 2 Oct 22:19:31 BST 2019: There are 34 event folder(s) with 426 file(s) to move. Wed 2 Oct 22:19:31 BST 2019: Starting recording archiving: 34 event folder(s) with 426 file(s) Wed 2 Oct 22:19:31 BST 2019: Moving clips to archive...

However, none of the errors are in SavedClips, so I figure it shouldn't matter. If we assume that there are 426 files that need to be moved as of the 2 Oct 22:19:31 timestamp, then I should see the same number of lines in the log which say 'Moved', but I don't. There are only 392 'Moved' entries, with the last being for the file: '2019-10-02_13-05-21/2019-10-02_13-04-13-right_repeater.mp4'

However, the snap-000095.bin file contains the following extra files, which haven't been archived: 36610533 SavedClips/2019-10-02_21-43-37/2019-10-02_21-33-20-front.mp4 36942948 SavedClips/2019-10-02_21-43-37/2019-10-02_21-33-20-left_repeater.mp4 37589093 SavedClips/2019-10-02_21-43-37/2019-10-02_21-33-20-right_repeater.mp4 36823625 SavedClips/2019-10-02_21-43-37/2019-10-02_21-34-20-front.mp4 37429495 SavedClips/2019-10-02_21-43-37/2019-10-02_21-34-20-left_repeater.mp4 37109500 SavedClips/2019-10-02_21-43-37/2019-10-02_21-34-20-right_repeater.mp4 36349024 SavedClips/2019-10-02_21-43-37/2019-10-02_21-35-21-front.mp4 36972043 SavedClips/2019-10-02_21-43-37/2019-10-02_21-35-21-left_repeater.mp4 35974200 SavedClips/2019-10-02_21-43-37/2019-10-02_21-35-21-right_repeater.mp4 37366014 SavedClips/2019-10-02_21-43-37/2019-10-02_21-36-21-front.mp4 37328261 SavedClips/2019-10-02_21-43-37/2019-10-02_21-36-21-left_repeater.mp4 36011772 SavedClips/2019-10-02_21-43-37/2019-10-02_21-36-21-right_repeater.mp4 36880939 SavedClips/2019-10-02_21-43-37/2019-10-02_21-37-22-front.mp4 36806367 SavedClips/2019-10-02_21-43-37/2019-10-02_21-37-22-left_repeater.mp4 37129101 SavedClips/2019-10-02_21-43-37/2019-10-02_21-37-22-right_repeater.mp4 36937383 SavedClips/2019-10-02_21-43-37/2019-10-02_21-38-22-front.mp4 36905183 SavedClips/2019-10-02_21-43-37/2019-10-02_21-38-22-left_repeater.mp4 36889796 SavedClips/2019-10-02_21-43-37/2019-10-02_21-38-22-right_repeater.mp4 36951196 SavedClips/2019-10-02_21-43-37/2019-10-02_21-39-23-front.mp4 36272413 SavedClips/2019-10-02_21-43-37/2019-10-02_21-39-23-left_repeater.mp4 36930798 SavedClips/2019-10-02_21-43-37/2019-10-02_21-39-23-right_repeater.mp4 36547309 SavedClips/2019-10-02_21-43-37/2019-10-02_21-40-24-front.mp4 36162210 SavedClips/2019-10-02_21-43-37/2019-10-02_21-40-24-left_repeater.mp4 36785988 SavedClips/2019-10-02_21-43-37/2019-10-02_21-40-24-right_repeater.mp4 37490185 SavedClips/2019-10-02_21-43-37/2019-10-02_21-41-25-front.mp4 36484932 SavedClips/2019-10-02_21-43-37/2019-10-02_21-41-25-left_repeater.mp4 36809420 SavedClips/2019-10-02_21-43-37/2019-10-02_21-41-25-right_repeater.mp4 35916279 SavedClips/2019-10-02_21-43-37/2019-10-02_21-42-25-front.mp4 36203958 SavedClips/2019-10-02_21-43-37/2019-10-02_21-42-25-left_repeater.mp4 36531215 SavedClips/2019-10-02_21-43-37/2019-10-02_21-42-25-right_repeater.mp4 3199202 SavedClips/2019-10-02_21-43-37/2019-10-02_21-43-26-front.mp4 4137268 SavedClips/2019-10-02_21-43-37/2019-10-02_21-43-26-left_repeater.mp4 3132387 SavedClips/2019-10-02_21-43-37/2019-10-02_21-43-26-right_repeater.mp4

The log file shows that the code thinks that snap-000094 and snap-000095 are the same, but they aren't if you diff them.

In the log, the problem seems to happen here: Thu 3 Oct 09:09:04 BST 2019: /mnt/cam/TeslaCam/SentryClips does not exist, skipping Thu 3 Oct 09:09:04 BST 2019: Moved 392 file(s), failed to copy 0, deleted 0. Thu 3 Oct 09:09:04 BST 2019: Unmounting /mnt/cam... Thu 3 Oct 09:09:05 BST 2019: Unmounted /mnt/cam. Thu 3 Oct 09:09:05 BST 2019: Finished archiving. Thu 3 Oct 09:09:05 BST 2019: Music archive not configured or unreachable Thu 3 Oct 09:09:05 BST 2019: unmounting /mnt/archive Thu 3 Oct 09:09:05 BST 2019: Connecting usb to host... Thu 3 Oct 09:09:05 BST 2019: Connected usb to host. Thu 3 Oct 09:09:06 BST 2019: Truncating log... Thu 3 Oct 09:09:06 BST 2019: Waiting for archive to be unreachable...

The archive loop seems to think that it's finished after 392 files, but there are still another 33 files to be moved.

Any thoughts on how that might happen? If I plug the Pi into my machine, then the TeslaCam directory currently has no files in either SavedClips or RecentClips. I've not yet tried it in the car since I updated to v10. archiveloop.log

[marcone]

However, the snap-000095.bin file contains the following extra files, which haven't been archived: 36610533 SavedClips/2019-10-02_21-43-37/2019-10-02_21-33-20-front.mp4

Looking for that specific file in the diagnostics you attached earlier, I see it first appear in snapshot 91:

Wed  2 Oct 21:50:59 BST 2019: taking snapshot of cam disk: /backingfiles/snapshots/snap-000091/snap.bin
...
Wed  2 Oct 21:52:11 BST 2019: linking /backingfiles/snapshots/newsnap/mnt/TeslaCam/SavedClips/2019-10-02_21-43-37/2019-10-02_21-33-20-front.mp4

It then continues to be present in snapshots 92, 93 and 94, but snapshot 95 no longer has it, per your diagnostics. Can you check the .toc files for those snapshots to see which ones actually list that file?

The log file shows that the code thinks that snap-000094 and snap-000095 are the same, but they aren't if you diff them.

The log message is misleading in that it checks whether there are any new/updated files in the new snapshot, not whether the two snapshots are exactly identical. Also note that it creates snapshot 95 several time in your diagnostics. The first 10 times it discards them because there have been no new files since the previous time. After that it does find new files and creates a new snapshot 95:

Thu  3 Oct 09:41:23 BST 2019: taking snapshot of cam disk: /backingfiles/snapshots/snap-000095/snap.bin
Thu  3 Oct 09:41:26 BST 2019: took snapshot
Thu  3 Oct 09:41:27 BST 2019: comparing /backingfiles/snapshots/snap-000094/snap.bin.toc and /backingfiles/snapshots/newsnap/snap.bin.toc
Thu  3 Oct 09:41:27 BST 2019: making links for /backingfiles/snapshots/newsnap/mnt, retargeted to /backingfiles/snapshots/snap-000095/mnt

however that snapshot does not appear to contain the "2019-10-02_21-33-20-front.mp4" file anymore, since it is not creating a link for it. The only explanation I can think of for that is that either the car deleted it because it needed space (you would need to be on v10 for that), or the file ended up being corrupted and fsck deleted it.

[fatfurrycat]

@marcone Thanks for looking at this. I've now gone and extracted the snap.bin files from snap-000093, 000094 and 000095. When mounted, the snap-000095 image is indeed empty of all files. However, both snap-000093 and snap-000094 do contain all of the files that are missing from the archive. I've managed to recover what I needed, so that's a good start.

However, I'd still like to understand why this happened.

As far as the .toc files go, then the 93 and 94 files do contain the reference to the "2019-10-02_21-33-20-front.mp4" file, and the image contains the file itself (as well as all the others). The 95 toc file doesn't contain the filename, but does still have some filenames in, which is odd given that it's empty of any video files. I've attached the .toc files, in case they are of any use.

When mounting the snap-000094 image, then I do see the following: total 882852 drwxr-xr-x. 6 root root 16384 Jan 1 1970 . drwxr-xr-x. 5 root root 4096 Oct 3 22:56 .. drwxr-xr-x. 3 root root 16384 Sep 19 10:38 Android -rwxr-xr-x. 1 root root 0 Jan 1 1980 FSCK0000.REC -rwxr-xr-x. 1 root root 0 Jan 1 1980 FSCK0001.REC -rwxr-xr-x. 1 root root 0 Jan 1 1980 FSCK0002.REC -rwxr-xr-x. 1 root root 0 Jan 1 1980 FSCK0003.REC -rwxr-xr-x. 1 root root 0 Jan 1 1980 FSCK0004.REC -rwxr-xr-x. 1 root root 0 Jan 1 1980 FSCK0005.REC -rwxr-xr-x. 1 root root 23445504 Jan 1 1980 FSCK0006.REC -rwxr-xr-x. 1 root root 35667968 Jan 1 1980 FSCK0007.REC -rwxr-xr-x. 1 root root 36274176 Jan 1 1980 FSCK0008.REC -rwxr-xr-x. 1 root root 37257216 Jan 1 1980 FSCK0009.REC -rwxr-xr-x. 1 root root 36077568 Jan 1 1980 FSCK0010.REC -rwxr-xr-x. 1 root root 37371904 Jan 1 1980 FSCK0011.REC -rwxr-xr-x. 1 root root 37339136 Jan 1 1980 FSCK0012.REC -rwxr-xr-x. 1 root root 37617664 Jan 1 1980 FSCK0013.REC -rwxr-xr-x. 1 root root 35930112 Jan 1 1980 FSCK0014.REC -rwxr-xr-x. 1 root root 37273600 Jan 1 1980 FSCK0015.REC -rwxr-xr-x. 1 root root 37191680 Jan 1 1980 FSCK0016.REC -rwxr-xr-x. 1 root root 36192256 Jan 1 1980 FSCK0017.REC -rwxr-xr-x. 1 root root 36143104 Jan 1 1980 FSCK0018.REC -rwxr-xr-x. 1 root root 35569664 Jan 1 1980 FSCK0019.REC -rwxr-xr-x. 1 root root 36896768 Jan 1 1980 FSCK0020.REC -rwxr-xr-x. 1 root root 37208064 Jan 1 1980 FSCK0021.REC -rwxr-xr-x. 1 root root 36765696 Jan 1 1980 FSCK0022.REC -rwxr-xr-x. 1 root root 35733504 Jan 1 1980 FSCK0023.REC -rwxr-xr-x. 1 root root 36388864 Jan 1 1980 FSCK0024.REC -rwxr-xr-x. 1 root root 37453824 Jan 1 1980 FSCK0025.REC -rwxr-xr-x. 1 root root 36421632 Jan 1 1980 FSCK0026.REC -rwxr-xr-x. 1 root root 36388864 Jan 1 1980 FSCK0027.REC -rwxr-xr-x. 1 root root 36913152 Jan 1 1980 FSCK0028.REC -rwxr-xr-x. 1 root root 37224448 Jan 1 1980 FSCK0029.REC -rwxr-xr-x. 1 root root 37208064 Jan 1 1980 FSCK0030.REC drwxr-xr-x. 2 root root 16384 Sep 19 10:37 LOST.DIR drwxr-xr-x. 2 root root 16384 Sep 18 15:43 System Volume Information drwxr-xr-x. 4 root root 16384 Oct 2 14:51 TeslaCam

which would seem to indicate that there was some corruption. However. the archivelog indicates that this corruption was only in the RecentFiles directory, and not SavedClips.

The car can't have deleted the files, as I wasn't running v10 when this happened. Overnight, I have updated to v10, though.

One final question. From what I'm reading, simply having updated in the last couple of days from the main-dev branch should be sufficient to correctly support v10?

Given that something appears to have gone a bit wonky with the snapshots, what would be the best way to recover? Can I simply delete all of the snapshot folders? Is there an index I need to reset?

Thanks again for your help, and work on this project. It's much appreciated.

snap-000093.bin.toc.txt snap-000094.bin.toc.txt snap-000095.bin.toc.txt

[th3fallen]

Anyone else get the dreaded USB write speed too low after this update? Been using this 4 months and this is the first time I've seen it?

[vita10gy]

That's what this discussion has become about. I think it's more of us than not.

https://github.com/marcone/teslausb/issues/239

[acraigl]

Anyone else get the dreaded USB write speed too low after this update? Been using this 4 months and this is the first time I've seen it?

Yup :(

[teslajive]

Anyone else get the dreaded USB write speed too low after this update? Been using this 4 months and this is the first time I've seen it?

Yup :(

Same here :/

[miles267]

Just when I had everything working correctly with v10, a day later and I've started receiving the USB write speed too slow error with buster release and my RP0. Seemed to work for about 24 hours, just sitting in the garage on WiFi without even driving around or having a true need to capture much video if any at all. The next morning, the error appeared. In my case have been using a SanDisk Ultra 128 GB microSD without issue. Was going to upgrade it to a SanDisk Extreme but now am not convinced it's the card itself.

[acraigl]

Just when I had everything working correctly with v10, a day later and I've started receiving the USB write speed too slow error with buster release and my RP0. Seemed to work for about 24 hours, just sitting in the garage on WiFi without even driving around or having a true need to capture much video if any at all. The next morning, the error appeared. In my case have been using a SanDisk Ultra 128 GB microSD without issue. Was going to upgrade it to a SanDisk Extreme but now am not convinced it's the card itself.

It's either something with v10 (more likely) or with the Buster build. Also, only with sentry mode recordings. It will continue to work with normal front-cam driving without issue. I have the same card in both 128 and 200GB versions. I've moved back to the 200GB to see if that makes a difference (it shouldn't).

[miles267]

Just curious what the reasoning was for moving to this buster release? I’ve only ever been on buster with teslausb and have never experienced a working configuration. Or rather one that doesn’t quickly result in the slow disk symptom.

In other words, will v10 work with the former stretch image?

[acraigl]

Just curious what the reasoning was for moving to this buster release? I’ve only ever been on buster with teslausb and have never experienced a working configuration. Or rather one that doesn’t quickly result in the slow disk symptom.

In other words, will v10 work with the former stretch image?

I don't think we're saying it's the teslaUSB release, rather it, in combination with the Tesla v10 software. Only @marcone and maybe a few other can say that for sure though.

[marcone]

It's either something with v10 (more likely) or with the Buster build.

people were reporting "usb too slow" problems before v10 and before Buster. It probably became more common with v10 because it records 33% more video.

Also, only with sentry mode recordings. It will continue to work with normal front-cam driving without issue.

There is no such thing as "normal front-cam driving". The car always records front, left and right, and in v10 also the rear camera.

[marcone]

In other words, will v10 work with the former stretch image?

Yes, it will.

[acraigl]

It's either something with v10 (more likely) or with the Buster build.

people were reporting "usb too slow" problems before v10 and before Buster. It probably became more common with v10 because it records 33% more video.

Also, only with sentry mode recordings. It will continue to work with normal front-cam driving without issue.

There is no such thing as "normal front-cam driving". The car always records front, left and right, and in v10 also the rear camera.

Fair enough. I only meant that I only see the slow USB issue coming back to my car after it's parked for a while. I have yet to see it outside of sentry mode.

[vita10gy]

I got the errors before re running the setup and after doing that to update, though I presume that didn't actually update the whole os to buster.

If that's the case basically all permutations have the issue.

Also, for the record, I had the car bail on "normal driving recording" too.

[acraigl]

I'm using a Sandisk Ultra 128 (rated at up to 100MB/s). I may try the Extreme Pro (up to 170MB/s) and see if that resolves the issue. But with USB 2.0 I'm not sure it will make a ton of difference either way. I'm still shocked this car doesn't have USB 3.0 up front.

[miles267]

I'm using a Sandisk Ultra 128 (rated at up to 100MB/s). I may try the Extreme Pro (up to 170MB/s) and see if that resolves the issue. But with USB 2.0 I'm not sure it will make a ton of difference either way. I'm still shocked this car doesn't have USB 3.0 up front.

Yes, it does seem strange. Maybe available as a future upgrade. Have reverted back my USB Samsung SSD for the time being, but have kept my RP0 on WIFI so I'm prepared to push any future updates to it if/when the root cause of this issue is identified. Of course, I'm glad to help test any config as needed.

[andrewgarfield]

Was just reading through this thread. I had an raspberry pi zero w working great using this project until v10 came out. I upgraded to the latest version of teslausb and while it was working I was getting the error about the writes being too slow. And my Model 3 rejected further usage of it as a dash cam.

Yesterday I switched to using a raspberry pi 4B using the pre-release 2.0 image of teslausb, and for the last 24 hours it's worked great!

Only issue I have seen is that the red light on the raspberry pi 4 stays on all the times when connected to the car (it doesn't happen when connected to a computer). But it still seems to function normally.

[miles267]

@andrewgarfield this is good info. I have a new unused RP4 here now. What are you using to power the RP4 in your car? Wasn’t sure whether it can use just a USB cable like the RP0?

[andrewgarfield]

@andrewgarfield this is good info. I have a new unused RP4 here now. What are you using to power the RP4 in your car? Wasn’t sure whether it can use just a USB cable like the RP0?

@miles267 I am using a single USB cable just like the raspberry pi zero only with a USB to USB-C adapter, so far it's holding up. It's on a Y cable for powering my nomad wireless pad too. So far, no issues. But, only have a day under my belt with it.

[miles267]

@andrewgarfield nice! Am going to try it on my end also. What did you use for camsize? Also did you use nofua=1,1?

[Pedals2Paddles]

I'm still on an image from back in the spring. It continues to work fine without error, but of course it isn't moving the sentry clips anymore. Can I just update the directories in the script and expect it to keep working fine?

[andrewgarfield]

@miles267 I used the same config file (no changes) as did with my rpi zero install. This was with a 100% camsize. I have not made any further modifications past what is in the default install (regarding the nofua).

[miles267]

I’ve recently installed buster on a 128GB SanDisk Ultra microSD card with camsize=32G and all default settings on a RP4. The same card w RP0 quickly exhibited the slow write speed error. However this config has been working for several hours. Also it can connect to WiFi at 5Ghz for uploading to CIFS 3.0 file share. Hope it continues to work. Will report back soon.

[acraigl]

Doesn't the Pi 4 require a 15w power source? I'm surprised it's working.

[miles267]

Just read it consumes 2.85 watts at idle which it is most of the time.