"Holes" in the recording - Why does SONAR not notice?

We had a client computer that recorded vinyl 12 hours per day. (Artist 2017.02 - ASIO: RME Fireface 800).
For a few months we had replaced this computer with a laptop DELL Latitude.   (Artist, 2017.02) (the same RME Fireface 800)
Now we notice "holes" in the recording:
That means: Every 1 - 3 minutes, suddenly 500ms to 2000ms are missing. The recording jumps seamless without a pause. It sounds like the band has forgotten to play half a measure. During Recording I listened to the OUTPUT of the RME Fireface - all OK. When I play this recording, then it "jumps" all few minutes.
 
I know this is up to a driver for the firewire connection or its up to the firewire hardware from the DELL laptop. The solution is to replace this computer. Very easy. (I don't want to check with other versions of SONAR)
 
My question is: Why does SONAR not notice !!! that the firewire driver delivers nonsense? I would expect that SONAR stops !! immeditately !! when the driver has issues during recording? 
Is there any parameter where I can tell SONAR to stop recording when a driver delivers nonsense?
I ask - because I need a safety precaution to prevent such issues. We have 7 client computers to record audio - I cann't check all recordings.
 

Does gap occur during recording, or during playback? IOW, if you examine the audio clip closely, can you identify where the gap is?
 
If so, that would suggest the audio interface is flushing its own internal buffer for some reason. SONAR would only know this had occurred if the data stream was interrupted. SONAR would detect this as a dropout and, if it was more than 250 ms in duration, halt the audio engine. You wouldn't miss such an event.
 
However, if the interface were to keep sending data despite the internal loss, the driver would happily continue to fill its buffers, SONAR would see an uninterrupted stream of data from the driver, and neither the driver nor SONAR would know there'd been any data lost.
 
I wouldn't be looking to replace the computer, I'd be considering replacing the audio interface.

DPC Latency checker.

Sonar can't notice a problem if there is a continuous stream of data coming into it - even if some of that data describes silence. So the issue must be outside Sonar. If drop outs are being described as data then they must be happening before or maybe during the A/D conversion stage. If this is the case there may be a fault in the analogue stage on the way into the audio interface. Either way, it's likely to be hardware rather than software, assuming you are monitoring from tape (from the DAW) and you are sure the drop outs are on the way in and not the way out.

There is a checksum of posted and received data trough firewire. So if the connection (for example cable) fails, the checksum is wrong.This would end in connection lost.
And the RME 800 doesnt tell SONAR where to position the data - Sonar only records the stream.
And it's not up to the RME 800, because it works with an other computer.
 
The question is: who kills up to 2 seconds of data without a gap in the streaming.
As we can now say:
An Original with 3:17 has after recording 3:15. 
Therefore SONAR is suspected - who shortens the recording?
Who kills the 2 seconds??
It's as if a ghost has cut holes in the recording then joined the ends.
(sync & caching is Trigger & Freewheel on all our devices - so only the stream is recorded without a clock)
   
I will make another test, to see if the recording is stretched, if there is a delay ....
Now I'm interessted in whats going on.

@M@
Our turntable is a broadcast turntable EMT948. "Supposedly" the best of the world. Has been used in all european broadcasting stations. It runs more accurately as a switsch watch. Second hand (with system TSD15) 6.500$
 

OK here is the first TEST:
SONAR looks into the future:
The recording is ready before the end is played.

 
The ghost is SONAR. At the end of the recording, a ghost from the Cakewalk team comes immediately and cuts a hole and joins the ends. Probably everyone laughs at this "joke".
(I have turned off direct monitoring. The output of the turntable is synchron with the RME 800)
 
My next test is updating from 2017.02 to the current version.

If you are recording with RME DigiCheck and you are messing with record enable buttons in sonar, you can lose what was in the buffer. You risk the data in the buffer, so bigger buffers means more obvious skips.

This is basically RME driver issue. Don't fiddle with the driver while you are recording and you will not have the issue.

Both Sonar and DigiCheck can be tricked this way.

When you are multi tracking, all tracks are impacted identically.

@gswitz
We don't use DigiCheck and we don't fiddle with the drivers. We noticed that "all" recordings from the last weeks are unusable. Because all recordings have holes.
This does not explain why 2 seconds are missing and the record is 2 seconds shorter as the input recording.
Sonar records a stream of 3:17 and has a clip with only 3:15. I would understand, if there were 2 seconds of silence or crackle, when the buffer of the firewire delivers nothing or nonsense.
But a recorded stream of 3:17 must end in a clip with 3:17. Because the RME 800 tells no time code, so the recording of the stream must go on. Even when the firewire delivers nonsense.

Thank you all.
This problem can not be solved. Otherwise I - or the Cakewalk team - or DELL - would have to do a lot of work for testing.

Sorry if I'm asking the obvious...

Have you monitored the recordings through Sonar? If so, are their periods of silence while Sonar is recording that then get closed up post-recording?

Have you tried recording into e.g. Audacity or another wave editor? If so, does the same problem arise?

Edited to add - I use my UFX via a Thunderbolt to firewire adaptor on Mac and it performs excellently, but have never succeeded in getting it to work properly in WIndows using firewire, so for Windows I've always used the USB connections. Firewire in Windows is a very tempremental thing indeed.

@tlw
I have not monitored through SONAR.
 
@gswitz
All computers for recording tape or vinyl have no internet. Therefor no Netflix. This are computers just for recording. Nobody works on this computers. Work is done on our 4 large DAWs. (Recorded Data is moved over local Network)
 
I say:
A laptop that crashes by closing projects in SONAR has in any case a problem.
If you want good results use professional devices - and not a DELL with a bulitin firewire card.
 
The RME 800 is 9 years old.
At that time 2008 we recorded 1100 vinyl for the German National Library with Windows XP, Sonar 6, and Pentium 2 with 800MHz and this RME 800. NO HOLES.
And now it does not work with Windows 10, DELL, DUAL Processor and 2,5 GHz.
This is a shame. I would assume that the DELL should have a better firewire card as the very old computer for 9 years. This is no progress.
   
Now there is back the old working computer Dual Core 3,4GHz. The old computer has a very good firewire interface card and all works perfect.
 
I don't have the time to check why the DELL has such issues. And I don't can check hours of recorded material to find "holes". We are under pressure through our customers.
 

I believe, that the firewirecard makes sometimes a pause (cable, hardware, overload, driver ...?) and in this pause SONAR stops intern to record the stream - then continues recording as soon the firewire delivers new data. Actually there should be a silent passage in the recording.
There is no other way to explain why input stream 3:17 is shortened to a length of 3:15 with a hole or "cut" in the stream.
My problem is however to exclude this in future. Therefore a "cancellation" in the recording or a warning would be helpful, when data is not received for a short moment.