Zenfox T3 Triple channel dash cams free test invitation, limited quantity

EGS said:
I just reviewed some footage from a short drive to walmart yesterday and I have fount that it has only recorded the first 2 minutes on all 3 cameras an nothing else after that, meaning all 3 cameras did stop recording and no warning whatsoever. I think an audible warning is critical when the system fails to record entirely. High temperature was not a factor in this case as temperature was around 80F and vehicle was parked in a cool garage. Things are quite unpredictable at this point.
Click to expand...

Out of curiosity, did your camera experience the 2 day jump ahead? There is an audible warning. Today, myy camera was beeping when everything stopped recording. Dissimilar to what happens if ONLY the rear and interior camera fail. The beeping made me check the files where I discovered the naming conflict. I forget the exact timestamp (should have taken a screenshot on my phone before formatting card) but the last file was at X hour and minute 36 on 21 June. The Erroneous 21 June file started at X hour and minute 37. Preventing the camera from writing a new file.

I'm no expert here, but I do know computers. And naming conflict caused the camera to halt. If something else is going on aside from the temperature and loss of time, we need to pin it down, too.
 
Last edited:
Yes, however I never heard any beep warnings from my camera in the entire time, therefore I assumed the camera was recording just fine. My next step was to allow my sd card to fill up to let it loop for the first time and to see how it would respond once it was full. But this morning I started my vehicle to pull it out the garage and few minutes later I turned it off and noticed that the camera did faint again without the ending zenfox logo, and to me that meant that issues where present again, so I pulled the card for review. That is when I fount that there was only 2 minute recording of my last trip dated to 2020_0622 instead of 2020_0620 which was the correct date. Upon close inspection in the video recorded, the date stamped initiated with the two day ahead and as soon as the GPS data became available the date stamped in the image corrected itself. So there are good chances it is a firmware bug since there is an RTC battery in there for sure.

CORRECTION: It did record all the drive session... the very first recording was placed to the end of the list due the date difference. That is the reason I never heard the beep warning. Man! The drinks I had earlier for Father's Day are not helping :wacky:...

Screenshot (7).png
 
Last edited:
kuoh said:
I don't think an RTC battery should be necessary to fix this as the GPS knows the correct time, otherwise it wouldn't be able to calculate the speed properly. It is likely a bug in how it handles the GPS data, as the error is always 2 days ahead with the correct GMT time instead of local time.

KuoH
Click to expand...

And I presume this bug affected all of us, just some noticed and others did not. So it's a firmware / software issue and not a hardware one.
 
EGS said:
Yes, however I never heard any beep warnings from my camera in the entire time, therefore I assumed the camera was recording just fine. My next step was to allow my sd card to fill up to let it loop for the first time and to see how it would respond once it was full. But this morning I started my vehicle to pull it out the garage and few minutes later I turned it off and noticed that the camera did faint again without the ending zenfox logo, and to me that meant that issues where present again, so I pulled the card for review. That is when I fount that there was only 2 minute recording of my last trip dated to 2020_0622 instead of 2020_0620 which was the correct date. Upon close inspection in the video recorded, the date stamped initiated with the two day ahead and as soon as the GPS data became available the date stamped in the image corrected itself. So there are good chances it is a firmware bug since there is an RTC battery in there for sure.

CORRECTION: It did record all the drive session... the very first recording was placed to the end of the list due the date difference. That is the reason I never heard the beep warning. Man! The drinks I had earlier for Father's Day are not helping :wacky:...
Click to expand...

Just as I described. So the erroneous 21 June was recorded 2 days ago. If your card wasn't formatted, then those files remained. So then yesterday when the camera recorded on the ACTUAL 21 June, it halted upon running into a naming conflict. My Camera alerted me by basically beeping upon entering the car. I couldn't figure out what caused the halt, until I logged into the camera via Wifi, and inspected the saved files. What I saw was yesterday's 21 June clash with the 21 June files from two days ago. And yes, the arrangement of the files had me puzzled until it dawned on me the cause of the problem.

Meaning this issue is 100% firmware / software and unrelated to the RTC battery. If it were an RTC battery issue, then the issue would have plagued just me, and not everyone else. Clearing demonstrating a software related problem.
 
HonestReview said:
Just as I described. So the erroneous 21 June was recorded 2 days ago. If your card wasn't formatted, then those files remained. So then yesterday when the camera recorded on the ACTUAL 21 June, it halted upon running into a naming conflict. My Camera alerted me by basically beeping upon entering the car. I couldn't figure out what caused the halt, until I logged into the camera via Wifi, and inspected the saved files. What I saw was yesterday's 21 June clash with the 21 June files from two days ago. And yes, the arrangement of the files had me puzzled until it dawned on me the cause of the problem.

Meaning this issue is 100% firmware / software and unrelated to the RTC battery. If it were an RTC battery issue, then the issue would have plagued just me, and not everyone else. Clearing demonstrating a software related problem.
Click to expand...
I hope I don't cause more confusion after the already confusing last two postings I made. The card was actually formatted and started clean before my last trip (initially I thought I didn't). The picture shows all the recordings of the trip I made to the store yesterday (Jun 20) but the very first 2 minute clip from each camera (the start of the driving session) are placed it the end because the error on the date and time. So the camera never stoped recording but I know it still a huge issue...
 
EGS said:
I hope I don't cause more confusion after the already confusing last two postings I made. The card was actually formatted and started clean before my last trip (initially I thought I didn't). The picture shows all the recordings of the trip I made to the store yesterday (Jun 20) but the very first 2 minute clip from each camera (the start of the driving session) are placed it the end because the error on the date and time. So the camera never stoped recording but I know it still a huge issue...
Click to expand...

So in your case, the camera tacked on an extra 2 minutes to each file, as a result of the 2 day jump in time? Mine simply halted when it got to those files. No tacking on, simply the camera beeping, and a failure to record.
 
HonestReview said:
So in your case, the camera tacked on an extra 2 minutes to each file, as a result of the 2 day jump in time? Mine simply halted when it got to those files. No tacking on, simply the camera beeping, and a failure to record.
Click to expand...
No. The first recording segment is the one that got stamped with the wrong date and time. Therefore they where moved to the end of the list.
 
kuoh said:
I don't think an RTC battery should be necessary to fix this as the GPS knows the correct time, otherwise it wouldn't be able to calculate the speed properly. It is likely a bug in how it handles the GPS data, as the error is always 2 days ahead with the correct GMT time instead of local time.

KuoH
Click to expand...

There needs to be time-keeping involved so that the cam can function correctly until a GPS lock is achieved, and the time them coordinated. With the other cams I mentioned, there was apparently not enough energy in the supercaps alone to maintain timekeeping for very long, so those cams reset themselves to the base time in the programming in order to remain functional. Those other cams needed to have a RTC battery added to solve that issue. This is why I brought up the point, but the Zenfox does have an RTC cell so it is very unlikely that any part of the time-related issues are here. I'm just trying to consider all possibilities and eliminate what we can to leave us with only the true answer by itself 😉

And now that we can eliminate this possibility, your theory on the problem being with the GPS data-handling becomes more solid, and indeed is likely to be correct. So I am left to wonder whether it's in the GPS module or in the cam, and I can't see any way to determine that through beta-testing but Zenfox can get the engineers to check it out.

Phil
 
  • Like
Reactions: EGS
Yes it would be something new if zenfox set the default date as some date in the future, and in case of a RCT failure just as problematic as a default date in the past.
But i will agree with jokiin here, this back to the future jump are probably a firmware problem.

Probably quantum resonance in the flux capacitor not accounted for. 😊
 
It's either that or the pesky Gallifreyans have installed a randomizer into the time control console 😎

Phil
 
EGS said:
No. The first recording segment is the one that got stamped with the wrong date and time. Therefore they where moved to the end of the list.
Click to expand...

Ok. But then the question remains, did you format the card or did you let the erroneously dated segments remain? In my case, these segments remained (didn't think to format card), causing a conflict when the actual date arrived. Meaning the camera didn't know what to do so it stopped recording since two files couldn't occupy the same name.
 
SawMaster said:
There needs to be time-keeping involved so that the cam can function correctly until a GPS lock is achieved, and the time them coordinated. With the other cams I mentioned, there was apparently not enough energy in the supercaps alone to maintain timekeeping for very long, so those cams reset themselves to the base time in the programming in order to remain functional. Those other cams needed to have a RTC battery added to solve that issue. This is why I brought up the point, but the Zenfox does have an RTC cell so it is very unlikely that any part of the time-related issues are here. I'm just trying to consider all possibilities and eliminate what we can to leave us with only the true answer by itself 😉

And now that we can eliminate this possibility, your theory on the problem being with the GPS data-handling becomes more solid, and indeed is likely to be correct. So I am left to wonder whether it's in the GPS module or in the cam, and I can't see any way to determine that through beta-testing but Zenfox can get the engineers to check it out.

Phil
Click to expand...

This is definitely a firmware / software bug. We all suffered the same glitch, so the RTC battery had zero to do with the failure to keep time. Yet one more thing to add to the list of items needing corrected.
 
HonestReview said:
Ok. But then the question remains, did you format the card or did you let the erroneously dated segments remain? In my case, these segments remained (didn't think to format card), causing a conflict when the actual date arrived. Meaning the camera didn't know what to do so it stopped recording since two files couldn't occupy the same name.
Click to expand...
Card was formatted.
 
jokiin said:
date jumping forward will be a firmware bug
Click to expand...

Agreed. If everyone had the problem, as I pointed out earlier, this isn't a hardware issue. The RTC battery would only come into play if I were the only one who experienced time jump. So this glitch is just another one to add to the list of items needing corrected. Although, the biggest failure is still the overheating.
 
I'm about to go out this morning and I will formate it in the computer and in the camera again and see what happens again.
 
EGS said:
Card was formatted.
Click to expand...

Ok. So that's why you didn't experience the same naming conflict I did. Under normal operating conditions, the camera never has to worry about the same day occuring twice. Unfortunately, with whatever firmware bug exists, the camera ran into that very scenario when I didn't think to reformat my card.
 
kamkar1 said:
Yes it would be something new if zenfox set the default date as some date in the future, and in case of a RCT failure just as problematic as a default date in the past.
But i will agree with jokiin here, this back to the future jump are probably a firmware problem.

Probably quantum resonance in the flux capacitor not accounted for. 😊
Click to expand...

I believe this to be the most logical explanation: According to Dr. Emmett Brown in Back to the Future Part II, whenever a time traveler alters key events occurring in the past, they effectively bring an alternate timeline into existence at their point-of-entry, and their original timeline is erased, even though its events are not forgotten by the time-traveler.

The camera ran into two different time lines, where the altered past became the new future, so the camera simply didn't record the "missing video" because the current ones with the same name were that "new future".
 
Here is a video showing what happened to the date and time.
NOTICE video blurred and shortened intentionally.
Date and time got corrected in the on-screen watermark stamp but the filename cannot be changed or corrected itself once it is created.


Screenshot (7).png
 
Last edited:
*waiting patiently on firmware update*
 
You must log in or register to reply here.
Back
Top