We faced this same issue (amongst numerous other bugs) some months ago. Due to the total lack of support by the manufacturer we had to troubleshoot this on our own.
The first thing that someone finds out is that the overall system behaviour only provides inconsistent information about the specific problem that you are trying to identify. The bigger the system, the more inconsistency you get. What we did is that we tried to design a plan in order to detect consistent information on events leading, causing or that may be related to the the loss of video.
Is this happening on specific devices? Is it periodic on specific devices? What is the minimum and the maximum video loss window? Can you catch this live and figure out whether manual operations (be them on the system itself or the network infrastructure) might restart the recording?
In our case we hired an IT company that deployed network monitoring tools along with snmt traps on all video sources, NVRs, workstations, servers, etc. For a certain time period where there were quite a few video recording loss events, we didn't manage to identify any network issues - bear also in mind that we are always using dedicated network for surveillance which are built after the manufacturer's recommended hardware (which is never cheap).
Unfortunately, although there were not network related issues, there were tons of system related issues like device disconnections, inability of client - server connections and more that we never actually managed to identify in greater detail. Our tries to mine consistent data gave as a very important clue. We figured out that there was a certain maximum time window of video recording lost and not a single second more.
As John is mentioning finding gaps is really hard. Indeed we never got any alert of camera disconnection that would trigger the loss of video recording.
Further investigation lead to the discovery (the manufacturer failed or didn't want to let us know that such a service was present) that the VMS itself was running a specific integrity check service periodically (exactly the aforementioned time window). During this check, any parts of the system found not to function as expected, were forced back to the "expected" operation. This affected the recording as well and ended any video recording lost. So, every T minutes this service was run automatically. Any video recording loss happening within this period would last a maximum of T minutes to a minimum of 1 second (should it happen at T-1second). The cause of the problem was identified by the manufacturer as a bug that was never actually solved - just worked around with unacceptable short term solutions leading to promises that were never fulfilled. On the contrary those workarounds lead to even more related (or even non-relate) problems.
To me, the key is consistency, through which you can figure out a pattern that will show you the general cause of the problem. From that point you can easier figure out your next steps since you will not anymore have to find a needle in the hay stack.
It took us about a month to install the system and almost 6 months to idetify the problem....
Should the problem be identified on the same kind of system through a personal message, i would be more than happy to assist any way i can.