Dashcam Viewer for Mac and Windows

[Chazz]

have you submitted any files?

Yes, back in early March. John said he would add it to his "job jar."

 

[Street Guardian USA]

Now the 2.x app is working well I'm sure adding more product compatibility will come next.

 

[traveler]

@Chazz I looked at your files back in March and found where the GPS data is embedded. Unfortunately the data was encoded in a format I hadn't seen before and I haven't had time to crack it. The best solution would be for customers to encourage DOD-Tec to share their data encoding formats with me. That would save a lot of time on my part.

On a different topic, I'm hearing that Dashcam Viewer 3 fixed the "black screen" issue for a number of people who like to record at resolutions > 1080p (For example: Viofo A119).

 

[mcaf123]

Just downloaded V3 and tried it on my Windows 10 machine with my SG DC cams. All I can say is wow! Seems so much slicker than before and PiP is an absolute godsend. Thanks for finally adding it!

The only issue I have is that sometimes the files aren't named exactly the same front and rear, with the seconds being slightly out by 1 or 2 and therefore the files don't sync up and PiP isn't available for such files. Please can you sort this out?
This is the only thing I've noticed in the 10 mins I've been playing with it....

@traveler any chance you could look into my issue with the file naming here ^

 

[Street Guardian USA]

@Travler has a SG9663DC so I’m sure he can take a closer look. Maybe share some example files too though.

 

[jokiin]

@Travler has a SG9663DC so I’m sure he can take a closer look. Maybe share some example files too though.

screenshot of the file view should do

 

[traveler]

@mcaf123 Sure, but let me ask a couple of questions to better understand the issue :

>The only issue I have is that sometimes the files aren't named exactly the same front and rear, with the seconds being slightly out by 1 or 2

1) Are the front and rear movies out-of-sync by 1 or 2 seconds from each other when you play them together, or are they in perfect sync despite the filenames being different?

2) [Perhaps @jokiin would know the answer:] Is the fact that the filenames are off by 1 or 2 seconds an issue with the dashcam itself (perhaps a clock setting would fix it), a problem with an early firmware version, or is it intended to work this way? Dashcam Viewer uses matching filenames to identify matching pairs of front/rear files so knowing the file naming scheme, and its variants, is important. I'm asking because if this file-naming issue is corrected with a firmware update then it doesn't make sense for me to workaround it.

3) Which firmware are you using?

4) Can you email me a file listing of your SD card that contains front/rear pairs so I can see the variants?

Thanks! - John
Website: http://dashcamviewer.com
Facebook: https://www.facebook.com/dashcamviewer

 

[jokiin]

need to see his screenshot so I'm clear what he is referring to with the file names

 

[mcaf123]

@mcaf123 Sure, but let me ask a couple of questions to better understand the issue :

>The only issue I have is that sometimes the files aren't named exactly the same front and rear, with the seconds being slightly out by 1 or 2

1) Are the front and rear movies out-of-sync by 1 or 2 seconds from each other when you play them together, or are they in perfect sync despite the filenames being different?

2) [Perhaps @jokiin would know the answer:] Is the fact that the filenames are off by 1 or 2 seconds an issue with the dashcam itself (perhaps a clock setting would fix it), a problem with an early firmware version, or is it intended to work this way? Dashcam Viewer uses matching filenames to identify matching pairs of front/rear files so knowing the file naming scheme, and its variants, is important. I'm asking because if this file-naming issue is corrected with a firmware update then it doesn't make sense for me to workaround it.

3) Which firmware are you using?

4) Can you email me a file listing of your SD card that contains front/rear pairs so I can see the variants?

Thanks! - John
Website: http://dashcamviewer.com
Facebook: https://www.facebook.com/dashcamviewer

1) Looking at it closely I wonder if this is actually a FW issue - if you look at the screenshots of the filename and timestamps on the video itself, both front and rear files show the time of recording starting at 08:40:03. However, the front cam has a filename of "084003", but the rear has a filename of "084004" despite the file actually starting at 08:40:03 like the front. I have done a spot check on some other affected files and this seems to be consistent (and I guess incorrect) behaviour.





2) I'll let Rick comment after seeing the file structure above and below....

3) FW = v1.26

4) Here is a screenshot of the file structure - file pairs highlighted in red are the affected files and the difference between the naming is highlighted in yellow

 

[jokiin]

I queried the engineers previously when the file naming convention was brought up and they said it was normal and expected

 

[DT MI]

@traveler - While you're looking into the idiosyncrasies of the SG9663DC file naming conventions here's another one.

Normally the DC will name the front camera file with the letter 'A' and the rear with the next higher sequential number and the letter 'B'. Occasionally the video file for the rear camera will be created first with the 'B' identifier followed by the front camera video with the 'A' identifier. See the attached - files 041A and 042B are the norm but the 043B/044A combination happens at times:



In the above scenario (043B/044A) Dashcam Viewer did not recognize the 043B rear camera file as being associated with the 044A front camera file.

 

[mcaf123]

I queried the engineers previously when the file naming convention was brought up and they said it was normal and expected

I remember you mentioning something like that last time a couple of us brought it up. However, can it really be normal to not have the filename and actual recording be one second out like I have shown above?

 

[jokiin]

it can't write the two files simultaneously, there is a delay as the data is written from memory to the card and at times that is going to fall either side of the same second

 

[mcaf123]

it can't write the two files simultaneously, there is a delay as the data is written from memory to the card and at times that is going to fall either side of the same second

OK. Perfectly logical explanation then
@traveler does that mean you can look into having DCV skirt around this and still pair the files up for viewing?

 

[DT MI]

it can't write the two files simultaneously, there is a delay as the data is written from memory to the card and at times that is going to fall either side of the same second

While that is a perfectly valid reason for the phenomenon an easy 'fix' would be save the date/time when the first (front) file is created and use it when creating the second (rear) file. Likely would entail only 2 lines of code in the firmware.

The more 'interesting' (and from a playback software perspective - problematic) issue is the occasional creation of the rear 'B' file before the front 'A' file.

 

[jokiin]

While that is a perfectly valid reason for the phenomenon an easy 'fix' would be save the date/time when the first (front) file is created and use it when creating the second (rear) file. Likely would entail only 2 lines of code in the firmware.

The more 'interesting' (and from a playback software perspective - problematic) issue is the occasional creation of the rear 'B' file before the front 'A' file.

nothing is ever two lines of code in the firmware (wish it was), eg; the OSD information is injected into the video 30 times per second, the GPS info is updated once per second, there's a lot of stuff going on for every frame of video, start playing with file naming and it gets messy fast

it's just something the player will need to handle, probably not two lines of code there either unfortunately but I don't see it as anything that can't be sorted

 

[DT MI]

nothing is ever two lines of code in the firmware (wish it was),...

OK, I was being a bit facetious but the issue could easily be rectified.

If file-name ends with 'A' then
save file-name to hold-file-name
else
move hold-file-name to file-name
change 'A' to 'B'
end-if;

Or (to save my claim of 2 lines of code):

If file-name ends with 'A' then save file-name to hold-file-name
else move hold-file-name to file-name change 'A' to 'B' end-if;

On a more serious note, the bigger problem from a playback perspective is the creation of the rear 'B' file before the front 'A' file. That would be a bit more difficult scenario for the playback S/W to reliably identify - especially S/W that's intended to handle files from multiple cameras/manufactures, the more exception processing the less stable the program and more difficult to implement changes.

 

[jokiin]

On a more serious note, the bigger problem from a playback perspective is the creation of the rear 'B' file before the front 'A' file. That would be a bit more difficult scenario for the playback S/W to reliably identify - especially S/W that's intended to handle files from multiple cameras/manufactures, the more exception processing the less stable the program and more difficult to implement changes.

I don't think the order they appear in is that relevant when they have such a clear identifier, front camera files are A, rear are B, that bit is consistent

 

[DT MI]

I don't think the order they appear in is that relevant when they have such a clear identifier, front camera files are A, rear are B, that bit is consistent

Well, at this point in time I know DashcamViewer (ver 3) does not recognize the relationship when 'B' comes before 'A'.

 

[jokiin]

it's probably just sorting by creation date