BlackVue Sync - A new portable, hands-off, automatic recording downloader for NAS or Docker

Thanks. I looked at my historical performance stats, and it's _possible_ that I'm seeing load spikes too. My NAS is quite beefy, so that would interesting. I'll do some more tests in the coming days.

If I interpret your screenshots correctly, one thing that may be making your performance issues more noticeable is that your baseline load is already pretty high (3-4), possibly due to your surveillance station software. I'd be curious to know if you saw the same level of performance drop without that software capturing.

Thanks again.
 
Will the docker continue to prune older files even if the camera is not connected to the network?
 
@blazn420 : Yes, recordings outside of the retention period are removed at startup, before contacting the dashcam. Part of the reason is to make room for newer recordings.

@Op911 :
I ran some tests on my NAS, and my load was negligible. Something like 0.2.

I find it interesting that wget used half the CPU than Python's urlretrieve(), so I'll run some more tests.

But I have to reiterate that your system is already under load, so I would invite you to try again on a lower load (likely by suspending your video capture) and to report the results. Also I found mentions of high CPU use and lockups in smbd on Synology, but I couldn't say whether they apply to your system or not.

Another test would be to try the raw script instead of docker. I'll appreciate any information you may be able to provide.
 
Hi there
You were right about the system being under load; I ended up suspending the video capture (or more specifically, the software motion detection) and did find the system became more responsive. Still hanging, but this time not indefinitely, but rather for 10-20 seconds or so. I found still that accessing the blackvue directory was far more CPU intensive than accessing any other directory on the NAS so I wonder if it's due to the sheer # of files in that directory somehow being overwhelming.

I haven't had time lately unfortunately to document CPU load while blackvue sync is running vs when it is not as the inlaws were visiting this easter weekend and I have some projects due, but when I can I would be happy to run any tests you ask me to. I will say I'm not quite sure I'm savvy enough to quickly figure out how to run the raw script on the synology instead of via Docker, except with a lot of spare time. I'm really just glad you made a docker image to make installing it so easy to begin with!

At the moment it works well enough for me and since it's gotten past the first "binge" of downloading an entire 64 gb card over the span of a few days, the share hanging hasn't been too much of an issue.
 
Thanks, really appreciate the update. I have some tests I want to run with different code, but it may come to make no difference.

Also interesting feedback about the docker image being more accessible than the plain script. I wouldn't have guessed. Cool.
 
So.... update....
It turns out it was all a problem with the Synology NAS. There was some kind of weird bug that was brewing, and it eventually got to the point where I couldn't access any shares at all due to slowdowns. After a little time going back and forth with Synology tech support we ended up resetting the NAS and reinstalling its OS.
Following that, all problems have disappeared, and now reading the directory tree and accessing contents is reasonably fast even when blackvue sync is working in the background.
So sorry to have implied that the problem was with BlackvueSync - it turns out the problem was cropping up and developing around the same time I tried Blackvuesync, but may have been unrelated.
Still don't know exactly what the problem was... it's just gone now that the NAS's OS has been reinstalled.
 
No worries, and again I really appreciate the follow-up. (y)
 
New release, 1.6:
  • Logs file/recording download speed to help troubleshoot unreliable/slow Wi-Fi setups.
  • Fixed a spurious error log during the first run after midnight.
  • Does a better job at cleaning up temp files from interrupted downloads.
  • Better handling of network errors while reading the file list.
 
I noticed on my WD PR4100 that files are not being pruned, any ideas?
 
I noticed on my WD PR4100 that files are not being pruned, any ideas?

I'll need a bit more info. What is your invocation like for instance?
 
I’m afraid I’m a novice with dockers. Invocation?


Sent from my iPhone using Tapatalk
 
I’m afraid I’m a novice with dockers. Invocation?


Sent from my iPhone using Tapatalk

Sorry for not being clearer; I mean how you're exactly invoking the docker container, all the options/parameters you're passing, etc.
 
Sorry for not being clearer; I mean how you're exactly invoking the docker container, all the options/parameters you're passing, etc.

On your docker page the section that uses “docker run -d”. I used those settings.


Sent from my iPhone using Tapatalk
 
On your docker page the section that uses “docker run -d”. I used those settings.


Sent from my iPhone using Tapatalk

The exact command pls. :) I need to give you a modified version that produces verbose logs to the console.
 
docker run -d --restart=always -v /shares/VIDEO/DASHCAM:/recordings -e PUID=500 -e PGID=1000 -e TZ="America/New_York" -e KEEP=2w -e PRIORITY=type --name=blackvuesync acolomba/blackvuesync
 
docker run -d --restart=always -v /shares/VIDEO/DASHCAM:/recordings -e PUID=500 -e PGID=1000 -e TZ="America/New_York" -e KEEP=2w -e PRIORITY=type --name=blackvuesync acolomba/blackvuesync

Great, thank you. Could you run: these commands

# stops the container
docker stop blackvuesync

removes the container
docker rm blackvuesync

# runs once w/ logs to the console. you can also redirect them to your share by appending "> /shares/VIDEO/DASHCAM/bvs.txt"

docker run -it --rm -v /shares/VIDEO/DASHCAM:/recordings -e VERBOSE=1 -e RUN_ONCE=1 -e PUID=500 -e PGID=1000 -e TZ="America/New_York" -e KEEP=2w -e PRIORITY=type --name=blackvuesync acolomba/blackvuesync

And could you PM me the log file.
 
should i add the address option in?
 
Great script and have got it working with minimal effort on my Mac. I will attempt to set it up on my raspberry pi in the coming days just to see how long it takes to copy files. So far its pretty quick! Very impressed. Once the initial backup is done I don't think it will take that long everyday to download. I do have a feature request. I have my dash cam on a 433mhz switch and would be impressive that once the script has finish that it sends a command to power down the camera. This can be done buy sending a simple web address json command. Where would the best place to put this in the script? Many Thanks
 
@Simon_rb Always good to hear success stories, thank you.

As to the shutdown, I'm hesitant to tack on very specialized behavior. It's also a bit tricky to do "the right thing" because the dash cam Wi-Fi connection can't be assumed to be stable. You wouldn't want to shut down the dashcam after it downloaded only half the files.

So my thinking is that you'd want to download recordings with "--priority type", and turn the dashcam off only once it has downloaded at least all driving/manual(/event?) recordings.

If that's the case, and assuming you're a programmer, I think the best spot would be the last loop in the sync() function. You'd add each downloaded recording to a downloaded_recordings list. Then you'd catch and rethrow exceptions around that last for loop, and in a finally clause you'd compare the two lists, and if current_dashcam_recordings minus downloaded_recordings only has parking (and event?) recordings, it would be safe to trigger your shutdown code.

Btw, I'd be curious to know how well a Pi works out in practice. I'm waiting for a Pi 4 which I'm sure would do fine, but I'm not sure about older models.
 
... I have my dash cam on a 433mhz switch and would be impressive that once the script has finish that it sends a command to power down the camera. This can be done buy sending a simple web address json command. ...
This piqued my interest. You have knowledge of a JSON command that the BV cameras support to shut themselves off? Can you share how that works? I'm aware of all the semi-documented HTTP commands to get files, but this capability is new and interesting to me.

Brad.
 
Back
Top