-
Notifications
You must be signed in to change notification settings - Fork 366
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
cellular: attempt sync right after each snapshot #931
base: main-dev
Are you sure you want to change the base?
cellular: attempt sync right after each snapshot #931
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In addition to the specific code comments, there is another issue with this change as written: after a successful archive, TeslaUSB disconnects the cam drive from the car in order to do cleanup, and will disconnect the music drive from the car to sync music. With this new sync-after-snapshot feature enabled, that would mean that dashcam/sentry recording and music playback will be interrupted after every sync.
@@ -16,6 +16,10 @@ | |||
export SSID='your_ssid' | |||
export WIFIPASS='your_pass' | |||
|
|||
# Cellular Connection Quality-of-Life | |||
# 1. If using a cellular connection, turn on the following flag to have TeslaUSB attempt sync right after each snapshot. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"1." implies this is part of a list, but it isn't. Also this isn't necessarily related to having a cellular connection, it's any connection.
then | ||
log "Copying music..." | ||
if copy_music_files | ||
if [ ! -e /mutable/ARCHIVING_CLIPS ] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This should be in /tmp, not in /mutable (otherwise if the Pi shuts off in the middle of archiving, it will never archive again)
I'd also prefer this to to be structured like:
if [ -e /tmp/ARCHIVING_CLIPS ]
then
return
fi
touch /tmp/ARCHIVING_CLIPS
...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Got it; thanks.
@marcone, on a side note, that actually explained a strange phenomenon that I observed these few days: sometimes I wake up in the morning and find out that my raspi has been offline for several hours according to network logs---the USB port and 12V port were all disconnected by the vehicle. Now I would conjecture that it was the cleanup process that took the cam drive off the vehicle so long, such that the vehicle decided that, even though sentry was active, since no drive is connected, it would be appropriate to cut the power, thus preventing teslausb to ever re-connect. The logs corroborated this as it was cut off right after |
Function
archive_clips
is expected to be run async and thus will put a lock file in/mutable
when it's running. If the env var flagARCHIVE_SYNC_AFTER_SNAPSHOP
is set,archive_clips
will be called each time snapshot is completed.Do you think this is a good idea? Sorry that I am inexperienced working with bash scripts and not sure if this lock file thing is good practice.