-
Notifications
You must be signed in to change notification settings - Fork 347
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
USB drive is not accessible by Dashcam #207
Comments
I started getting this on .32 as well on my model 3. I might have 3 Sentry events, but come back to the car with the error message and only one folder created on the Pi. Restarting the pi (pulling power) and letting it restart will reconnect the drive, but the 2 recordings while it wasn’t writing are lost. Doesn’t always happen either, but 2/3 Times when I parked today (all had 1-3 sentry events). Update: Adding my Diagnostics.txt after 3rd occurrence today (making it 3/4): |
I'm having similar issues with .28 and 2 days ago I upgraded to most recently version using teslausb selfupdate. My message says the same except it says 'not readable' rather than accessible. And the following message about formatting is slightly differerent. Most likely same error but they changed the message for the newer firmware. I brought this up in my message here: This wasn't happening until I decided to upgrade teslausb. How about an option to roll back to an earlier build? |
Same here. I upgraded teslausb and I am getting hit with the same error. If I unplug and use, sometimes I get the error about USB being too slow. I use a Sandisk extreme, so I don't think the SD card speed is the issue. The USB being too slow is a Model 3 error AFAIK, it does not seem to impact the S and X. |
I have the same issue since updating TeslaUSB to the latest version 2 days ago. In my Model 3 with version 2019.28.3.1 I have only seen the warning about the USB stick being too slow though. @curiousgrge Exactly the same here. It didn't happen before I decided to update TeslaUSB. |
The setup script als runs "apt-get upgrade", so updates both the teslausb scripts and Raspbian. It would be interesting to see if starting from scratch with an older version of teslausb has the same problems (which could mean the problem is with Raspbian) or not (which could mean the problem is with the newer teslausb scripts) |
I will try starting from scratch today and let you know what my results are. |
I did a scratch install using an Etcher image and the old configuration file I had. The setup file shows as finished. I'm going to leave it on overnight and see what the results will be. Keep your eyes peeled for an edit to this post. |
There are several things that might be worth trying in order to diagnose this problem:
The following seems to work to install an older version of teslausb:
To prevent setup from updating all the Raspbian packages, add You can also combine the two approaches to get an old version of teslausb on an older version of Raspbian. |
I tried an older version of teslausb on my Pi0 and it was working perfectly. I think it might be useful to have a latest and stable branch with the default as stable. |
I tested 06152019 (latest release at this time) over the weekend with no issues. All I did was flash and restore my old config. I have a gut feeling this issue may have to do with an apt dist upgrade or a RPI firmware update. I feel like I might have done both myself in SSH. If flashing a new release to SD reverts both, then either one of the two could have caused issues. If one of the two does not revert on flashing from scratch, then whichever was reverted was likely was the culprit. |
I re-flashed with the latest on Saturday as well. No issues with too slow/not accessible errors all day today with plenty of sentry events.
Get Outlook for iOS<https://aka.ms/o0ukef>
…________________________________
From: raz4725 <[email protected]>
Sent: Sunday, September 8, 2019 4:04 PM
To: marcone/teslausb
Cc: raushel; Comment
Subject: Re: [marcone/teslausb] USB drive is not accessible by Dashcam (#207)
I tested 06152019 (latest release at this time) over the weekend with no issues. I have a gut feeling this issue may have to do with an apt dist upgrade or a RPI firmware update.
I feel like I might have done both myself in SSH. If flashing a new release to SD reverts both, then either one of the two could have caused issues. If one of the two does not revert on flashing from scratch, then whichever was revertes was likely was the culprit.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub<#207?email_source=notifications&email_token=ALWIUBYU23I4ZUPP6VLU4J3QIVSGPA5CNFSM4ISRQ3I2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD6FZLHY#issuecomment-529241503>, or mute the thread<https://github.com/notifications/unsubscribe-auth/ALWIUBZEO6PPVRXOZERIKYLQIVSGPANCNFSM4ISRQ3IQ>.
|
I installed the latest version (from scratch), which was about 3 days #86 (comment) . Yesterday, I ran into the same problem, see screenshot below |
I reinstalled from scratch 2 days ago and so far it is working as before, without issues. |
I've had similar problem after reinstalling from scratch. Seemed to work for a few days then I would occasionally get the message. It would also not delete a previous archive as it would download it again when I could get it working. So this time I reinstalled again and haven't quite tested it yet but here are a few things I noticed.: Favorites are retained somehow. @marcone Is there a simple method of mounting the music partition through Linux so I can copy my music back through the SD card reader rather than the slow USB port of the Raspberry Pi? It took me over 2.5hrs to copy music back through USB and much longer if through WiFi. edit: Just noticed the latest commit. Will this bugfix resolve this issue? I'm not using API. |
To access the "music partition" when the card is just plugged in to a card reader, you have to first mount the /backingfiles partition, then mount the music_disk.bin disk image. The latest commit fixes an issue introduced 2 days ago, so if you installed on Saturday or Sunday, you may want to run setup again. |
my selfupdate command returns "already up to date" but I updated Sunday |
selfupdate only updates the setup-teslausb script itself, and so "already up to date" only indicates that that script is already the latest version. |
yes, that did the trick, thank you. I'm looking at getting the Raspberry Pi 4, is this natively supported by this project? (I realize the last comment I saw you said you don't have one to test on) |
Not currently supported, and I don't have a way to test it, but some people are trying to get it to work: #240 |
I had the chance to do this today, and it fixed my problem above! |
Just want to provide more information about this error: I almost ran into this error every day in the past week. Mostly, I unplugged and replugged the board to the card, then the error was gone, and the board was working again. Except one time, rebooting wouldn't fix the problem, and I had to take the board back, then did "setup-teslausb selfupdate", and "setup-teslausb", which fixed the issue. |
Even though I can re-run the setup to fix the problem, my board seems never store sentry mode videos in "recent" folder, anymore. |
Sentry videos are stored in SavedClips, not RecentClips. Is that what you meant? |
Yes, I meant no video saved in "SavedClips". Also, I noticed there are many files (I don't remember the names at the moment, but they are not regular files, my guess is they are temporary files) saved at the root of the CAM drive |
Are those the "FSCK0001.REC" files? Those are files that fsck recovered. In some cases they're complete and playable files, it's just the file names are missing. |
Yes, exactly. |
Hi all. Im not using a Pi, but just plugging in a USB drive straight into de jack, and I am getting this same error. The only thread I have found on the net that shows this error is this one.. I´ve tried multiple drives and all give me the same problem, and have tried the same drives on a different tesla and it work correctly. Any idea what could be happening or how I can fix it? |
@dieb11 might be worth a call to the service center. Could be a problem with the port itself. |
After a few weeks the issue came back and I got the same message again. Since v10 has some Sentry Mode improvements, I went back to a traditional stick and that one hasn’t had any issue so far. |
Since V10 and a fresh install and tried multiple MicroSD cards, this issue is coming up. |
I have the same error message with my M3 (2019.32.12.2). (USB drive is not accessible by Dashcam) It's functionning with this version ? |
I've been lurking this thread, any fix so far? |
I was finally able to repeat this issue. Effectively, when hooking my pi back up to USB, it mounted the music portion on Mac OS, but not the cam partition. Log: diagnostics.txt The interesting tad-bit: So, TeslaUSB does not fix all types of problems automatically. Perhaps something we can improve in future builds. I could not get fsck to fix this error automatically. I had to first find the offset: Number Start End Size Type File system Flags (parted) q Then mount the file to loopback Attempt to fix via fsck And even attempt to delete the file by hand Even those steps did not correct the issue with not mounting the cam to usb |
I’m seeing this same issue and I am not using teslausb. I’m using a Samsung SD straight via USB to SD adapter. |
@garricn I'm seeing this issue the last few days with a Samsung SD as well. This seems not directly related to teslausb, although the issue occurred more often when I was using teslausb. |
Here is the output from
|
Well those I/O errors certainly don't look good. Looks like you have a bad card, and are possibly using a charge-only cable instead of a true USB cable. |
thanks @marcone. I will try a different cable (although it was working fine for quite a while) and, if that doesn't work, a different microsd card and reinstall everything. |
Update: turns out cable was fine. Reflashing with the latest image (same 64 gb microsd card) did the trick. Here is some of the latest dmesg output:
|
Did anyone else solve this problem or figure out a root cause? It just started happening to me. |
Running the latest marcone/teslausb release on a M3 running v9.0 (2019.32 9d0d19a). This is a fairly new update that I received this week.
Since the update to 2019.32, I keep getting a USB drive is not accessible by Dashcam error message. It says to Reformat the drive to a supported format.
When this happens, a red exclamation mark appears on the top right and the recording icon turns white with a small X. Unplugging and re-plugging fixes the issue, but it repeats after a few minutes of being plugged in.
Logs are attached.
diagnostics.txt
The text was updated successfully, but these errors were encountered: