marcone / teslausb Goto Github PK

Good morning -

I've found a couple closed issues with this problem, but the ones I saw all 'magically' fixed themselves.

In short, after burning the image to my SD, I boot the Pi0W and wait. it does some activity for about 4 minutes, and then stops. I'm able to SSH to the Pi (which tells me the network parameters are fine).

On the Pi, I see in /boot the WIFI_ENABLED and TESLAUSB_SETUP_STARTED files, but it never finishes setup.

The setup log never progresses past this stage:

Mon  6 May 01:08:52 BST 2019 : Detecting whether to update wpa_supplicant.conf
Mon  6 May 01:08:52 BST 2019 : Wifi variables specified, and no /boot/WIFI_ENABLED. Building wpa_supplicant.conf.
Mon  6 May 01:08:52 BST 2019 : Rebooting...
Mon  6 May 01:09:18 BST 2019 : Detecting whether to update wpa_supplicant.conf
Mon  6 May 01:09:18 BST 2019 : Grabbing main setup file.

Thoughts?

The USB works great at the beginning transferring files, doing the initial music sync. However, after a long time, say overnight, the dashcam drive does not show up. I have to restart the pi for it to show backup. DAE have this problem?

It looks like this might be caused by frequent connect/disconnects. Is there a way we can sync only once and not sync again till the wifi is disconnected ?

And/or unmount and remount once car transitions from asleep to online ?

I have no idea if there's any realistic way to fix this, but I've found that /mutable/archiveloop.log has completely wrong timestamps when the Pi first boots up. The system thinks it's November 2016 for some reason.

These timestamps fix themselves eventually during the archiving process (ntp finally runs, I guess?), but I often find myself SSHing into my pi when I get home to confirm that it's working, and the timestamps being totally wrong make it impossible to tell if the log lines are new or old.

Hello,
I have set up the teslausb_setup_variables.conf file and booted the Pi, was able to ssh into it and connect. I see the "WIFI_ENABLED" file and "TESLAUSB_SETUP_STARTED" file in /boot, but when I look at the teslausb-headless-setup.log file, it looks like it gets stuck at the "Grabbing main setup file." step. I started over and changed the BRANCH (not repository) to diagnostics, but it does not show any additional information.

Any ideas?

I've configured rclone to use Google Drive. However, I've noticed every uploaded file is corrupted (file size is 500kb each).

Changing the archive-clips.sh file to use the copy command instead seems to fix this issue.

rclone --config /root/.config/rclone/rclone.conf copy "$file_name" "$drive:$path" >> "$LOG_FILE" 2>&1 || echo ""

However, this does not clean up the files from the saved clips location.

For now, I've added after the rclone. This can be dangerous though... If the rclone command is not successful, you may end up deleting without uploading.

  rm "$file_name"

I will work on a PR to potentially validate the upload prior to removing the local copy.

Sun 26 May 18:16:38 BST 2019: Mounting /mnt/archive...
mount error(22): Invalid argument
Refer to the mount.cifs(8) manual page (e.g. man mount.cifs)
Sun 26 May 18:16:38 BST 2019: Failed to mount /mnt/archive.
Sun 26 May 18:16:38 BST 2019: Sleeping before retry...

How would I find the invalid argument? Only thing I've been able to find online is the CIFS version may need to be changed to something like 2.1. How would I be able to try that.

Marcone,

I have been looking through the closed issue threads and saw that you put some code into the one-step install to check for previous partitions. I am trying to install manually (trying to use gdrive), but am installing for the second time. Therefore when I try to run:

wget https://raw.githubusercontent.com/marcone/teslausb/main-dev/setup/pi/setup-teslausb
chmod +x setup-teslausb
./setup-teslausb

I get:

Verifying that there is sufficient space available on the MicroSD card...
STOP: The MicroSD card is too small: 524288 bytes available.
BYT; /dev/mmcblk0:31.9GB:sd/mmc:512:512:msdos:SD SU32G:; 1:4194kB:49.2MB:45.0MB:fat32::lba; 2:50.3MB:1804MB:1753MB:ext4::; 3:1804MB:31.8GB:30.0GB:ext4::; 4:31.8GB:31.9GB:105MB:ext4::;

Is there anyway to fix this for the manual folks like you did for the one-step installs? Is there any workaround for this?

Finally, can I throw you a donation for answering my questions the last two days?

after running the setup script the final error is posted
`/dev/mmcblk0p4 contains a ext4 file system labelled 'mutable'
created on Sun May 5 08:13:49 2019
Proceed anyway? (y,N) y
Discarding device blocks: done
Creating filesystem with 103424 1k blocks and 25896 inodes
Filesystem UUID: a6b29797-65c4-4782-a3c1-403b7d0f48e2
Superblock backups stored on blocks:
8193, 24577, 40961, 57345, 73729

Allocating group tables: done
Writing inode tables: done
Creating journal (4096 blocks): done
Writing superblocks and filesystem accounting information: done

Mounting the partition for the backing files...
Mounted the partition for the backing files.
Creating backing disk files.
create-backingfiles: starting
create-backingfiles: starting
create-backingfiles: Allocating 0K for /backingfiles/cam_disk.bin...
create-backingfiles: Allocating 0K for /backingfiles/cam_disk.bin...
fallocate: invalid length value specified`

I just tried using the manual install to setup an rclone to dropbox teslausb. However no writes to the provided FAT mounts are persisted. In fact, mac os complains that it cannot repair either CAM or MUSIC and that they are read only. I see similar behavior when I mount the backingfiles in raspbian as well.

I found these errors in the dmesg:

[ 1392.998578] print_req_error: I/O error, dev loop0, sector 1
[ 1392.998598] Buffer I/O error on dev loop0, logical block 1, lost async page write
[ 1393.009947] loop: Write error at byte offset 14516224, length 512.
[ 1393.009977] print_req_error: I/O error, dev loop0, sector 26304
[ 1393.009998] Buffer I/O error on dev loop0, logical block 26304, lost async page write
[ 1403.078890] loop: Write error at byte offset 1049088, length 512.
[ 1403.078912] print_req_error: I/O error, dev loop0, sector 1
[ 1403.078926] Buffer I/O error on dev loop0, logical block 1, lost async page write
[ 1448.517260] loop: Write error at byte offset 14516224, length 512.
[ 1448.517291] print_req_error: I/O error, dev loop0, sector 26304
[ 1448.517312] Buffer I/O error on dev loop0, logical block 26304, lost async page write

I also tried running rpi-update. This happens on both the 4.14 and 4.19 kernels.

Is it possible to setup multiple SSIDs to look for/connect to (ie, home wifi, and phone hotspot for on-demand syncing?)

I made a brief stop at home today then left again a few minutes later. While I was home the Pi started moving the files to the network share. I drove away before it was complete and the Pi did not recover. 15 minutes into the drive the dashcam icon still hadn't returned. Restarting the Pi by unplugging it and plugging it back in fixed it, but can we make is so that the script notices the share is no longer working when trying to move files.

Can't seem to get it going through. Wifi is configured correctly and I am able to SSH in but checking the teslausb-headless-setup.log its stuck at Grabbing main setup file.

/boot/TESLAUSB_SETUP_STARTED is there but not TESLAUSB_SETUP_FINISHED

Thanks for all these fixes, I've been using your branch for 2 weeks and it's been working great.

I did have one issue, the first time I arrived home the FAT partition was too corrupted to fix, it couldn't be mounted and the images couldn't be transferred. I think the problem was the device connected to my WiFi and detected my archive while I was still pulling into the drive and unmounted the USB drive while the car was still writing a video file.

I added a small delay after the archive is detected to give me time to park and the car time to write the last recording.

I thought it might be useful to support an optional delay.

Title says it all.
It is known that the car will overwrite after 59-60 minutes. Is it possible to code where this current files are moved to ‘Saved’ folder every 59-60 minutes to have a continuous recording.
I understand that this will require larger SD cards.
Thank you

Please disregard, it appears this only fails until there are actually 10 minutes of footage to archive.

I wanted to create a separate issue on the off chance there's something we can do on the RasPi side to get a single usb cable to work again.

I used my USB power meter to see what happens when the RasPi reboots, and based on what the meter is showing, the power to the port itself is actually going away - no apparent overload that would seem to trigger it - max current is maybe 230mA - well below even very basic USB power limits.

I thought maybe Tesla added some logic to actively reject "usb attacks" given the visibility on the hacking stuff recently, so I copied the USB device ID, etc from a working USB thumb drive and it didn't seem to have any effect. (I plugged it into the g_mass_storage.conf file)

Video of what I observed: http://imgur.com/gallery/qecn7Ke

All cables were plugged in the whole time - the power meter just saw a complete loss of power (or low enough to reboot).

Anybody else tried things to get a single cable to work again? I finally got two cables working again so I'm at least back to "working". Just hoping to improve further.

After changing my sharename in /boot/teslausb_setup_variables.conf and re-running /etc/rc.local, I noticed that it was failing to mount the archive. Thanks to #42 and #27, I checked /etc/fstab and noticed that it was still pointing to the old sharename I had specified. I reran the whole setup process but it still didn't change. For now I've manually updated /etc/fstab. Ideally this file should get updated/recreated when the setup process happens again but I haven't delved into the details yet. Hope this helps for anyone who's running into the same issue.

Can you update with a new one? Thanks

For the past couple days, since upgrading my Tesla to 2019.16.2 and auto-enabling Sentry Mode my Tesla alarm has gone off at 7:00 AM with no external disturbances.

I strongly suspect TeslaUSB is unmounting the USB drive from the Tesla at this time, perhaps a daily restart or some other cron-driven maintenance. The car is seeing the USB unmount and triggering the alarm with horn blaring and music blasting.

If I run 'date' when sshed to TeslaUSB it returns a time 8 hours ahead of me with a timezone of BST, but the created/modified time of files saved to my server are seven hours behind, so the alarm is going off right when the timestamp on the files would be midnight.

If there's no way to avoid the unmounting, perhaps TeslaUSB could be updated to use the Tesla API to turn off Sentry Mode before the restart and reenable it after the restart.

I followed the one page setup, and also did a manual setup just to see if there were any differences, but essentially, the TeslaCam recordings work well, but I am not syncing any videos to my archive folder.

The logs don't have much information, but i am seeing the following in the logs:

Thu 16 May 21:07:07 BST 2019: Failed to mount /mnt/archive.
Thu 16 May 21:07:07 BST 2019: Attempts exhausted.
Thu 16 May 21:07:07 BST 2019: cam archive not mounted

Does this indicate that it cannot connect to my shared network folder? Or what exactly is /mnt/archive and how can I further debug this?

Right now, my device is properly storing RecentClips and SavedClips, and disconnects when i get within wifi range, as expected, but nothing is syncing over to my network share.

Incase it helps, the archive folder is on a Mac. I am able to see /mnt/archive when ssh'd in, there are no failes in it or /mnt/cam, but i do see the directories.

_Be sure that your WiFi password is enclosed in single quotes, and that if it contains one or more single quote characters you replace each single quote character with a backslash followed by a single quote character.

For example, if your password werea'b
you would have
export sharepassword='a'b'_

Should this be:
export WIFIPASS='a'b'
?

I'm attempting a manual install with GDrive and Pushover. I keep running into the same error on the last step when I try to run the TeslaUSB setup. Specifically, I get:

grep: /root/bin/setup-teslausb: No such file or directory
setup-teslausb is outdated, attempting update
STOP: failed to update setup-teslausb

I have looked over the closed and open issues and don't see anyone who is having a similar issue. I was wondering if you could tell me where I'm going wrong. Here is the log from my setup:

PS C:\Users\chads> ssh pi@raspberrypi
The authenticity of host 'raspberrypi (fe80::57c4:d551:6557:a7a8%20)' can't be established.
ECDSA key fingerprint is SHA256:S5vf5pIwnKt+NY5HxbNRBDkNcM8xCTNNdIB54meku+4.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'raspberrypi,fe80::57c4:d551:6557:a7a8%20' (ECDSA) to the list of known hosts.
pi@raspberrypi's password:
Linux raspberrypi 4.14.98+ #1200 Tue Feb 12 20:11:02 GMT 2019 armv6l

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.

SSH is enabled and the default password for the 'pi' user has not been changed.
This is a security risk - please login as the 'pi' user and type 'passwd' to set a new password.

pi@raspberrypi:~ $ passwd
Changing password for pi.
(current) UNIX password:
Enter new UNIX password:
Retype new UNIX password:
passwd: password updated successfully
pi@raspberrypi:~ $ sudo -i

SSH is enabled and the default password for the 'pi' user has not been changed.
This is a security risk - please login as the 'pi' user and type 'passwd' to set a new password.

root@raspberrypi:~# curl -L https://raw.github.com/pageauc/rclone4pi/master/rclone-install.sh | bash
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0
100 2508 100 2508 0 0 3451 0 --:--:-- --:--:-- --:--:-- 3451
bash ver 1.6 written by Claude Pageau

--2019-05-29 05:01:27-- https://downloads.rclone.org/rclone-current-linux-arm.zip
Resolving downloads.rclone.org (downloads.rclone.org)... 2a02:24e0:8:61f9::1, 5.153.250.7
Connecting to downloads.rclone.org (downloads.rclone.org)|2a02:24e0:8:61f9::1|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 9447065 (9.0M) [application/zip]
Saving to: ‘rclone.zip’

rclone.zip 100%[==================================================================================================================>] 9.01M 2.00MB/s in 5.2s

2019-05-29 05:01:33 (1.74 MB/s) - ‘rclone.zip’ saved [9447065/9447065]

unzip rclone.zip to folder rclone-tmp
Archive: rclone.zip
inflating: rclone-tmp/rclone.1
inflating: rclone-tmp/README.txt
extracting: rclone-tmp/git-log.txt
inflating: rclone-tmp/README.html
inflating: rclone-tmp/rclone
Install files and man pages
Purging old database entries in /usr/share/man...
Processing manual pages under /usr/share/man...
Purging old database entries in /usr/share/man/fr.UTF-8...
Processing manual pages under /usr/share/man/fr.UTF-8...
Purging old database entries in /usr/share/man/sl...
Processing manual pages under /usr/share/man/sl...
Purging old database entries in /usr/share/man/sv...
Processing manual pages under /usr/share/man/sv...
Purging old database entries in /usr/share/man/ko...
Processing manual pages under /usr/share/man/ko...
Purging old database entries in /usr/share/man/ja...
Processing manual pages under /usr/share/man/ja...
Purging old database entries in /usr/share/man/da...
Processing manual pages under /usr/share/man/da...
Purging old database entries in /usr/share/man/de...
Processing manual pages under /usr/share/man/de...
Purging old database entries in /usr/share/man/ru...
Processing manual pages under /usr/share/man/ru...
Purging old database entries in /usr/share/man/pl...
Processing manual pages under /usr/share/man/pl...
Purging old database entries in /usr/share/man/hu...
Processing manual pages under /usr/share/man/hu...
Purging old database entries in /usr/share/man/nl...
Processing manual pages under /usr/share/man/nl...
Purging old database entries in /usr/share/man/es...
Processing manual pages under /usr/share/man/es...
Purging old database entries in /usr/share/man/pt_BR...
Processing manual pages under /usr/share/man/pt_BR...
Purging old database entries in /usr/share/man/tr...
Processing manual pages under /usr/share/man/tr...
Purging old database entries in /usr/share/man/fr...
Processing manual pages under /usr/share/man/fr...
Purging old database entries in /usr/share/man/it...
Processing manual pages under /usr/share/man/it...
Purging old database entries in /usr/share/man/fi...
Processing manual pages under /usr/share/man/fi...
Purging old database entries in /usr/share/man/fr.ISO8859-1...
Processing manual pages under /usr/share/man/fr.ISO8859-1...
Purging old database entries in /usr/share/man/id...
Processing manual pages under /usr/share/man/id...
Purging old database entries in /usr/share/man/pt...
Processing manual pages under /usr/share/man/pt...
Purging old database entries in /usr/share/man/zh_CN...
Processing manual pages under /usr/share/man/zh_CN...
Purging old database entries in /usr/share/man/zh_TW...
Processing manual pages under /usr/share/man/zh_TW...
Purging old database entries in /usr/share/man/gl...
Processing manual pages under /usr/share/man/gl...
Purging old database entries in /usr/share/man/cs...
Processing manual pages under /usr/share/man/cs...
Processing manual pages under /usr/local/man...
Updating index cache for path `/usr/local/man/man1'. Wait...done.
Checking for stray cats under /usr/local/man...
Checking for stray cats under /var/cache/man/oldlocal...
1 man subdirectory contained newer manual pages.
1 manual page was added.
0 stray cats were added.
15 old database entries were purged.
Deleting rclone.zip and Folder rclone-tmp
rclone is installed at /usr/bin/rclone
rclone v1.47.0

• os/arch: linux/arm
• go version: go1.12.4
  --2019-05-29 05:01:46-- https://raw.github.com/pageauc/rclone4pi/master/rclone-sync.sh
  Resolving raw.github.com (raw.github.com)... 151.101.204.133
  Connecting to raw.github.com (raw.github.com)|151.101.204.133|:443... connected.
  HTTP request sent, awaiting response... 301 Moved Permanently
  Location: https://raw.githubusercontent.com/pageauc/rclone4pi/master/rclone-sync.sh [following]
  --2019-05-29 05:01:46-- https://raw.githubusercontent.com/pageauc/rclone4pi/master/rclone-sync.sh
  Resolving raw.githubusercontent.com (raw.githubusercontent.com)... 199.232.32.133
  Connecting to raw.githubusercontent.com (raw.githubusercontent.com)|199.232.32.133|:443... connected.
  HTTP request sent, awaiting response... 200 OK
  Length: 4337 (4.2K) [text/plain]
  Saving to: ‘rclone-sync.sh’

rclone-sync.sh 100%[==================================================================================================================>] 4.24K --.-KB/s in 0.001s

2019-05-29 05:01:46 (4.51 MB/s) - ‘rclone-sync.sh’ saved [4337/4337]

--2019-05-29 05:01:46-- https://raw.github.com/pageauc/rclone4pi/master/Readme.md
Resolving raw.github.com (raw.github.com)... 199.232.32.133
Connecting to raw.github.com (raw.github.com)|199.232.32.133|:443... connected.
HTTP request sent, awaiting response... 301 Moved Permanently
Location: https://raw.githubusercontent.com/pageauc/rclone4pi/master/Readme.md [following]
--2019-05-29 05:01:47-- https://raw.githubusercontent.com/pageauc/rclone4pi/master/Readme.md
Resolving raw.githubusercontent.com (raw.githubusercontent.com)... 151.101.204.133
Connecting to raw.githubusercontent.com (raw.githubusercontent.com)|151.101.204.133|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 1739 (1.7K) [text/plain]
Saving to: ‘Readme.md’

Readme.md 100%[==================================================================================================================>] 1.70K --.-KB/s in 0.002s

2019-05-29 05:01:47 (900 KB/s) - ‘Readme.md’ saved [1739/1739]

--2019-05-29 05:01:47-- https://raw.github.com/pageauc/rclone4pi/master/rclone-install.sh
Resolving raw.github.com (raw.github.com)... 151.101.204.133
Connecting to raw.github.com (raw.github.com)|151.101.204.133|:443... connected.
HTTP request sent, awaiting response... 301 Moved Permanently
Location: https://raw.githubusercontent.com/pageauc/rclone4pi/master/rclone-install.sh [following]
--2019-05-29 05:01:48-- https://raw.githubusercontent.com/pageauc/rclone4pi/master/rclone-install.sh
Resolving raw.githubusercontent.com (raw.githubusercontent.com)... 151.101.204.133
Connecting to raw.githubusercontent.com (raw.githubusercontent.com)|151.101.204.133|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 2508 (2.4K) [text/plain]
Saving to: ‘rclone-install.sh’

rclone-install.sh 100%[==================================================================================================================>] 2.45K --.-KB/s in 0.001s

2019-05-29 05:01:48 (2.68 MB/s) - ‘rclone-install.sh’ saved [2508/2508]

rclone installed at /usr/bin/rclone

             INSTRUCTIONS Google Drive Example

1 You will be required to have a login account on the remote storage service
Open putty SSH login session to RPI and execute command below

rclone config

Follow rclone prompts. For more Details See
https://github.com/pageauc/rclone4pi/wiki/Home
2 At name> prompt specify a reference name eg gdmedia
3 At storage> prompt Enter a remote storage number from List
4 Select Auto Config, At Link: prompt, left click
and highlight rclone url link (do not hit enter)
5 on computer web browser url bar right click paste and go.
6 On computer web browser security page, Confirm access.
7 Copy web browser access security token and paste
into RPI SSH session rclone prompt. Enter to accept
8 To test remote service access. Execute the following where
gdmedia is the name you gave your remote service

rclone ls gdmedia:/

Example sync command make source identical to destination

rclone sync -v /home/pi/rpi-sync gdmedia:/rpi-sync

To upgrade

cd rpi-sync
./rclone-install.sh upgrade

For more Details See https://github.com/pageauc/rclone4pi/wiki/Home
Bye

root@raspberrypi:~# rclone config
2019/05/29 05:01:58 NOTICE: Config file "/root/.config/rclone/rclone.conf" not found - using defaults
No remotes found - make a new one
n) New remote
s) Set configuration password
q) Quit config
n/s/q> n
name> gdrive
Type of storage to configure.
Enter a string value. Press Enter for the default ("").
Choose a number from below, or type in your own value
1 / A stackable unification remote, which can appear to merge the contents of several remotes
\ "union"
2 / Alias for a existing remote
\ "alias"
3 / Amazon Drive
\ "amazon cloud drive"
4 / Amazon S3 Compliant Storage Provider (AWS, Alibaba, Ceph, Digital Ocean, Dreamhost, IBM COS, Minio, etc)
\ "s3"
5 / Backblaze B2
\ "b2"
6 / Box
\ "box"
7 / Cache a remote
\ "cache"
8 / Dropbox
\ "dropbox"
9 / Encrypt/Decrypt a remote
\ "crypt"
10 / FTP Connection
\ "ftp"
11 / Google Cloud Storage (this is not Google Drive)
\ "google cloud storage"
12 / Google Drive
\ "drive"
13 / Hubic
\ "hubic"
14 / JottaCloud
\ "jottacloud"
15 / Koofr
\ "koofr"
16 / Local Disk
\ "local"
17 / Mega
\ "mega"
18 / Microsoft Azure Blob Storage
\ "azureblob"
19 / Microsoft OneDrive
\ "onedrive"
20 / OpenDrive
\ "opendrive"
21 / Openstack Swift (Rackspace Cloud Files, Memset Memstore, OVH)
\ "swift"
22 / Pcloud
\ "pcloud"
23 / QingCloud Object Storage
\ "qingstor"
24 / SSH/SFTP Connection
\ "sftp"
25 / Webdav
\ "webdav"
26 / Yandex Disk
\ "yandex"
27 / http Connection
\ "http"
Storage> 12
** See help for drive backend at: https://rclone.org/drive/ **

Google Application Client Id
Setting your own is recommended.
See https://rclone.org/drive/#making-your-own-client-id for how to create your own.
If you leave this blank, it will use an internal key which is low performance.
Enter a string value. Press Enter for the default ("").
client_id> [removed]
Google Application Client Secret
Setting your own is recommended.
Enter a string value. Press Enter for the default ("").
client_secret> [removed]
Scope that rclone should use when requesting access from drive.
Enter a string value. Press Enter for the default ("").
Choose a number from below, or type in your own value
1 / Full access all files, excluding Application Data Folder.
\ "drive"
2 / Read-only access to file metadata and file contents.
\ "drive.readonly"
/ Access to files created by rclone only.
3 | These are visible in the drive website.
| File authorization is revoked when the user deauthorizes the app.
\ "drive.file"
/ Allows read and write access to the Application Data folder.
4 | This is not visible in the drive website.
\ "drive.appfolder"
/ Allows read-only access to file metadata but
5 | does not allow any access to read or download file content.
\ "drive.metadata.readonly"
scope> 3
ID of the root folder
Leave blank normally.
Fill in to access "Computers" folders. (see docs).
Enter a string value. Press Enter for the default ("").
root_folder_id>
Service Account Credentials JSON file path
Leave blank normally.
Needed only if you want use SA instead of interactive login.
Enter a string value. Press Enter for the default ("").
service_account_file>
Edit advanced config? (y/n)
y) Yes
n) No
y/n> n
Remote config
Use auto config?

• Say Y if not sure
• Say N if you are working on a remote or headless machine
  y) Yes
  n) No
  y/n> n
  If your browser doesn't open automatically go to the following link: [removed]
  Log in and authorize rclone for access
  Enter verification code> [removed]
  Configure this as a team drive?
  y) Yes
  n) No
  y/n> n

[gdrive]
type = drive
client_id = [removed]
client_secret = [removed]
scope = drive.file
token = [removed]

y) Yes this is OK
e) Edit this remote
d) Delete this remote
y/e/d> y
Current remotes:

Name Type
==== ====
gdrive drive

e) Edit existing remote
n) New remote
d) Delete remote
r) Rename remote
c) Copy remote
s) Set configuration password
q) Quit config
e/n/d/r/c/s/q> q
root@raspberrypi:# export ARCHIVE_SYSTEM=rclone
root@raspberrypi:# export RCLONE_DRIVE=gdrive
root@raspberrypi:# export RCLONE_PATH=TeslaCam
root@raspberrypi:# rclone mkdir "$RCLONE_DRIVE:$RCLONE_PATH"
root@raspberrypi:# rclone lsd "$RCLONE_DRIVE":
-1 2019-05-29 02:08:48 -1 TeslaCam
root@raspberrypi:# export pushover_enabled=true
root@raspberrypi:# export pushover_user_key=[removed]
root@raspberrypi:# export pushover_app_key=[removed]
root@raspberrypi:~# wget https://raw.githubusercontent.com/marcone/teslausb/main-dev/setup/pi/setup-teslausb
--2019-05-29 05:06:32-- https://raw.githubusercontent.com/marcone/teslausb/main-dev/setup/pi/setup-teslausb
Resolving raw.githubusercontent.com (raw.githubusercontent.com)... 199.232.32.133
Connecting to raw.githubusercontent.com (raw.githubusercontent.com)|199.232.32.133|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 8192 (8.0K) [text/plain]
Saving to: ‘setup-teslausb’

setup-teslausb 100%[==================================================================================================================>] 8.00K --.-KB/s in 0.003s

2019-05-29 05:06:33 (2.39 MB/s) - ‘setup-teslausb’ saved [8192/8192]

root@raspberrypi:# chmod +x setup-teslausb
root@raspberrypi:# ./setup-teslausb
Updating package index files...
Get:1 http://archive.raspberrypi.org/debian stretch InRelease [25.4 kB]
Get:2 http://raspbian.raspberrypi.org/raspbian stretch InRelease [15.0 kB]
Get:3 http://raspbian.raspberrypi.org/raspbian stretch/main armhf Packages [11.7 MB]
Get:4 http://archive.raspberrypi.org/debian stretch/main armhf Packages [221 kB]
Get:5 http://archive.raspberrypi.org/debian stretch/ui armhf Packages [45.0 kB]
Get:6 http://raspbian.raspberrypi.org/raspbian stretch/non-free armhf Packages [95.5 kB]
Fetched 12.1 MB in 26s (464 kB/s)
Reading package lists... Done
Verifying that the requested configuration is valid...
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 1804 100 1804 0 0 4382 0 --:--:-- --:--:-- --:--:-- 4400
Downloaded /tmp/verify-configuration.sh ...
grep: /root/bin/setup-teslausb: No such file or directory
setup-teslausb is outdated, attempting update
STOP: failed to update setup-teslausb

I completed all steps and can connect via SSH as well as see the TeslaCam Google Drive folder created. However, I've triggered sentry mode to see if it's uploading the video to the Gdrive but still nothing and it's been a few hours? Any insight or information as to what's going on would be much appreciated.

You might consider using Apache MiNiFi on the Pi Zero. It has a very nice, durable way of transferring data.

I have a Pi Zero running MiNiFi, monitoring TeslaCam/SavedClips. When a new file is detected, it will read it, and then transfer it to a Raspberry Pi on my home network running a full NiFi instance. The full NiFi instance then uses a PutS3 processor to save my clips to AWS.

I'm a new teslausb user (thank you for all the work on this!), so take this suggestion with a grain of salt:

My typical use case (which I assume is typical for most) is that the teslausb will connect to my home network as I get home and park the car. The challenge is it seems like there is a good chance that the car could power down and go to sleep while teslausb is still syncing content, and I'd rather not mess with keeping Climate on, or Sentry mode while at home in the garage.

It seems like it would be interesting if teslausb was more aware of the state of the car, and could prevent it from going to sleep until the sync completes. Would integrating the Tesla car API (using something like this:https://www.teslaapi.io/) to understand the car state ("Am I parked?") and keep it awake while syncing (state poll, or maybe sending WakeUp command?). This could lead potentially to other interesting features like only syncing while charging, etc.

Anyway, perhaps this has been thought of / tried before, but seems like it would be a pretty cool addition to the project...

Thanks for considering!

Installing this today via your provided image & auto-config (marcone/main-dev), I wanted to change it to use SFTP afterwards but that required non-readonly filesystem. There was nothing at '/root/bin/remountfs_rw' however (and only two files in /root/bin).

Easy fix was to run the following instead, which I presume is all that 'remountfs_rw' helper is doing.
mount / -o remount,rw

Just wanted to let you know -- otherwise thank you for this, pretty cool & appreciate that you're maintaining it! :)

PS -- The only other change I wanted to make was to secure SSH on the Pi; for most users a password change would probably be fine (and I think that'd be worth at least suggesting, if not automating) though I personally wanted only key-based auth.

That might be equally easy option to automate (key-based) though, else end up with the password sitting in plaintext on the Pi; still probably better than leaving it default, though! :)

Just tried to get this going. My router can see the device as a wifi client but I can't see how to access it over wifi. I tried going to \teslausb and it's assigned IP address (10.0.0.12) but I can't
access it. The only config changes I made was adding my SSID and password.

I'm sure I'm doing something wrong, but I'm stuck?

I have installed TeslaUSB today and it works perfect on the Model S. I notice that for correct archiving additional power is need besides the USB. When in park the connection is lost on WiFi and therefor no archiving. After adding a powerbank everything runs smooth. I will no try to use the charger in de cigarette outlet, hopefully the power stays on.

Question: how can I change the location of the archive after installation. Is there a configuration file which can be edited?

Just built this from scratch and while the log says it's connected to USB host and dmesg shows that it is connected (at least electrically) the drive does not show up. The backing file is fine, can mount it and see directories. Any ideas?

Hi,

In the Readme it says it supports syncing music from CIFS share. But later in the readme the only way to sync the music that is discussed is unplugging the pi from the car and into the computer. Can you add a guide to setup syncing from a CIFS share?

Would be slick to include this project and clean up the folder structure before uploading files:

https://pypi.org/project/tesla-dashcam/

My thought is to pipe videos through this tool during the upload process and the result after the archive is a clean folder structure with one video per event.

Created the TeslaUSB with teslausb-20190505, which worked as it should. Can log into thru WiFi and if I connect the TeslaUSB to a computer I will see the folder.

When I connect the drive to the Tesla the icon on the MCU shows the normal red dot. When I press the icon, the icon changes to the download/save icon, but then there will popup the x icon. After a few seconds the red dot is present again. Nothing was saved on the TeslaUSB.

When I insert a normal USB stick everything works as it should. How can I troubleshoot this?
Can I post/check any logfiles?

While moving files and usb massivestorage are stopped, mount secondary massivestorage to able sentry mode to write new images. Until moving files are moved, swap massivestorage and perform again loop.

I got the error

STOP: The MicroSD card is too small.

error during the one-step setup for both teslausb-20190402 and teslausb-20190331. The one-step setup halts after 4th stage(by number of light flashes).
When I tried, to manually install using sudo -i and then run /etc/rc.local, it produced the following log:

pi@teslausb:~ $ sudo -i

SSH is enabled and the default password for the 'pi' user has not been changed.
This is a security risk - please login as the 'pi' user and type 'passwd' to set a new password.

root@teslausb:~# /etc/rc.local
My IP address is 192.168.92.178
dos2unix: converting file /root/teslausb_setup_variables.conf to Unix format...
Detecting whether to update wpa_supplicant.conf
dos2unix: converting file /root/teslausb_setup_variables.conf to Unix format...
Starting setup.
Updating package index files...
Hit:1 http://archive.raspberrypi.org/debian stretch InRelease
Hit:2 http://raspbian.raspberrypi.org/raspbian stretch InRelease
Reading package lists... Done
Verifying that the requested configuration is valid...
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 690 100 690 0 0 2463 0 --:--:-- --:--:-- --:--:-- 2473
Downloaded /tmp/verify-configuration.sh ...
Verifying that there is sufficient space available on the MicroSD card...
STOP: The MicroSD card is too small.

I have also attached my teslausb-healess-setup.log. It seems like its the same error. I used Etcher to flash the image, set to 65% camera percentage, and have a 64GB microSD card.
teslausb-headless-setup.log

Greatly appreciate your effort! Thanks!

My teslacam is finally running pretty smoothly. The only thing I have noticed is that it disconnects from the car when it connects to my wifi to sync. Is that expected behavior?

Would make it easier for others to help and debug also

from my archiveloop.log

Wed 29 May 06:02:45 BST 2019: Mounting /mnt/archive...
mount: can't find /mnt/archive in /etc/fstab
Wed 29 May 06:02:45 BST 2019: Failed to mount /mnt/archive.
Wed 29 May 06:02:45 BST 2019: Sleeping before retry...
Wed 29 May 06:02:46 BST 2019: Retrying...

this repeated dozens of times before it gives up
thoughts?

Doing a headless install pulling from the main-dev branch. Gets stuck at Creating backing disk files.

Here are the logs from teslausb-headless-setup.log for reference.

Tue Oct 30 18:41:06 GMT 2018 : Detecting whether to update wpa_supplicant.conf
Tue Oct 30 18:41:06 GMT 2018 : Wifi variables specified, and no /boot/WIFI_ENABLED. Building wpa_supplicant.conf.
Tue Oct 30 18:41:06 GMT 2018 : Rebooting...
Tue Oct 30 18:41:31 GMT 2018 : Detecting whether to update wpa_supplicant.conf
Tue Oct 30 18:41:31 GMT 2018 : Grabbing main setup file.
Tue Oct 30 18:41:32 GMT 2018 : Starting setup.
Tue Oct 30 18:41:32 GMT 2018 : Updating package index files...
Fri Mar 29 17:23:07 GMT 2019 : Verifying that the requested configuration is valid...
Fri Mar 29 17:23:08 GMT 2019 : Downloaded /tmp/verify-configuration.sh ...
Fri Mar 29 17:23:08 GMT 2019 : Verifying that there is sufficient space available on the MicroSD card...
Fri Mar 29 17:23:08 GMT 2019 : There is sufficient space available.
Fri Mar 29 17:23:18 GMT 2019 : Downloading additional setup scripts.
Fri Mar 29 17:23:19 GMT 2019 : Downloaded /tmp/create-backingfiles-partition.sh ...
Fri Mar 29 17:23:19 GMT 2019 : Downloaded /tmp/create-backingfiles.sh ...
Fri Mar 29 17:23:20 GMT 2019 : Downloaded /tmp/make-root-fs-readonly.sh ...
Fri Mar 29 17:23:20 GMT 2019 : Downloaded /root/configure.sh ...
Fri Mar 29 17:23:20 GMT 2019 : Fixing the modules-load parameter in /boot/cmdline.txt...
Fri Mar 29 17:23:20 GMT 2019 : Fixed cmdline.txt.
Fri Mar 29 17:23:29 GMT 2019 : Starting to create backing files partition...
Fri Mar 29 17:23:29 GMT 2019 : Checking existing partitions...
Fri Mar 29 17:23:30 GMT 2019 : Modifying partition table for backing files partition...
Fri Mar 29 17:23:30 GMT 2019 : Modifying partition table for mutable (writable) partition for script usage...
Fri Mar 29 17:23:30 GMT 2019 : Writing updated partitions to fstab and /boot/cmdline.txt
Fri Mar 29 17:23:31 GMT 2019 : Formatting new partitions...
Fri Mar 29 17:23:41 GMT 2019 : Mounting the partition for the backing files...
Fri Mar 29 17:23:41 GMT 2019 : Mounted the partition for the backing files.
Fri Mar 29 17:23:41 GMT 2019 : Creating backing disk files.

I don't have any good options to sync and archive the footage, but I would like the ability to just be able to connect over wifi and look through the files and delete them remotely.

Is this possible in the current setup?

Ran an older version for the past several months without issue until v9 (like most). Recently decided to update to see if it would now work with my X again so rebuilt my TeslaUSB using the latest one-step install (prebuilt teslausb-20190505). After running, I found that the CAM / MUSIC folders would no longer show up even on my Mac.

This morning I decided to do the manual install to see if that worked any better. I got to the step for running ./setup-teslausb and it ran for a short time before erroring with the following:

Downloaded /root/configure.sh ...
~ ~
Fixing the modules-load parameter in /boot/cmdline.txt...
Fixed cmdline.txt.
Starting to create backing files partition...
/tmp/create-backingfiles-partition.sh: line 21: hash: mkfs.btrfs: not found
Can't find btrfs tools. Please install manually or use the correct prebuilt

This appears to explain why the drives won't mount - it looks like it's unable to create the partitions.

BTW, I am using the latest "Raspbian Stretch Light" from https://www.raspberrypi.org/downloads/raspbian/

What is a good method to update the scripts as new commits are added? I don’t want to have to start over each time.
Thanks

Hi, I've been so freaking excited about this and it's absolutely amazing how easy this has been so far. I haven't really touched code in this way since middle school, but here I am relearning bash. I hope you can help me muddle through this, I'm obviously not the best with this stuff!

I've been using the latest prebuilt image 20190505 and the one step config file.
It works fine as far as the Tesla is concerned, and the Cam partition mounts (there is always a dirty eject error on my Mac when I plug it in there, but then it remounts fine)

It connects to wifi just fine as well, but when I check the archive loop, it always fails.
Checking fstab, there was no apparent entry for my server. This is what was in my one step config. I just hacked together the last line based on reading previous issues here. I read in a previous issue that removing the single quotes worked for someone, and I've tried it both ways, etching a new prebuilt image and using a new .conf.

One thing I've noticed is that in my case, the script always seems to hang at fetching main config file in archive loop, and I have to run rc scripts again to get it to finish setting up.

Back to fstab - I also have no .teslaCamArchiveCredentials either so I'm playing a guessing game as to how that should be formatted.

fstab, last line is hacked in - no idea how it should be

proc            /proc           proc    defaults          0       0
PARTUUID=b4293f65-01  /boot           vfat    defaults          0       2
PARTUUID=b4293f65-02  /               ext4    defaults,noatime  0       1
# a swapfile is not a swap partition, no line here
#   use  dphys-swapfile swap[on|off]  for that
LABEL=backingfiles /backingfiles ext4 auto,rw,noatime 0 2
LABEL=mutable /mutable ext4 auto,rw 0 2
/backingfiles/cam_disk.bin /mnt/cam vfat noauto,users,umask=000,offset=1048576 0 0
/homeserver.local/Storage /mnt/archive cifs vers=1.0,credentials=/root/.teslaCamArchiveCredentials,iocharset=utf8,file_mode=0777,dir_mode=0777 0

blank .teslaCamArchiveCredentials, I have no idea what should be in here

shareuser=pi
sharepassword=raspberry

contents of teslausb_setup_variables.conf

#####################################################################
# SAMPLE CONFIGURATION FILE FOR TESLAUSB Pi Setup
#
# Example config file for teslausb_setup. Lines with "#" are comments/ignored.
# Remove the "#" before "export" to activate a line. Be sure to rename this file
# to "teslausb_setup_variables.conf" and place it in the "boot" folder of your
# SD card. 
#
######################################################################

# Default variables for CIFS (Windows/Mac file sharing) setup
export ARCHIVE_SYSTEM=cifs
export archiveserver=homeserver.local
export sharename=Storage
export shareuser=pi
export sharepassword=raspberry
export camsize=100%
export timezone=America/Chicago

# if you set camsize to less than 100%, but don't want music to use
# all the remaining space, you can specify how much space you want
# music to use by setting this variable
#export musicsize=4G

# If you want to automatically copy music from a CIFS share every time
# the Pi connects to wifi, set the following variable. The share is
# assumed to exist on the same server as the archive share. It can
# be the same share as the share used for backing up recordings, but
# the folder needs to be different.
# export musicsharename=your_music_share/music_folder

# Wifi setup information
export SSID=wifi
export WIFIPASS='password'

# If doing a headless (i.e. automatic) setup
export HEADLESS_SETUP=true

# Uncomment if setting up Pushover push notifications 
# export pushover_enabled=false
# export pushover_user_key=user_key
# export pushover_app_key=app_key

# Uncomment and change if you want setup scripts to be pulled
# from a different repo than github.com/marcone/teslausb
# export REPO=marcone

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

If you're having trouble configuring teslausb, please check the troubleshooting document on the wiki before reporting an issue.
For questions, check the FAQ first, or ask them on the Discord server

When you do file an issue, include as much detail as possible, or the issue will likely be closed.
You can run setup-teslausb diagnose to capture a lot of the relevant information:

sudo -i
/root/bin/setup-teslausb selfupdate
/root/bin/setup-teslausb diagnose > /tmp/diagnostics.txt

Then include the generated diagnostics.txt in your issue report, or put it in pastebin or gist and link to it.

I have a 200GB SD card and get the following errors each attempt. The SD card is cleared each attempt and I use Rufus to image.

Fri 12 Apr 02:54:09 BST 2019 : Starting setup.
Fri 12 Apr 02:54:09 BST 2019 : Updating package index files...
Fri 12 Apr 03:12:00 BST 2019 : Verifying that the requested configuration is valid...
Fri 12 Apr 03:12:01 BST 2019 : Downloaded /tmp/verify-configuration.sh ...
Fri 12 Apr 03:12:01 BST 2019 : Verifying that there is sufficient space available on the MicroSD card...
Fri 12 Apr 03:12:02 BST 2019 : STOP: The MicroSD card is too small: 104857600 bytes available.
Fri 12 Apr 03:12:02 BST 2019 : BYT;
/dev/mmcblk0:197GB:sd/mmc:512:512:msdos:SD SC200:;
1:4194kB:49.9MB:45.7MB:fat32::lba;
2:50.3MB:1816MB:1766MB:ext4::;
3:1816MB:197GB:195GB:ext4::;
4:197GB:197GB:105MB:ext4::;

I'm trying to sync my music over and its semi working. Out of 100 songs, its only syncing across around 30. Tried restarting the PI to start sync again and it says its finished copying even though it's not 1:1 synched.

Fri 17 May 20:02:50 BST 2019: Finished fsck on /mnt/music.
Fri 17 May 20:02:50 BST 2019: Copying music from archive...
Fri 17 May 20:03:08 BST 2019: Unmounting /mnt/music...
Fri 17 May 20:03:09 BST 2019: Unmounted /mnt/music.
Fri 17 May 20:03:09 BST 2019: Finished copying music.

I just blew half my Sunday and a hefty chunk of today banging my head against the wall trying to set up my new Raspberry Pi Zero W using the instructions provided for this project. I finally discovered that the problem was that I have a two-band WiFI router, and the 2.4 and 5 Ghz networks use different SSIDs. I had not read anywhere (in this project, on Amazon where I bought the thing, or even on the main RaspberryPI site) that the Raspberry Pi Zero W only supports 2.4Ghz, so I'd been using the SSID that all my devices use, and had absolutely no luck with headless setup.

I eventually managed to figure it out by hooking my Pi up to my monitor and keyboard and logging in directly, then futzing around with raspi-config. And don't get me started on the absurdity of the default keyboard config being UK instead of US, which completely breaks your ability to type pipe characters and double-quotes. Ugh that was a pain to find a fix for.

Anyway, seeing as how this project is likely to be encountered primarily by RaspberryPi newbies like myself, I'd simply like to request that it's instructions should mention the Pi Zero W's 2.4 Ghz WiFi band limitation.

I'd also love to know if you have any advice to help get ssh [email protected] to work. I've installed Bonjour, but that didn't help. I still get "Could not resolve hostname raspberrypi.local: No such host is known." The only way I can get into the Pi is by ssh'ing directly to it's WiFi IP (192.168.1.111 in my case). Which actually makes me wonder if the "USB Ethernet/RNDIS Gadget" is even doing anything. Or are the instructions regarding that just a hint about when the Pi has finished booting up?

Anyway, now that I've finally got networking functional, I'm going to keep trying to set up my Pi for TeslaUSB. Thanks for making such a cool tool!

This is my archiveloop for today:

Fri 24 May 16:05:09 CDT 2019: Archive is reachable.
Fri 24 May 16:05:29 CDT 2019: Archiving...
Fri 24 May 16:05:29 CDT 2019: Disconnecting usb from host...
Fri 24 May 16:05:29 CDT 2019: Disconnected usb from host.
Fri 24 May 16:05:29 CDT 2019: Ensuring cam archive is mounted...
Fri 24 May 16:05:29 CDT 2019: /mnt/archive is already mounted.
Fri 24 May 16:05:29 CDT 2019: Ensured cam archive is mounted.
Fri 24 May 16:05:29 CDT 2019: Starting...
Fri 24 May 16:05:29 CDT 2019: Ensuring cam file is mounted...
Fri 24 May 16:05:29 CDT 2019: Mounting /mnt/cam...
Fri 24 May 16:05:29 CDT 2019: Mounted /mnt/cam.
Fri 24 May 16:05:30 CDT 2019: Ensured cam file is mounted.
Fri 24 May 16:05:30 CDT 2019: Running fsck on /mnt/cam...
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/loop0: 389 files, 312620/3538228 clusters
Fri 24 May 16:05:32 CDT 2019: Finished fsck on /mnt/cam.
Fri 24 May 16:05:32 CDT 2019: Moving clips to archive...
Fri 24 May 16:05:32 CDT 2019: Creating output directory ''
Fri 24 May 16:05:32 CDT 2019: Creating output directory '2019-05-24_08-08-11'
Fri 24 May 16:05:32 CDT 2019: Moving '2019-05-24_08-08-11/2019-05-24_07-58-57-front.mp4'
Fri 24 May 16:06:01 CDT 2019: Moved '2019-05-24_08-08-11/2019-05-24_07-58-57-front.mp4'
Fri 24 May 16:06:01 CDT 2019: Moving '2019-05-24_08-08-11/2019-05-24_07-58-57-left_repeater.mp4'
Fri 24 May 16:06:25 CDT 2019: Moved '2019-05-24_08-08-11/2019-05-24_07-58-57-left_repeater.mp4'
Fri 24 May 16:06:25 CDT 2019: Moving '2019-05-24_08-08-11/2019-05-24_07-58-57-right_repeater.mp4'
Fri 24 May 16:06:51 CDT 2019: Moved '2019-05-24_08-08-11/2019-05-24_07-58-57-right_repeater.mp4'
Fri 24 May 16:06:51 CDT 2019: Moving '2019-05-24_08-08-11/2019-05-24_07-59-57-front.mp4'
Fri 24 May 16:07:09 CDT 2019: Moved '2019-05-24_08-08-11/2019-05-24_07-59-57-front.mp4'
Fri 24 May 16:07:09 CDT 2019: Moving '2019-05-24_08-08-11/2019-05-24_07-59-57-left_repeater.mp4'
Fri 24 May 16:07:28 CDT 2019: Moved '2019-05-24_08-08-11/2019-05-24_07-59-57-left_repeater.mp4'
Fri 24 May 16:07:28 CDT 2019: Moving '2019-05-24_08-08-11/2019-05-24_07-59-57-right_repeater.mp4'
Fri 24 May 16:07:55 CDT 2019: Moved '2019-05-24_08-08-11/2019-05-24_07-59-57-right_repeater.mp4'
Fri 24 May 16:07:55 CDT 2019: Moving '2019-05-24_08-08-11/2019-05-24_08-00-57-front.mp4'
Fri 24 May 16:08:25 CDT 2019: Moved '2019-05-24_08-08-11/2019-05-24_08-00-57-front.mp4'
Fri 24 May 16:08:25 CDT 2019: Moving '2019-05-24_08-08-11/2019-05-24_08-00-57-left_repeater.mp4'
Fri 24 May 16:08:43 CDT 2019: Moved '2019-05-24_08-08-11/2019-05-24_08-00-57-left_repeater.mp4'
Fri 24 May 16:08:43 CDT 2019: Moving '2019-05-24_08-08-11/2019-05-24_08-00-57-right_repeater.mp4'
Fri 24 May 16:08:56 CDT 2019: Moved '2019-05-24_08-08-11/2019-05-24_08-00-57-right_repeater.mp4'
Fri 24 May 16:08:56 CDT 2019: Moving '2019-05-24_08-08-11/2019-05-24_08-01-58-front.mp4'
Fri 24 May 16:09:07 CDT 2019: Moved '2019-05-24_08-08-11/2019-05-24_08-01-58-front.mp4'
Fri 24 May 16:09:07 CDT 2019: Moving '2019-05-24_08-08-11/2019-05-24_08-01-58-left_repeater.mp4'
Fri 24 May 16:09:20 CDT 2019: Moved '2019-05-24_08-08-11/2019-05-24_08-01-58-left_repeater.mp4'
Fri 24 May 16:09:20 CDT 2019: Moving '2019-05-24_08-08-11/2019-05-24_08-01-58-right_repeater.mp4'
Fri 24 May 16:09:32 CDT 2019: Moved '2019-05-24_08-08-11/2019-05-24_08-01-58-right_repeater.mp4'
Fri 24 May 16:09:32 CDT 2019: Moving '2019-05-24_08-08-11/2019-05-24_08-02-58-front.mp4'
Fri 24 May 16:09:47 CDT 2019: Moved '2019-05-24_08-08-11/2019-05-24_08-02-58-front.mp4'
Fri 24 May 16:09:47 CDT 2019: Moving '2019-05-24_08-08-11/2019-05-24_08-02-58-left_repeater.mp4'
Fri 24 May 16:10:02 CDT 2019: Moved '2019-05-24_08-08-11/2019-05-24_08-02-58-left_repeater.mp4'
Fri 24 May 16:10:02 CDT 2019: Moving '2019-05-24_08-08-11/2019-05-24_08-02-58-right_repeater.mp4'
Fri 24 May 16:10:14 CDT 2019: Moved '2019-05-24_08-08-11/2019-05-24_08-02-58-right_repeater.mp4'
Fri 24 May 16:10:14 CDT 2019: Moving '2019-05-24_08-08-11/2019-05-24_08-03-58-front.mp4'
Fri 24 May 16:10:26 CDT 2019: Moved '2019-05-24_08-08-11/2019-05-24_08-03-58-front.mp4'
Fri 24 May 16:10:26 CDT 2019: Moving '2019-05-24_08-08-11/2019-05-24_08-03-58-left_repeater.mp4'
Fri 24 May 16:10:38 CDT 2019: Moved '2019-05-24_08-08-11/2019-05-24_08-03-58-left_repeater.mp4'
Fri 24 May 16:10:38 CDT 2019: Moving '2019-05-24_08-08-11/2019-05-24_08-03-58-right_repeater.mp4'
Fri 24 May 16:10:50 CDT 2019: Moved '2019-05-24_08-08-11/2019-05-24_08-03-58-right_repeater.mp4'
Fri 24 May 16:10:50 CDT 2019: Moving '2019-05-24_08-08-11/2019-05-24_08-04-58-front.mp4'
Fri 24 May 16:11:01 CDT 2019: Moved '2019-05-24_08-08-11/2019-05-24_08-04-58-front.mp4'
Fri 24 May 16:11:01 CDT 2019: Moving '2019-05-24_08-08-11/2019-05-24_08-04-58-left_repeater.mp4'
Fri 24 May 16:11:15 CDT 2019: Moved '2019-05-24_08-08-11/2019-05-24_08-04-58-left_repeater.mp4'
Fri 24 May 16:11:15 CDT 2019: Moving '2019-05-24_08-08-11/2019-05-24_08-04-58-right_repeater.mp4'
Fri 24 May 16:11:32 CDT 2019: Moved '2019-05-24_08-08-11/2019-05-24_08-04-58-right_repeater.mp4'
Fri 24 May 16:11:32 CDT 2019: Moving '2019-05-24_08-08-11/2019-05-24_08-05-59-front.mp4'
Fri 24 May 16:11:50 CDT 2019: Moved '2019-05-24_08-08-11/2019-05-24_08-05-59-front.mp4'
Fri 24 May 16:11:50 CDT 2019: Moving '2019-05-24_08-08-11/2019-05-24_08-05-59-left_repeater.mp4'
Fri 24 May 16:12:08 CDT 2019: Moved '2019-05-24_08-08-11/2019-05-24_08-05-59-left_repeater.mp4'
Fri 24 May 16:12:09 CDT 2019: Moving '2019-05-24_08-08-11/2019-05-24_08-05-59-right_repeater.mp4'
Fri 24 May 16:12:27 CDT 2019: Moved '2019-05-24_08-08-11/2019-05-24_08-05-59-right_repeater.mp4'
Fri 24 May 16:12:27 CDT 2019: Moving '2019-05-24_08-08-11/2019-05-24_08-06-59-front.mp4'
Fri 24 May 16:13:42 CDT 2019: Moved '2019-05-24_08-08-11/2019-05-24_08-06-59-front.mp4'
Fri 24 May 16:13:42 CDT 2019: Moving '2019-05-24_08-08-11/2019-05-24_08-06-59-left_repeater.mp4'
Fri 24 May 16:15:37 CDT 2019: Moved '2019-05-24_08-08-11/2019-05-24_08-06-59-left_repeater.mp4'
Fri 24 May 16:15:37 CDT 2019: Moving '2019-05-24_08-08-11/2019-05-24_08-06-59-right_repeater.mp4'

It seems to be stuck writing that file as it's now well past 18:30 CDT...

dmesg:

[505777.675521] INFO: task mv:2257 blocked for more than 120 seconds.
[505777.675544]       Tainted: G         C        4.19.37+ #1216
[505777.675551] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[505777.675562] mv              D    0  2257   2091 0x00000000
[505777.675629] [<c06c6890>] (__schedule) from [<c06c6d6c>] (schedule+0x50/0xa8)
[505777.675664] [<c06c6d6c>] (schedule) from [<c004e3e0>] (io_schedule+0x20/0x48)
[505777.675702] [<c004e3e0>] (io_schedule) from [<c0104d14>] (wait_on_page_bit+0x108/0x150)
[505777.675727] [<c0104d14>] (wait_on_page_bit) from [<c0104e54>] (__filemap_fdatawait_range+0xf8/0x148)
[505777.675750] [<c0104e54>] (__filemap_fdatawait_range) from [<c0104ecc>] (filemap_fdatawait_range+0x28/0x38)
[505777.675774] [<c0104ecc>] (filemap_fdatawait_range) from [<c01073a4>] (filemap_write_and_wait+0x68/0x9c)
[505777.676458] [<c01073a4>] (filemap_write_and_wait) from [<bf5c01c4>] (cifs_setattr+0x90/0x86c [cifs])
[505777.676885] [<bf5c01c4>] (cifs_setattr [cifs]) from [<c019005c>] (notify_change+0x1c4/0x40c)
[505777.676916] [<c019005c>] (notify_change) from [<c01a6dec>] (utimes_common+0xc0/0x198)
[505777.676937] [<c01a6dec>] (utimes_common) from [<c01a6fe0>] (do_utimes+0x11c/0x160)
[505777.676957] [<c01a6fe0>] (do_utimes) from [<c01a71c4>] (sys_utimensat+0x80/0xc0)
[505777.676978] [<c01a71c4>] (sys_utimensat) from [<c0009000>] (ret_fast_syscall+0x0/0x28)
[505777.676988] Exception stack(0xca87ffa8 to 0xca87fff0)
[505777.677004] ffa0:                   00000000 00000005 00000005 00000000 bedfc19c 00000000
[505777.677020] ffc0: 00000000 00000005 00037ef0 0000015c 00038838 00000000 00037ef0 bedfc4ac
[505777.677032] ffe0: b6e53834 bedfc120 0001ef30 b6e53854
[505900.557062] INFO: task mv:2257 blocked for more than 120 seconds.
[505900.557084]       Tainted: G         C        4.19.37+ #1216
[505900.557091] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[505900.557101] mv              D    0  2257   2091 0x00000000
[505900.557165] [<c06c6890>] (__schedule) from [<c06c6d6c>] (schedule+0x50/0xa8)
[505900.557202] [<c06c6d6c>] (schedule) from [<c004e3e0>] (io_schedule+0x20/0x48)
[505900.557237] [<c004e3e0>] (io_schedule) from [<c0104d14>] (wait_on_page_bit+0x108/0x150)
[505900.557262] [<c0104d14>] (wait_on_page_bit) from [<c0104e54>] (__filemap_fdatawait_range+0xf8/0x148)
[505900.557284] [<c0104e54>] (__filemap_fdatawait_range) from [<c0104ecc>] (filemap_fdatawait_range+0x28/0x38)
[505900.557307] [<c0104ecc>] (filemap_fdatawait_range) from [<c01073a4>] (filemap_write_and_wait+0x68/0x9c)
[505900.557971] [<c01073a4>] (filemap_write_and_wait) from [<bf5c01c4>] (cifs_setattr+0x90/0x86c [cifs])
[505900.558397] [<bf5c01c4>] (cifs_setattr [cifs]) from [<c019005c>] (notify_change+0x1c4/0x40c)
[505900.558427] [<c019005c>] (notify_change) from [<c01a6dec>] (utimes_common+0xc0/0x198)
[505900.558451] [<c01a6dec>] (utimes_common) from [<c01a6fe0>] (do_utimes+0x11c/0x160)
[505900.558468] [<c01a6fe0>] (do_utimes) from [<c01a71c4>] (sys_utimensat+0x80/0xc0)
[505900.558490] [<c01a71c4>] (sys_utimensat) from [<c0009000>] (ret_fast_syscall+0x0/0x28)
[505900.558501] Exception stack(0xca87ffa8 to 0xca87fff0)
[505900.558517] ffa0:                   00000000 00000005 00000005 00000000 bedfc19c 00000000
[505900.558533] ffc0: 00000000 00000005 00037ef0 0000015c 00038838 00000000 00037ef0 bedfc4ac
[505900.558545] ffe0: b6e53834 bedfc120 0001ef30 b6e53854

Is it safe to reboot and keep all of my files? Can I manually restart the archiveloop script or some such? Tried looking through previous issues/FAQ, but I might be blind!

The rsync method successfully moves files to the remote rsync server, but it does not remove them from the raspberry pi, so it eventually fills up.

I am trying a potential fix. See attached revised contents of archive-clips.sh
archive-clips.sh.gz

Hey so Sentry Mode told me it had 4 events so it should've saved something...but it saved absolutely nothing (there's nothing left in /mnt/cam). Yes the camera icon was there and should've been working.

What logs would be helpful in figuring out why it would've not saved files or just deleted them?

Edit: Everything worked previously and nothing has changed, btw. teslausb version: teslausb-20190505

The application is moving files to my Shared drive. The shared drive is named TeslaShare and it has a folder TeslaCam with two sub folders SavedClips and RecentClips. The moved files appear to be moved in bathes that very in size and are themselves enclosed in a date folder. They are moved to the root, not into TeslaCam nor into the appropriate subdirectory in TeslaCam. Additionally, they are only openable but the username I gave for the shared drive. This occurs even though in my sharing I have given admins and the car as a user read/write access (permissions) and the shared drive and all subfolders on the drive have that admins and auto as user with read/write permission. (I suspect when it creates the date sub-folder it only gives itself permission). Why it doesn't move files to the appropriate sub-folder isn't clear. I could change the user to myself to resolve the issue of permissions but I'm not sure how to fix it creating date subfolders and not putting things in the correct subfolder. The reason this is desirable is that the App called DashCam Viewer (Downloadable from the Apple App store) expects to find files in the proper sub directories in TeslaCam and it allows you to view 3 cameras simultaneously which is a nice feature. Thanks for guidance on how to fix this.