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.

[MikeBishop]

As described, this shouldn't matter for an instance that uploads regularly. If there were some reserved space to tuck recordings aside, you could prevent the Tesla from deleting them, but if that space were visible to the Tesla, you wouldn't hit the "not enough space" condition until you'd filled it anyway.

All in all, this looks like a no-op unless you have a smarter way to decide what to delete when full than "oldest."

[marcone]

The "now saved in a separate folder" bit might indicate some path(s) need to be updated in Teslausb.

[sottile]

Yup, indeed this archive loop function needs to be updated to search BOTH SavedClips and SentryClips

function archive_teslacam_clips () { ... DIR_COUNT=$(find "$CAM_MOUNT"/TeslaCam/SavedClips/* -maxdepth 0 -type d | wc -l) FILE_COUNT=$(find "$CAM_MOUNT"/TeslaCam/SavedClips/* -type f | wc -l) ...

and in archive_clips

It's probably worth it to future proof this and only EXCLUDE the "RecentClips" and the loop through all other directories and push the files.

Side note, using / can be problematic. I can see that it is used in a lot of places. If there are a LOT of files, you can exceed the max command line with the glob expansion. In this case, it's probably better to eliminate the / in both commands as they aren't necessary in this case. If you're trying to make sure it's a directory, using /. is better as in find "$CAM_MOUNT"/TeslaCam/SavedClips/. (and so on)

[SemoTech]

Thank you @sottile & @marcone

Do you know if these changes have already been added to the code, so I can update my Pi? I am running early access V10 (2019.32.2.11) on my TM3 and this change has already occurred for me.

Appreciated!

[marcone]

No, not yet

[SemoTech]

No, not yet

No rush @marcone but will be very excited once its' done. Will check back here....

[txex95]

Might also want to keep the folder structure of the transferred files to differentiate the Saved vs Sentry clips in the destination share.

[txex95]

Not very experienced programming. But willing to give it a shot. Does the SavedClips lines just need to be duplicated for SentryClips to capture both or is there more to it? Otherwise SD card is filling up with sentry clips.

[acraigl]

USB Sync to my NAS hasn't happened since I got v10. Only discovered it (not working) yesterday. Nothing uploaded since 9/21. I'll reflash and see if that changes anything in case something was corrupted during the firmware update.

[acraigl]

USB Sync to my NAS hasn't happened since I got v10. Only discovered it (not working) yesterday. Nothing uploaded since 9/21. I'll reflash and see if that changes anything in case something was corrupted during the firmware update.

Just posting back -- reflashed (latest beta, FWIW) and confirmed I have video files recording. Can SSH to the device no problem, but archiving isn't happening. When I tried to manually kick off the archiveloop script, it said it was already running. :|

[marcone]

The current archive scripts don't take into account the new "SentryClips" folder. You can try the "v10" branch where I added some (untested, since I don't have v10 yet) code to archive SentryClips too.

[acraigl]

The current archive scripts don't take into account the new "SentryClips" folder. You can try the "v10" branch where I added some (untested, since I don't have v10 yet) code to archive SentryClips too.

Thanks. Thinks are still a bit wonky. Like, I only see the dashcam icon on my screen when I return home. ??? With v10 rolling to everyone now, I'm sure you'll work this out.

[SemoTech]

Buster Release Image working perfectly following Tesla Firmware 2019.32.10.1 (v10 release)! All features confirmed functional.
Great job @marcone!

[acraigl]

Buster Release Image working perfectly following Tesla Firmware 2019.32.10.1 (v10 release)! All features confirmed functional. Great job @marcone!

@SemoTech I wish I was so lucky. The dashcam icon never enables for me, and everything else seems to check out... can ssh to it, install completes successfully, etc. :( Can you post your config maybe? (redacting the personal info, obviously.)

[acraigl]

@marcone did a dmesg, assuming this is bad? Using the v10 branch with my original configuration file (from the june release)

[ 43.742612] No dialect specified on mount. Default has changed to a more secure dialect, SMB2.1 or later (e.g. SMB3), from CIFS (SMB1). To use the less secure SMB1 dialect to access old servers which do not support SMB3 (or SMB2.1) specify vers=1.0 on mount. [ 43.957918] CIFS VFS: Error connecting to socket. Aborting operation. [ 43.957951] CIFS VFS: cifs_mount failed w/return code = -101 [ 46.832409] loop0: p1 [ 97.414115] No dialect specified on mount. Default has changed to a more secure dialect, SMB2.1 or later (e.g. SMB3), from CIFS (SMB1). To use the less secure SMB1 dialect to access old servers which do not support SMB3 (or SMB2.1) specify vers=1.0 on mount.

FWIW, headless setup log said the archive was reachable....

[marcone]

The "No dialect specified on mount" message doesn't matter I think (I see it too, and it doesn't prevent me from mounting the archive). Maybe sudo mount /mnt/archive gives a more helpful error message.

[acraigl]

The "No dialect specified on mount" message doesn't matter I think (I see it too, and it doesn't prevent me from mounting the archive). Maybe sudo mount /mnt/archive gives a more helpful error message.

It might but the bigger problem is I can't get the dashcam icon to come up anymore in the car. So although it appears to go through the archiveloop process, it doesn't have anything to copy anyway. I seem to have reduced/removed any dmesg errors by using the latest stretch image with the v10 archive and CIFS 3.0 setting... I just need to figure out why the damn thing isn't coming up in the car properly. :(

[acraigl]

@marcone ok, so after a lot of trial and error, I've found the reason that my icon wasn't appearing was because of a bad splitter. When I go direct it records no problem. Probably the act of getting v10 and moving stuff around jostled it just enough to stop working. Or something. Ugh.

Anyway, I'm still seeing the CIF error in dmesg, attached. And nothing is getting archived. Not sure what else to try at this point. Open to any suggestions. dmseg20190928.txt

[marcone]

diagnostics might show more: setup-teslausb diagnose

[acraigl]

output attached. I don't see anything out of the ordinary? diagnose.txt

[marcone]

Those diagnostics are truncated (by a lot). Can you run setup-teslausb selfupdate and then setup-teslausb diagnose again?

[gacevedo]

Does the software update automatically every time the pi boots up, or do I need to SSH into it and run an update command of sorts, or do I need to go through the whole setup process again? I got v10 yesterday, and I'd like to test the changes. Thank you.

[normalfaults]

update process is here: https://github.com/marcone/teslausb/wiki

[acraigl]

Those diagnostics are truncated (by a lot). Can you run setup-teslausb selfupdate and then setup-teslausb diagnose again?

Looks like everything was in a read-only mode for some reason. I did a mount -o remount, rw / and just ran setup-teslausb. That got everything cooking. Unfortunately the diagnose output looks exactly the same. 😢

Update: Was able to run the remountfs_rw script as root (as described in the troubleshooting doc) and reran. Updated diagnose output attached. diagnose2.txt

[marcone]

You probably need to set the branch specified in /root/teslausb_setup_variables.conf back to main-dev, because it looks like you're on another, older branch.

[acraigl]

You probably need to set the branch specified in /root/teslausb_setup_variables.conf back to main-dev, because it looks like you're on another, older branch.

OK, will update/rerun and let you know. Will main allow for the v10 video files?

[gacevedo]

So, got home after my first ride using v10, and after updating the Pi with instructions provided on here: https://github.com/marcone/teslausb/wiki. Videos are not making it into my server, so I SSH'ed into the Pi and the logs stopped on this line:

Sun 29 Sep 10:12:51 PDT 2019: linking /backingfiles/snapshots/newsnap/mnt/TeslaCam/SentryClips/2019-09-29_09-31-36/2019-09-29_09-21-31-back.mp4

Nothing else after that, for the past 21 minutes. Anything else I can do to debug this issue?

Note: before v10, everything was working just fine.

Thank you!

[gacevedo]

If I run /etc/rc.local, I get the following output (pasting just the last few lines):

_rm: cannot remove '/backingfiles/snapshots/newsnap/mnt/.Spotlight-V100/Store-V1/VolumeConfig.plist': Read-only file system rm: cannot remove '/backingfiles/snapshots/newsnap/mnt/.Spotlight-V100/VolumeConfiguration.plist': Read-only file system rm: cannot remove '/backingfiles/snapshots/newsnap/mnt/.fseventsd/fseventsd-uuid': Read-only file system /dev/loop0p1 on /backingfiles/snapshots/newsnap/mnt type vfat (ro,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,errors=remount-ro) /dev/loop1p1 on /backingfiles/snapshots/newsnap/mnt type vfat (ro,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,errors=remount-ro) /dev/loop2p1 on /backingfiles/snapshots/newsnap/mnt type vfat (ro,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,errors=remount-ro) /dev/loop3p1 on /backingfiles/snapshots/newsnap/mnt type vfat (ro,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,errors=remount-ro) snapshot already mounted fsck from util-linux 2.29.2 fsck.fat 4.1 (2017-01-24) 0x41: Dirty bit is set. Fs was not properly unmounted and some data may be corrupt. Automatically removing dirty bit. Performing changes. /dev/loop4p1: 493 files, 646970/1420449 clusters stat: cannot stat '/backingfiles/snapshots/newsnap/mnt/TeslaCam/SavedClips//': No such file or directory /root/bin/makesnapshot.sh: line 60: collection: unbound variable

[gacevedo]

I ran...

_sudo -i /root/bin/remountfsrw /root/bin/setup-teslausb selfupdate /root/bin/setup-teslausb reboot

And it seems to be working again. No idea what the issue was. Hopefully this was a permanent fix. Will find out next time I take the car out.

[miles267]

@Gacevedo - so you have teslausb working successfully with v10? Haven’t seen anyone confirm that here yet.

[mcowger]

Its working correctly here (updated teslausb per @gacevedo's comment, then left, had a sentry event, came back) and have all the proper files (including rear camera) in my CIFS server.

[gacevedo]

@miles267 yessir. Back repeater videos and everything. Not sure why I had to run the Teslausb update twice, since the first time it didn't show any errors. But, that didn't impact the recording, only the copying/moving off of the videos. But after running the update again and rebooting, videos were transferred onto my file server without any issues.

[acraigl]

I'm not faring as well as some of the others. Recordings are happening fine, but still have the CIF errors when I run dmesg. Nothing copying over. I'll continue to play with it and see if I can tweak anything to get it moving.

[lightdsn]

I'm trying to ssh into my pi and I've forgotten the password, can anyone let me know what the default one was set too?

[bladec59]

raspberry

[lightdsn]

Thank you! Did all this and everything is working great on V10, thanks to everyone for the help and for keeping this up to date!

[carleeno]

I wanted to confirm that it is working for rclone as well, thanks everybody! I do want to ask however, I'm considering submitting a PR so that it will backup SavedClips and SentryClips to separate folders on the server, so it's easier to tell what was what, but I'm not sure what people would prefer. Any suggestions? Should both be backed up to the same folder, or kept separated?

[acraigl]

@marcone I have no idea what changed, but I can also confirm it's working now. My last good config has me using CIFS 3.0 and the main-dev branch. I will say that I also got another software update this morning, currently running 2019.32.11 bac8c51. Whatever the reason, VERY pleased this is working once more. Thanks (as always) for helping me through this.

EDIT: No rear camera files are showing up -- just the front/left/right like before. EDIT EDIT: Now I'm seeing the rear camera. Maybe it didn't finish archiving last time? Anyway, looks like I'm good. Whew! :)

[acraigl]

I wanted to confirm that it is working for rclone as well, thanks everybody! I do want to ask however, I'm considering submitting a PR so that it will backup SavedClips and SentryClips to separate folders on the server, so it's easier to tell what was what, but I'm not sure what people would prefer. Any suggestions? Should both be backed up to the same folder, or kept separated?

I like the idea of separated, personally.

[carleeno]

I like the idea of separated, personally.

Looks like someone has beat me to it, PR already submitted for CIFS, and my PR for rclone was already merged :) So keep an eye out for PR 284 to get merged, then you can update and run setup again to get archiving to separate folders.

[gacevedo]

So... I'm now --randomly- getting the "USB drive is too slow" message from the car, and recordings get disabled (both Dashcam and Sentry). Unplugging the Pi Zero W and plugging back in "fixes" the issue, but it comes back again next day or simply at random times. I'm using a SanDisk Extreme microSDXC UHS-I memory card. Anyone else experiencing this issue?

[mcowger]

I am also getting that identical behavior

On Sep 30, 2019, at 1:37 PM, Gabriel Acevedo notifications@github.com wrote:

 So... I'm now --randomly- getting the "USB drive is too slow" message from the car, and recordings get disabled (both Dashcam and Sentry). Unplugging the Pi Zero W and plugging back in "fixes" the issue, but it comes back again next day or simply at random times. I'm using a SanDisk Extreme microSDXC UHS-I memory card. Anyone else experiencing this issue?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

[gacevedo]

Potentially related to https://github.com/marcone/teslausb/issues/286? I haven't had a chance to SSH into the Pi and check logs, etc. I'll try to do that tonight.

[carleeno]

@gacevedo @mcowger I've not had that happen yet, after a few days of usage, I'm using a SanDisk 128GB High Endurance Video microSDXC, U3. What is your cam disk size you selected when running setup? Exactly which card do you have? U1 or U3? Considering there is now an additional camera being recorded, some slower cards might not have enough speed for v10 edit, more info: I'm running a manual install version of teslausb, not the prebuilt image. And my cam size is 16gb, music 16gb, the rest for snapshots.

[gacevedo]

It's supposed to be UHS Speed Class 3 (U3) and Video Speed Class 30 (V30). I didn't allocate space for music, so I think the default is 90%? I didn't re-install teslausb (originally installed using the pre-built image). Rather, I followed the General Tips for selfupdate. Assuming the speed of my card is enough, maybe I need to rebuild things from scratch.

@gacevedo @mcowger I've not had that happen yet, after a few days of usage, I'm using a SanDisk 128GB High Endurance Video microSDXC, U3. What is your cam disk size you selected when running setup? Exactly which card do you have? U1 or U3? Considering there is now an additional camera being recorded, some slower cards might not have enough speed for v10 edit, more info: I'm running a manual install version of teslausb, not the prebuilt image. And my cam size is 16gb, music 16gb, the rest for snapshots.

[carleeno]

@gacevedo I just found this as well #239 so it seems that we're talking about speeds far below the advertised ratings of the cards. Might have something to do with the version of raspian being used or something else outside of the teslausb code.

[fatfurrycat]

Updated my TeslaUSB configuration earlier today in preparation for V10 (which car has notified me about, but I've yet to install).

Following the update, I went out for a drive and ensured that there was some footage to transfer. When I returned home, I can see a connection to my NAS, but not footage is transferred.

The appropriate timeslot in the diagnose log shows the following messages: Mon 30 Sep 20:26:50 BST 2019: Archiving... Mon 30 Sep 20:26:50 BST 2019: Disconnecting usb from host... Mon 30 Sep 20:26:50 BST 2019: Disconnected usb from host. Mon 30 Sep 20:26:50 BST 2019: Ensuring cam archive is mounted... Mon 30 Sep 20:26:50 BST 2019: Mounting /mnt/archive... Mon 30 Sep 20:26:50 BST 2019: Mounted /mnt/archive. Mon 30 Sep 20:26:50 BST 2019: Ensured cam archive is mounted. Mon 30 Sep 20:26:50 BST 2019: Checking saved folder count... Mon 30 Sep 20:26:50 BST 2019: Ensuring cam file is mounted... Mon 30 Sep 20:26:50 BST 2019: Mounting /mnt/cam... Mon 30 Sep 20:26:50 BST 2019: Mounted /mnt/cam. Mon 30 Sep 20:26:51 BST 2019: Ensured cam file is mounted. Mon 30 Sep 20:26:51 BST 2019: Running fsck on /mnt/cam... Mon 30 Sep 20:26:51 BST 2019: | fsck from util-linux 2.29.2 Mon 30 Sep 20:26:53 BST 2019: | fsck.fat 4.1 (2017-01-24) Mon 30 Sep 20:26:53 BST 2019: | 0x41: Dirty bit is set. Fs was not properly unmounted and some data may be corrupt. Mon 30 Sep 20:26:53 BST 2019: | Automatically removing dirty bit. Mon 30 Sep 20:26:53 BST 2019: | Free cluster summary wrong (1718284 vs. really 1718287) Mon 30 Sep 20:26:53 BST 2019: | Auto-correcting. Mon 30 Sep 20:26:53 BST 2019: | Performing changes. Mon 30 Sep 20:26:53 BST 2019: | /dev/loop19: 193 files, 353597/2071884 clusters Mon 30 Sep 20:26:53 BST 2019: Finished fsck on /mnt/cam. Mon 30 Sep 20:26:53 BST 2019: There are 0 event folder(s) with 0 file(s) to move. Mon 30 Sep 20:26:53 BST 2019: Unmounting /mnt/cam... Mon 30 Sep 20:26:54 BST 2019: Unmounted /mnt/cam. Mon 30 Sep 20:26:54 BST 2019: Finished archiving.

I've attached the diagnose log here. Would appreciate someone taking a look at the logs, and letting me know if there's anything obvious wrong. I can't see it for trying. I've manually managed to mount the archive location with no errors, so it's not that.

The last successful archive folder was 2019-09-29_19-04-11

I'm assuming that the code still functions correctly with v9 software? Any help would be much appreciated. diagnose.txt

[carleeno]

@fatfurrycat just to confirm, if you plug the pi into a computer and view the TeslaCam drive, do you have any files in the SavedClips or SentryClips folder? (Keep in mind it doesn't copy RecentClips). edit, and yes it should still work with v9 (SavedClips folder name is the same)

[marcone]

Mon 30 Sep 20:26:53 BST 2019: There are 0 event folder(s) with 0 file(s) to move.

would seem to indicate there's nothing to archive. As noted above, RecentClips aren't archived (yet)

[vita10gy]

I'm also having the issue as described by others.

Unplugging and replugging sees it work for a while, confirmed by there being files in recent, but eventually the car decides it's not writing fast enough and stops working while driving, or recording during sentry mode.