BlackVue Downloader [Latest http://www.gizmocoding.com]

45701

Version 3.0.0.0

Changelog:
- Add TabControl for current details of connected Camera​
MB/s, MB downloaded, last connected details etc.​
(Click the little down arrow to open up)​

45702

- Include image of current models​
- Add Rear Camera Live View if supported Camera Model​
- Fix for overfull log - deleted very 6 hours or so​
- Parse Dashcam firmware version, model No, Language & Display.​
- Parse ini for future use and display if needed​
- Add option to set a maximum used Folder Size, deletes oldest files up to this size​
if set very small will download, delete and download again if not careful​
Would suggest is set to multiple of days data​
- Add Delete Now button if Debug Logging checked​
- Auto Scroll to bottom of Info window as info arrives​
- Add Run at Windows Startup Toggle Checkbox.​


Cheers

Glenn
 

Attachments

  • BlackVueDownloader.3.0.0.0.64bit.zip
    733.2 KB · Views: 50
  • BlackVueDownloader.32bit.v3.0.0.0.zip
    733.3 KB · Views: 16
Glenn, I'm having an issue that followed me from your app's version 2.9.9 to 3.0.0.0. While the dashcam is definitely connected (see attached Pingplotter graph) to the Wi-Fi access point, BlackVueDownloader starts throwing a bunch of these messages in the log:

2019-05-21 17:03:43,534 DEBUG [0] [1] App Caught ExceptionSystem.AggregateException: One or more errors occurred. ---> Flurl.Http.FlurlHttpTimeoutException: Call timed out: GET http://192.168.1.77/Config/version.bin ---> System.Threading.Tasks.TaskCanceledException: A task was canceled.

Sometimes things recover without my intervention, other times I have to exit and restart BlackVueDownloader.

How would I go about troubleshooting the issue? If uploading one of the log files to you via PM would help, I'm happy to do so!

DashcamConnectivity.png
 
Glenn, I'm having an issue that followed me from your app's version 2.9.9 to 3.0.0.0. While the dashcam is definitely connected (see attached Pingplotter graph) to the Wi-Fi access point, BlackVueDownloader starts throwing a bunch of these messages in the log:

2019-05-21 17:03:43,534 DEBUG [0] [1] App Caught ExceptionSystem.AggregateException: One or more errors occurred. ---> Flurl.Http.FlurlHttpTimeoutException: Call timed out: GET http://192.168.1.77/Config/version.bin ---> System.Threading.Tasks.TaskCanceledException: A task was canceled.

Sometimes things recover without my intervention, other times I have to exit and restart BlackVueDownloader.

How would I go about troubleshooting the issue? If uploading one of the log files to you via PM would help, I'm happy to do so!

View attachment 46377

Hi

Sorry missed this - must check notifications.

Thanks for the detailed - info - yes a log would certainly help.

Q:
What camera model are you connecting to?
At a guess it seems that version.bin doesn’t exist - can you connect to:
192.168.1.77/Config/version.bin ?
(the error is caught and shouldn’t cause other issues - just debug logging stuff you are seeing)

Edit:
Looking at the code, just indicating that can’t connect to Config.bin but would seem something else is amiss. The exception is all caught and only logged because debug logging is on. That error message in itself shouldn’t cause any issues.

May be something else going on, a debug log may help, or may be more general connection issue,

If could post a debug log indicating when issue occurs would - will have a detailed look.

(although can say version 3 has been running constantly on my windows10 computer for 59 days now without a single hiccup!)

Glenn

Sent from my iPad using Tapatalk
 
Last edited:
@GlennNZ - where should I upload a *.zip/*.7z of a few of my debug logs? Here, or as a PM?
 
This just got weirder - previously the issue was just that BVD just didn't "see" my 750S on the network when it was.

A new issue, that I just now discovered, is that BVD does it's periodic check, sees the camera, but thinks a download is still in progress, but there was zero traffic to/from the 750S (except for my Pingplotter ICMP).

2019-06-01 11:47:18,607 DEBUG [0] [1] App Filtered Item: 20190530_141005
2019-06-01 11:47:18,607 DEBUG [0] [1] App Filtered Item: 20190530_141005
2019-06-01 11:47:18,608 DEBUG [0] [1] App Connected to BlackVue IP Address:172.16.0.77
2019-06-01 11:47:18,608 DEBUG [0] [1] App CheckandDownload: Connected Okay to IP:172.16.0.77 Checking Download File Thread.
2019-06-01 11:47:18,609 INFO [0] [1] App DashCam 1 Thread is still Downloading from DashCam, do nothing this time...


[This is where I went to see how caught-up my files were, saw that the last one had a timestamp of around midnight. Curious to see how fast/slow the network transfer was, I used Windows10's RESMON.EXE and discovered there was absolutely zero traffic. So I exited and restarted BVD.

2019-06-01 11:55:29,690 DEBUG [0] [1] App Exit selected.
2019-06-01 11:55:29,748 DEBUG [0] [1] App App OnExit Called
2019-06-01 11:55:29,750 DEBUG [0] [1] App -- Setting Cancel token on all DashCams --
2019-06-01 11:55:32,753 DEBUG [0] [1] App Checking File:S:\Blackvue\Dashcam\CamFiles\JETTA2016_FOOTAGE\_tmp\20190531_053223_PF.mp4T221FAID3S.downloadertemp
2019-06-01 11:55:32,754 INFO [0] [1] App Deleting File:S:\Blackvue\Dashcam\CamFiles\JETTA2016_FOOTAGE\_tmp\20190531_053223_PF.mp4T221FAID3S.downloadertemp
2019-06-01 11:55:32,756 INFO [0] [1] App Error Deleting File(s)
2019-06-01 11:55:32,764 DEBUG [0] [1] App Exception:System.IO.IOException: The process cannot access the file 'S:\Blackvue\Dashcam\CamFiles\JETTA2016_FOOTAGE\_tmp\20190531_053223_PF.mp4T221FAID3S.downloadertemp' because it is being used by another process.
at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)
at System.IO.FileInfo.Delete()
at BlackVueServiceApp.App.delete_tmp_files()
 
Thanks! I sent you a PM with a link to download the *.zip file
 
Thanks! I sent you a PM with a link to download the *.zip file

Ok - not quite a PM - but found!

Ok - have reviewed hours of logs and nothing that would bring down app appears to be happening. It all appears pretty expected.

Essentially seems that is downloading fine for about 5 hours, then disconnects, you restart the app and it starts again.

Basically seems to be occasionally getting no reply from camera when checking if cameras connecting when currently downloading (after 4-5 hours of downloading). This then causes app to register that camera as disconnected, cancel the download, delete temp files (fails occasionally depending on whether releases file in time) and will recheck at time interval. After downloading for that long, I’m not surprised the camera occasionally fails a connection check.

Should reconnect and start again despite this.

Could increase check time up from 10 minutes to longer, as currently when downloading still runs the ‘is connected’ check (and does for each camera). If this timeouts, which happened once in this log after 5 hours, disconnects camera and stops downloading.

When I’m back can have a look at code and see if can streamline this area, but probably is one of those aspects of supporting multiple cameras that checks still need to run even if downloading.

Glenn





Sent from my iPad using Tapatalk
 
Thanks for sifting through those logs while you're away!
 
Thanks for sifting through those logs while you're away!

No problem!

Will have a look at the code checks and see if can remove ‘connection check’ if currently downloading - which makes sense as a double check, but it seems it leads to occasional timeouts/then disconnection/reconnection in your case.

Meanwhile could increase the check time to 20-30 minutes or so - x2x3 times less likely to happen in that case.

Re: time of transfer - from earlier post - I’ve tested against powershell and the BVD with the current buffers was twice as fast. Powershell looks fast because of the constant update, which is why I added in the speed checks to make sure I was right. Welcome to check times and can look - it is possible that different buffer sizes suit different situation. Obviously probably a lot of things that go into that thought - from camera/age/model to wifi connection speed etc.

Glenn




Sent from my iPad using Tapatalk
 
I added both the BVD executable and the \Record path as exclusions in my anti-virus which seemed to have rectified the throughput issue. [which is why I deleted that previous post, so as not to muddy things for future readers]

One cool thing to note: I accidentally learned that the camera will support two simultaneous download streams - I mistakenly kicked off the powershell script while BVD was already running, and it started downloading an Event file. Not sure there's any value in that as each of the transfer rates are then halved.

Which leads to a suggestion for a wish-list feature: let us pick which types of files to prioritize, e.g. Manual, Events, then Parking, then Normal.
 
I am a software engineer and was guided here by Blackvues support staff. I know there is no reason why they cannot easily open up the system to at least allow a file system over a PC connected via WIFI. In fact I reckon they have safeguards in there to stop it. Very dissapointed. I just want to come home, go inside, fire up the PC. WIFI to the cars cameras and get the footage of all the idiots on the road for the day and make YouTubes to make fun of them online. Trying to pull the SD cards from two cameras every single day just sucks and no way am I wasting all the time pulling it through the so called cloud at a massive expense from my cars wifi. Also pulling all the 4k video down to a damn phone is useless. Why oh why. we shouldn't have to go through all this trouble when they have the API already available. The simple fact they are doing it to the phone means it can be done to the PC very easily should they choose to actually be helpful..
 
I am a software engineer and was guided here by Blackvues support staff. I know there is no reason why they cannot easily open up the system to at least allow a file system over a PC connected via WIFI. In fact I reckon they have safeguards in there to stop it. Very dissapointed. I just want to come home, go inside, fire up the PC. WIFI to the cars cameras and get the footage of all the idiots on the road for the day and make YouTubes to make fun of them online. Trying to pull the SD cards from two cameras every single day just sucks and no way am I wasting all the time pulling it through the so called cloud at a massive expense from my cars wifi. Also pulling all the 4k video down to a damn phone is useless. Why oh why. we shouldn't have to go through all this trouble when they have the API already available. The simple fact they are doing it to the phone means it can be done to the PC very easily should they choose to actually be helpful..

Blackvue Downloader obviously will do all this.

There are a few obvious problem with having a file system on the camera - which one? Which network protocol to support, user access, etc.etc.

The more practical issue is even with a file system, the time to copy a days worth of photos is likely to take hours. To copy and paste 100s of files which will take an hours to transfer via file explorer is likely to be a problem. Clearly a better solution would be a background program to copy missing files etc.etc.

So I would argue even if Cameras had a supported network file system something like Blackvue Downloader would be a better solution regardless.

Glenn




Sent from my iPad using Tapatalk
 
In fact I reckon they have safeguards in there to stop it. Very dissapointed.
My take.. Blackview wants everyone to use the cloud.. an extra source of revenue for them.... and, an opportunity for them to monitor what the folk are recording.
 
Blackvue Downloader obviously will do all this.

There are a few obvious problem with having a file system on the camera - which one? Which network protocol to support, user access, etc.etc.

The more practical issue is even with a file system, the time to copy a days worth of photos is likely to take hours. To copy and paste 100s of files which will take an hours to transfer via file explorer is likely to be a problem. Clearly a better solution would be a background program to copy missing files etc.etc.

So I would argue even if Cameras had a supported network file system something like Blackvue Downloader would be a better solution regardless.

Glenn




Sent from my iPad using Tapatalk

I'm not bagging Blackvue Downloader I think that is brilliant from what I have read and thats not much I haven't had a chance to look yet. You have no argument from me thats a great idea. I will have to check the software out it sounds great. I will have to go look rather than bore you with questions that may be obvioulsy answered to me. I'd pay good money for a program like this thats for sure. I don't know why they don't have a PC interface like they do the phone. I wonder if you ran a PC emulator for a phone and ran their software on that if that would work once WIFI'ed in to the camera.
 
Has anyone updated to the latest firmware on the 750s-2ch and confirmed this is still working? Thanks in advance!
 
@jggarceron my 750S-2CH is at firmware version 1.016 and Blackvue Downloader successfully connects and downloads.

Like other 750* users, I have an issue where the camera isn't reliably connecting to the/a "garage AP" when I pull into the driveway; if I'm paying attention, I'll toggle Wi-Fi via the button and that usually gets it connected. On rare occasions I've had to power-cycle the fickle thing.
 
@jggaceron - whoops, I didn't see we're now at 1.017, soooo, thanks for the heads-up! I'll not updating the firmware until I hear there aren't any problems - I like this downloader too much!
 
Thanks for the replies! I decided to give it a shot anyways. I am now on 1.017 and the so far so good. My dashcam is connected to my home WiFi and my dashcam videos are downloading as expected. I will reply back if I run into any problems in the next few days.
 
Back
Top