Bizzare FTP issue with IP8M-T2499EW (not file deleting bug)

SRV

n3wb
Joined
Jul 3, 2017
Messages
7
Reaction score
3
First off, its not the FTP file deleting bug when the camera reboots thats already been talked about.

I got THREE of the IP8M-T2499EW cameras with the 2.8mm lens about a month ago. They came with V2.622R190415 firmware so I upgraded to latest V2.622R191024 firmware and that went fine. The cameras are working well and are set to upload the video to a local PC running Filezilla (0.9.53beta if that matters) when a video detection event occurs. This FTP upload is working fine for these 3 cameras, no problems at all. The FTP upload process creates a folder for the camera Device Name (Setup>System>General>Device Name) and then sub folders for each day with a format of YYYY-MM-DD. Within each of those folders it makes a sub folder named 001 and within that sub folder another sub folder named dav. Now in that dav folder, it creates a sub folder for each hour and finally in each of those hourly folders the MP4 video files are stored based on the hour the video occurred. This is all done between with camera and Filezilla automatically, no user intervention is required. I am 100% happy with how this is working.

So the complete path name to a video file would be
e:\camera videos\CAM01\2020-04-14\001\dav\13\xxxxxxyyyyyzzzzz.mp4

Now the bizarre part. I decided to buy another IP8M-T2499EW camera with the 4.0mm lens. It came with the latest V2.622R191024 firmware already installed. The camera has been setup to be identical to the others (I triple checked everything) and it works normally except for the FTP. The videos are being uploaded to FTP but the file structure is now different only for this camera. Under each YYYY-MM-DD folder it now makes a sub folder named video_001. It then places all the mp4 videos of that day in that one folder. There can be 200-500 videos there in that one folder at the end of the day. It no longer creates a sub folder for each hour like the older cameras did, which kept the number of files in each folder to a more manageable number of 10-30. This is the same model camera, running the same firmware, uploading to the same FTP server yet the folder and file organization is different. BIZARRE !!!!

So for only this new camera the complete path to a video file would be
e:\camera videos\CAM04\2020-04-14\video_001\xxxxxxyyyyyzzzzz.mp4

I have rebooted the 4.0mm camera numerous times, no change. I have performed a factory reset from the GIU and then reconfigured the camera, no change. I have deleted the folder from Filezilla so after a camera reboot it has to create an new folder with the camera Device Name. This one camera insists on still doing the FTP folder structure this bizarre different way.

Anyone ever seen this and know how to fix this?

I know Blue Iris is far superior to FTP but like I said, 3 of these IP2M-T2499EW cameras work one way with FTP (and I like that way just fine) but 1 camera behaves differently with FTP for no reason that is obvious (like a user config error). Totally bizarre!
 

TonyR

IPCT Contributor
Joined
Jul 15, 2014
Messages
16,457
Reaction score
38,173
Location
Alabama
I wonder what would happen if you backed up the config file from a "good" cam and then restored that to the "bad" cam?
Of course, I'd unplug the "good" cam from the LAN before I restored that file to the "bad" cam so there won't be 2 cams with the same IP address.
 

SRV

n3wb
Joined
Jul 3, 2017
Messages
7
Reaction score
3
I tried exporting the config of a good camera and then importing it to the bad camera but it said "Operate Failed" so that didn't work. That part was strange. BTW, all the cameras are set to get their IP address from a DHCP Server and I have my router set to have static IP addresses for the cameras based on their MAC address, so there won't be IP address conflicts. There is a newer firmware available V2.622 R200320 and I tried that too, same problem. Did a Factory Restore from the web interface, reconfigured the camera all over again, got the same problem. This one has me baffled.
 
Last edited:

SRV

n3wb
Joined
Jul 3, 2017
Messages
7
Reaction score
3
I've been looking at the Filezilla log. Here's what I see:

The camera IP address is 192.168.0.32
The camera name is Tom_Brady
The FTP Username is FOOTBALL

Here what happens when the camera starts up:
1. The camera tells the FTP to MKD Tom_Brady (make a directory named Tom_Brady)
2. The camera tells the FTP to STOR DVRWorkDirector (transfers a file named DVRWorkDirectory) in to the Tom_Brady folder.
3. The camera tells the FTP to MKD 2020-04-16 (make a directory named 2020-04-16 in the Tom_Brady directory)
4. The camera tells the FTP to MKD video_001 (make a directory named video_001 in the 2020-04-16 directory).
5. The camera tells the FTP to STOR xxxxyyyyyzzzzz.mp4 and the mp4 file gets sent over.

Clearly the camera is telling the FTP to make the folder structure this new way so of course the FTP does it. So the problem is with the camera itself. The camera is stuck in this mode where it will only make a video_001 folder in the YYY-MM-DD folder when it should be making a 001 folder then a dav folder then a hour folder.

Now, here's more of the story. I originally had a 2.8mm lens T2499EW camera in one location and that camera was configured to have a Device Name of Tom_Brady. It was working correctly on FTP and had uploaded about 4 days of videos with the correct 001/dav/ folder and had the correct hourly sub folders. That means it had already sent its DVRWorkDirecctory file over to the Tom_Brady folder on the FTP. I then removed that camera and put the 4.0mm lens camera in its place. I configured its Device Name to be the same Tom_Brady. That's when the trouble started, the new camera seems to have been messed up when it saw the original DVRWorkDirectory file from the original camera.

What is this DVRWorkDirectory file anyway? What does it do? If I delete it from the FTP folder where the FTP saves the files, the camera puts a new copy in there, so the file must reside in the camera. If a new camera tries to read a DVRWorkDirectory file from another camera, will that mess up the new camera?

I used Hex Editor Neo to look at whats in the DVRWorkDirectory file. Although it is 4K bytes in size, it only contains 53 bytes of data, the rest are zeros. The first 18 bytes are ASCII for the serial number of the camera. The remaining 35 bytes of data are hex values except the last 6 bytes which is ASCII for Remote. That leaves just 29 bytes for data that might be some kind of configuration data. Comparing this file from 2 good cameras shows that besides the different serial number, only 7 bytes of data change, and the first 2 and last two are always the same, so really only 5 bytes change. Now comparing this file from a bad camera to this file from a good camera, besides the serial number, only those same 5 bytes change so the bad camera file is not profoundly different than a good camera file.

Blue Iris is beginning to look better and better to me every day. Sad because FileZilla is doing a good job for the 2.8mm camera but not the 4.0mm camera. I don't dare take the risk of messing with one of my good cameras, since once it gets messed up there seems to be no way so far to get it back to the original working order. So far I would say its an Amcrest firmware/software bug.
 
Last edited:
Top