marcone / teslausb

A smart USB drive for Tesla Dashcam - extended storage, auto archive, web viewer
MIT License
1.83k stars 335 forks source link

Deleted All Videos, Saved Nothing #28

Closed ghost closed 5 years ago

ghost commented 5 years ago

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

marcone commented 5 years ago

"there's nothing left in /mnt/cam" sounds like the normal state after a successful backup: after a backup it will unmount the drive from /mnt/cam, and reconnect it to the car, i.e. at that point /mnt/cam will just be the empty mountpoint, but the car will see the drive. You can check /mutable/archiveloop.log, which should tell you exactly if it backed up any files and if so which ones. If it backed up something, you should see something like:

Wed 15 May 18:32:23 PDT 2019: Moving clips to archive...
Wed 15 May 18:32:23 PDT 2019: Creating output directory ''
Wed 15 May 18:32:23 PDT 2019: Creating output directory '2019-05-15_16-17-03'
Wed 15 May 18:32:23 PDT 2019: Moving '2019-05-15_16-17-03/2019-05-15_16-16-front.mp4'
Wed 15 May 18:36:34 PDT 2019: Moved '2019-05-15_16-17-03/2019-05-15_16-16-front.mp4'
Wed 15 May 18:36:34 PDT 2019: Moving '2019-05-15_16-17-03/2019-05-15_16-16-left_repeater.mp4'
Wed 15 May 18:40:50 PDT 2019: Moved '2019-05-15_16-17-03/2019-05-15_16-16-left_repeater.mp4'
Wed 15 May 18:40:50 PDT 2019: Moving '2019-05-15_16-17-03/2019-05-15_16-16-right_repeater.mp4'
Wed 15 May 18:47:44 PDT 2019: Moved '2019-05-15_16-17-03/2019-05-15_16-16-right_repeater.mp4'
Wed 15 May 18:47:44 PDT 2019: Moving '2019-05-15_16-17-03/2019-05-15_16-17-front.mp4'
Wed 15 May 18:49:08 PDT 2019: Moved '2019-05-15_16-17-03/2019-05-15_16-17-front.mp4'
Wed 15 May 18:49:08 PDT 2019: Moving '2019-05-15_16-17-03/2019-05-15_16-17-left_repeater.mp4'
Wed 15 May 18:51:56 PDT 2019: Moved '2019-05-15_16-17-03/2019-05-15_16-17-left_repeater.mp4'
Wed 15 May 18:51:56 PDT 2019: Moving '2019-05-15_16-17-03/2019-05-15_16-17-right_repeater.mp4'
Wed 15 May 18:53:11 PDT 2019: Moved '2019-05-15_16-17-03/2019-05-15_16-17-right_repeater.mp4'
Wed 15 May 18:53:11 PDT 2019: Moved 6 file(s), failed to copy 0, deleted 0.
Wed 15 May 18:53:11 PDT 2019: Finished moving clips to archive.

If there was nothing to back up, it will show something like this instead:

Thu  3 Nov 10:17:16 PDT 2016: Moving clips to archive...
Thu  3 Nov 10:17:16 PDT 2016: Creating output directory ''
Thu  3 Nov 10:17:16 PDT 2016: Creating output directory ''
Thu  3 Nov 10:17:16 PDT 2016: Moved 0 file(s), failed to copy 0, deleted 0.
Thu  3 Nov 10:17:16 PDT 2016: Finished moving clips to archive.

Also if you set up your Pi between May 5 and 11 and used 100% of the available space, you may have to redo setup. There was a problem with using all the available space that could prevent the car from writing to the drive at all.

ghost commented 5 years ago

This is a snippet of the archiveloop from the relevant time:

Thu 16 May 16:45:15 CDT 2019: Archive is reachable.
Thu 16 May 16:45:35 CDT 2019: Archiving...
Thu 16 May 16:45:35 CDT 2019: Disconnecting usb from host...
Thu 16 May 16:45:35 CDT 2019: Disconnected usb from host.
Thu 16 May 16:45:36 CDT 2019: Ensuring cam archive is mounted...
Thu 16 May 16:45:36 CDT 2019: /mnt/archive is already mounted.
Thu 16 May 16:45:36 CDT 2019: Ensured cam archive is mounted.
Thu 16 May 16:45:36 CDT 2019: Starting...
Thu 16 May 16:45:36 CDT 2019: Ensuring cam file is mounted...
Thu 16 May 16:45:36 CDT 2019: Mounting /mnt/cam...
Thu 16 May 16:45:36 CDT 2019: Mounted /mnt/cam.
Thu 16 May 16:45:36 CDT 2019: Ensured cam file is mounted.
Thu 16 May 16:45:36 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.
FATs differ but appear to be intact. Using first FAT.
Reclaimed 35857 unused clusters (1174962176 bytes) in 46 chains.
Free cluster summary wrong (3726586 vs. really 3690750)
  Auto-correcting.
Performing changes.
/dev/loop0: 121 files, 85567/3776317 clusters
Thu 16 May 16:45:39 CDT 2019: Finished fsck on /mnt/cam.
Thu 16 May 16:45:39 CDT 2019: Moving clips to archive...
Thu 16 May 16:45:39 CDT 2019: Creating output directory ''
Thu 16 May 16:45:39 CDT 2019: Creating output directory ''
Thu 16 May 16:45:39 CDT 2019: Moved 0 file(s), failed to copy 0, deleted 0.
Thu 16 May 16:45:39 CDT 2019: Finished moving clips to archive.
Thu 16 May 16:45:39 CDT 2019: Unmounting /mnt/cam...
Thu 16 May 16:51:41 CDT 2019: Unmounted /mnt/cam.
Thu 16 May 16:51:41 CDT 2019: Finished archiving.
Thu 16 May 16:51:41 CDT 2019: No music archive configured
Thu 16 May 16:51:41 CDT 2019: Connecting usb to host...
Thu 16 May 16:51:41 CDT 2019: Connected usb to host.

But if Sentry Mode had 4 events, it definitely should've saved something. Any other logs I can look it to see maybe why it didn't save something?

Note: It's a 128GB microSD card that's basically empty.

marcone commented 5 years ago

what does df /backingfiles say?

ghost commented 5 years ago
root@teslausb:~# df /backingfiles
Filesystem     1K-blocks      Used Available Use% Mounted on
/dev/mmcblk0p3 122983424 122125792         0 100% /backingfiles
root@teslausb:~#

Edit: I'm going to assume that's not what it should be. :D

Edit:

root@teslausb:/backingfiles# ls -lah
total 116G
drwxr-xr-x  1 root root   24 May 13 20:25 .
drwxr-xr-x 23 root root 4.0K May 13 20:25 ..
-rw-r--r--  1 root root 116G May 16 20:56 cam_disk.bin
root@teslausb:/backingfiles#
marcone commented 5 years ago

Odd, you seem to be "missing" over 800 megabytes of space: /backingfiles is 117.3 gigabytes, of which 116.5 gigabytes are used, yet there is 0 available space. What does btrfs fi df /backingfiles/ say?

ghost commented 5 years ago
root@teslausb:~# btrfs fi df /backingfiles/
Data, single: total=116.27GiB, used=116.27GiB
System, single: total=4.00MiB, used=16.00KiB
Metadata, single: total=1.01GiB, used=99.61MiB
GlobalReserve, single: total=98.84MiB, used=0.00B
root@teslausb:~#
marcone commented 5 years ago

Any errors in dmesg?

ghost commented 5 years ago

An insane amount of lines like this:

[248663.943651] print_req_error: I/O error, dev loop0, sector 50211
[248663.943667] Buffer I/O error on dev loop0, logical block 50211, lost async page write
[248668.838630] lo_write_bvec: 408 callbacks suppressed
[248668.838646] loop: Write error at byte offset 26966016, length 512.
[248668.838669] print_req_error: 408 callbacks suppressed
[248668.838678] print_req_error: I/O error, dev loop0, sector 50620
[248668.838694] buffer_io_error: 408 callbacks suppressed
[248668.838704] Buffer I/O error on dev loop0, logical block 50620, lost async page write
[248668.857937] loop: Write error at byte offset 26966528, length 512.
[248668.857967] print_req_error: I/O error, dev loop0, sector 50621
[248668.857989] Buffer I/O error on dev loop0, logical block 50621, lost async page write
[248668.870072] loop: Write error at byte offset 26967040, length 512.

This goes on basically indefinitely.

Edit: After all of that, it ends with this:

[248770.472722] Mass Storage Function, version: 2009/09/11
[248770.472741] LUN: removable file: (no medium)
[248770.472916] LUN: removable file: /backingfiles/cam_disk.bin
[248770.472925] Number of LUNs=1
[248770.484231] g_mass_storage gadget: Mass Storage Gadget, version: 2009/09/11
[248770.484249] g_mass_storage gadget: g_mass_storage ready
[248770.484265] dwc2 20980000.usb: bound driver g_mass_storage
[250295.443907] dwc2 20980000.usb: new device is full-speed
[250295.821323] dwc2 20980000.usb: new device is full-speed
[250295.895640] dwc2 20980000.usb: new device is full-speed
[250296.198903] dwc2 20980000.usb: new device is high-speed
[250296.271600] dwc2 20980000.usb: new device is high-speed
[250296.329523] dwc2 20980000.usb: new address 7
[250296.343237] g_mass_storage gadget: high-speed config #1: Linux File-Backed Storage
[252214.155570] dwc2 20980000.usb: new device is full-speed
[252214.535382] dwc2 20980000.usb: new device is full-speed
[252214.599532] dwc2 20980000.usb: new device is full-speed
[252214.902006] dwc2 20980000.usb: new device is high-speed
[252214.974948] dwc2 20980000.usb: new device is high-speed
[252215.032734] dwc2 20980000.usb: new address 12
[252215.045321] g_mass_storage gadget: high-speed config #1: Linux File-Backed Storage
[255661.292464] dwc2 20980000.usb: new device is full-speed
[255661.669515] dwc2 20980000.usb: new device is full-speed
[255661.743437] dwc2 20980000.usb: new device is full-speed
[255662.045903] dwc2 20980000.usb: new device is high-speed
[255662.118737] dwc2 20980000.usb: new device is high-speed
[255662.176590] dwc2 20980000.usb: new address 8
[255662.189277] g_mass_storage gadget: high-speed config #1: Linux File-Backed Storage
[258460.630519] dwc2 20980000.usb: new device is full-speed
[258461.009537] dwc2 20980000.usb: new device is full-speed
[258461.083360] dwc2 20980000.usb: new device is full-speed
[258461.388825] dwc2 20980000.usb: new device is high-speed
[258461.461778] dwc2 20980000.usb: new device is high-speed
[258461.519579] dwc2 20980000.usb: new address 4
[258461.532030] g_mass_storage gadget: high-speed config #1: Linux File-Backed Storage
[260910.900939] CIFS VFS: Close unmatched open
[262031.832254] dwc2 20980000.usb: new device is full-speed
[262032.214003] dwc2 20980000.usb: new device is full-speed
[262032.287738] dwc2 20980000.usb: new device is full-speed
[262032.590115] dwc2 20980000.usb: new device is high-speed
[262032.662907] dwc2 20980000.usb: new device is high-speed
[262032.720746] dwc2 20980000.usb: new address 6
[262032.734541] g_mass_storage gadget: high-speed config #1: Linux File-Backed Storage
marcone commented 5 years ago

The "lost async write" thing is the same error as https://github.com/marcone/teslausb/issues/26, which I thought I fixed by leaving about a gigabyte of free space. Either that's not enough, or something else went wrong. When did you set up this device?

ghost commented 5 years ago

The 13th. The device successfully backed up videos on the 14th without issue. Didn't get a chance for any additional testing until today when the 4 Sentry videos went MIA. :)

Edit: and we can move all of this discussion back over to #26 if that's more ideal.

marcone commented 5 years ago

At this point I would recommend redoing setup and possibly also selecting a smaller camsize. Note that the car will only keep the last hour of non-saved recordings, or about 5.5 GB, so using 116 GB for recordings is enough for the last 1 hour, plus another 20 hours of saved recordings. I doubt you press the save button that much between backups :)

I changed the scripts back to using ext4 for the backingfiles partition for now, until I can sort out the btrfs issue. Give it a few minutes to propagate on Github, then rerun setup. You don't need to download a new release, just reflash 20190505, and it will download the current setup scripts.

ghost commented 5 years ago

So in the .conf I should just set the size to like 50% or something?

marcone commented 5 years ago

Now that it's back to using ext4 I don't think it really matters and 100% should be fine. I usually use "32G" myself.

ghost commented 5 years ago

Oh, you can specify a size as well? Guess I missed that!

Cat forced me to bed, but I’ll give the updated stuff a try in the morning. Thanks for the quick replies/resolution!

Btw: any reason for aiming for btrfs over ext4 in general? I know Synology uses a hybrid solution of btrfs and ext4, but their reasoning involves btrfs’ issues with RAID. Just curious which btrfs features you’re looking to take advantage of!


From: marcone notifications@github.com Sent: Thursday, May 16, 2019 22:24 To: marcone/teslausb Cc: xnaas; Author Subject: Re: [marcone/teslausb] Deleted All Videos, Saved Nothing (#28)

Now that it's back to using ext4 I don't think it really matters and 100% should be fine. I usually use "32G" myself.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHubhttps://github.com/marcone/teslausb/issues/28?email_source=notifications&email_token=AB7DLX5JFZBHLV4B5IE3B73PVYQQRA5CNFSM4HNROW2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODVTT4QQ#issuecomment-493305410, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AB7DLX5YYDTVGRCPGEB5JNTPVYQQRANCNFSM4HNROW2A.

marcone commented 5 years ago

The plan was to use btrfs to take snapshots of the disk image while it's in use by the car, so I can get past the artificial 1-hour time window and keep more recordings.

ghost commented 5 years ago

Ahhh, very cool. I wish you luck in that endeavor! Worst case scenario, I guess btrfs just needs a boatload of free space. 🙃

Thanks again. ♥️


From: marcone notifications@github.com Sent: Thursday, May 16, 2019 22:35 To: marcone/teslausb Cc: xnaas; Author Subject: Re: [marcone/teslausb] Deleted All Videos, Saved Nothing (#28)

The plan was to use btrfs to take snapshots of the disk image while it's in use by the car, so I can get past the artificial 1-hour time window and keep more recordings.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHubhttps://github.com/marcone/teslausb/issues/28?email_source=notifications&email_token=AB7DLXYJWGCTX7OB4JUD5BTPVYRZ7A5CNFSM4HNROW2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODVTULBY#issuecomment-493307271, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AB7DLX6QYLNDFFW75WNR2U3PVYRZ7ANCNFSM4HNROW2A.

ghost commented 5 years ago

Didn't get a chance to set this up again this morning, but I just set it back up after getting home. Since it's already been rolled back to ext4, I'll go ahead and close out this issue and monitor #26. :)

Thanks once again!

ghost commented 5 years ago

Well, not sure what I fucked up this time around, but this doesn't seem right:

Fri 17 May 19:23:31 CDT 2019: Mounting /mnt/archive...
mount: can't find /mnt/archive in /etc/fstab
Fri 17 May 19:23:31 CDT 2019: Failed to mount /mnt/archive.
Fri 17 May 19:23:31 CDT 2019: Attempts exhausted.
Fri 17 May 19:23:31 CDT 2019: Failed to mount cam archive.
Fri 17 May 19:23:31 CDT 2019: Couldn't connect archive, skipping archive step

Is the formatting of my .conf incorrect?

export ARCHIVE_SYSTEM=cifs
export archiveserver=192.168.1.150
export sharename=Media/Videos/TeslaCam

Could've sworn this worked previously?

marcone commented 5 years ago

Looks OK to me, assuming you also specified the username and password to use. To be honest I've never used a "share/folder/subfolder" type path, I've always used "share/folder". The fact that /mnt/archive isn't in fstab indicates something went wrong during setup, so check the setup log in /boot.

ghost commented 5 years ago

Hmm. It's complaining about the CIFS version, but there's not a chance that's right.

Edit: I'm reflashing specifying CIFS version 2.1, but idk if that's gonna help. 🤔

Edit: As predicted, changing the CIFS version didn't change anything. Hmm...idk wtf I did, nothing changed! lol

Edit: Eventually got it sorted out. Changed the password for the account and it seems to be working fine. No idea why it suddenly stopped liking the old password, but whatever!

marcone commented 5 years ago

Does/did your password have special characters in it, and you forgot to quote it?

ghost commented 5 years ago

Edit: Fuck it. I rebooted the thing again and it seems like it might finally be good to go, again. 🙃