No relevant resource is found in the selected language.

This site uses cookies. By continuing to browse the site you are agreeing to our use of cookies. Read our privacy policy>Search

Reminder

To have a better experience, please upgrade your IE browser.

upgrade

All the cameras corresponding to one IVS MU stop r**ding at the same time.

Publication Date:  2019-07-30 Views:  133 Downloads:  0

Issue Description

From the video r**d searching result, we find that many cameras stop r**rding at the same time and never start again.

Alarm Information

None

Handling Process


We must manually delete all the residual files, otherwise the problem will recur.
Operation

1. Check if there is residual index information in the database. If yes, delete it. The operation is described detailedly below by example.
Note
Before operating in the database, must backup up the database. The backup method is: right click the database name and select the backup database. If there is any database operation failure, we can recover it by the backup file.
i. Query the index information for camera “029001000010101” and order the result by **ing start time.
select * from tbl_**_data t where t.camera_code = ‘029001000010101’ order by t.start_time
ii. Query the index information **ed before a time point for camera “029001000010101” and order the result by **ing start time.
select * from tbl_**_data t where t.camera_code = ‘029001000010101’ and t.start_time < ‘20121001000000’ order by t.start_time
iii. Delete the index information **ed before a time point for camera “029001000010101”
delete from tbl_**_data t where t.camera_code = ‘029001000010101’ and t.start_time < ‘20121001000000’
iv. Delete the index information before a time point for all cameras
delete from tbl_**_data t where t.start_time < ‘20121001000000’
v. Query all the index information stored on one MU
select * from tbl_**_data t where t.mru_code = ‘00000001106020000002’
2. Check if there is residual index file in the index file directory. If yes, delete it. The operation is described detailedly below by example.
Note: All the index files for one camera will be stored in the same directory, and further kept in sub-folders named by time. This directory is configured by the “**IndexPath” field in the ivs_mru_**.conf file, which is stored in the /home/ivsmu/mru/conf directory. For example, most of the case, this field is configured as “**IndexPath=/mrumnt/**IndexFile”
i. Query the index files for camera 029001000010101
find/mrumnt/**IndexFile/029001000010101 –name *.idx
ii. Query the index files generated in Sep 2012
find /mrumnt/**IndexFile/ –name 201209* -type d
iii. Delete all the index files generated in Sep 2012 (be careful, this operation is not reversible)
find /mrumnt/**IndexFile/ –name 201209* -type d –exec rm –rf {} \;
3. Check if there is residual ** file on the disk. If yes, delete it. The operation is described detailedly below by example.
Note: The ** files will be stored on different luns and different Raid groups. The directory on each lun for one camera will be named by its device id and further named the sub-folders by time.
i. Query the ** files for camera 029001000010101
find /mrumnt –name 029001000010101 –type d
ii. Query the ** files generated in Sep 2012
find /mrumnt –name 201209* -type d
iii. Delete all the ** files generated in Sep 2012 (be careful, this operation is not reversible)
find /mrumnt –name 201209* -type d –exec rm –rf {} \;


 


Root Cause


1. By analysis, we notice that all the stopped cameras belong to the same MU and all the cameras corresponding to this Mu have stopped video **ing.
2. Check if the ivs_mru_** process runs normally, the result is yes. Then tried to resolve the problem by reboot the server or mu service, both failed.
3. Checking the platform **ing plan for these cameras, found all the plan have changed from all-day **ing to stop. Manually start it again, the **ing can be recovered.
4. Keep on to find the root cause for this problem by reading the MRU log files, found many abnormal information, as below.
2012-11-20 01:58:56.154880 [ERR] [0x79a28ba0] | (DeleteManager.cpp:1040)  Delete ** file failed. Index file path=/mnt/**_indexfile/000000000430104/20120517/20120517185150_20120517185331_P000.idx
2012-11-20 01:58:56.166343 [WAR] [0x79a28ba0] | (DeleteManager.cpp:1074)  No file can be delete, so stop **.
2012-11-20 01:58:56.166352 [WAR] [0x79a28ba0] | (FileEgress.cpp:481)  Camera=000000000430104 over ride disk fail, Full Policy=1.
2012-11-20 01:58:56.166370 [WAR] [0x79a28ba0] | (FileEgress.cpp:1454)  Camera=000000000430104 override disk fail, so stop **.
This information tells us the service encounters failure when trying to delete the ** files stored from May to Jul, when the system is being deployed and commissioning. During that period, many inconsistent index files, ** files and database index appears, which leads to the failure of deleting old files when execute the “Overflow policy” and further leads to ** stop.


Suggestions

During the system commissioning period, due to some abnormal operation, there will always have some inconsistent index files, ** files or database index information. After commissioning, must remember to delete them.

END