Level triggered recording crashing

program crashes after a few houjrs

Over the past month I have seen an otherwise stable system – that I have discussed in this forum, become one that crashes. I use the program to record fire department audio. The system is a Scarlett 18i20 to an i7 machine and the key feature that I use is the voice activated record feature.
I am using build 3250, but the last time I can recall the system being stable was build 3119. At this time a recording runs for a few hours and then it crashes with an error saying a fatal error has occurred and each time the message says a dump of the state prior to the problem has been sent to nTrack sysop.
I would like to find out what is causing the error. I have disabled and stopped my antivirus program, stopped win updates and stopped all other applications that could impact the machine – but the problem persists. Sometimes the recording will run for upwards of 50 hours before the error occurs – other times it happens in less than 3 hours

Hi Firecomm,

we’ve started today a long duration recording test to see if we can reproduce the problem. We do have a Scarlett 18i20 to test with so hopefully we’ll be able to reproduce the crash.
I’ll let you know what we find out.
In the meantime please send new crash dumps should the problem happen again, possibly filling in a short description of the crash so that we can more easily identify your crash dump.
Also please check that you have the latest version of the Scarlett Asio drivers, new versions are being released quite often and we had some problems with an earlier version of the drivers which was caused by a bug in the drivers, which has been fixed in later versions.

Flavio.

How is your interface coupled to the computer? Firewire? Usb?
Bax

interface for 18i20 is USB – which is the only option

Flavio

Where are the crash reports saved or do I have to do something special to save the file when a crash occurs?

Paul

After just less than 30 hours recording nTrack has crashed again. The total file size for all recorded material (in this folder) is 1.56 GB with the largest or average file being 292,898. I have updated the 18i20 drivers, there is no antivirus program running, windows updates have been turned off, the power setting for the machine has no power down and the machine is not used for anything else – it’s standalone just for recording audio.
Once again I don’t know where the crash report is saved, when I know that I can send it to you — or do you get it automatically each time a crash occurs?
Paul

Flavio

I think I see the crash report is linked to the request form. I have filled in the latest crash report

Flavio

nTrack ran for less than 4 hours this time before it crashed. I have sent the latest report.

Flavio

nTrack ran for about 40 hours this time before it crashed. I have sent the crash report.

** I notice that when the program starts recording – in voice activated mode, the word ‘RECORDING’ flashes slowly in red, but after a few hours it changes to black. The other thing is the flash rate (for the word RECORDING) is slow in the first few hours, but it gradually speeds up and by the time the record time reaches something in excess of 30 hours the flash rate has reached a point the word is barely legible.

Pau

Paul,

build 3254 should be online in a few hours, it fixes a memory leak that caused n-Track to gradually consume more memory until Windows would kill the app. This wouldn’t matter for typical recording sessions that rarely last more than a bunch of hours but might be the root cause of the problems your experiencing with recordings of say more than 4 hours.
Please let me know if the new build fixes the problem.

Thanks,
Flavio.

Flavio

I am pleased to report that nTrack has now run for 133 hours (using build 3254)in my current recording session without a crash incident. The memory leak bug fix seems to have fully addressed the issue that I reported. Thanks for your prompt work to find and fix the bug.

Paul

Flavio

It now seems I spoke too soon, nTrack just crashed at about 140 hours recording time. All seemed very okay until that point. I have sent you the crash report with an explanatory note.


Paul

Paul,

we’re still testing to see if we find other problems with long running recordings. Please if you can do this test: uncheck the Settings -> Waveform display -> “Show waveforms while recording” and “Generate waveforms while recording”.
This will make n-Track record without showing the waveforms while they are being recorded. This would tell us if the problem is related to the waveforms generation and drawing or with the recording itself.
Please also check how much memory is being used by n-Track every few hours during the recording (in the Windows Task Manager check the Memory / private working set column).

Thanks,
Flavio.

Flavio

I have started a new 6-channel recording and deselected / inchecked the specific items your requested related to showing waveforms.

With regards to memory usage, Task Mgr is reporting 81,956K being used my nTrack. Given I run both Process Monitor and Process Explorer, I can report that nTrack is using 2.91% CPU, 97,268K Private bytes and 124,748K working set memory usage.

I will continue to monitor memory usage.

Paul

Flavio

I know I’ve mentioned - and made this offer in the past, but if you’d like to connect with my machine using TeamViewer please let me know and I’ll send you access info off this forum.

Paul

Flavio

After 28 hours, the memory usage for nTrack has increased a small amount from the numbers I posted yesterday. The numbers (as per Task Manager) are now showing 87,216K – which is up from 81,956K at the start.

Paul

Flavio

After 55 hours, the memory usage for nTrack has remained steady at 87,224K (as per Task Manager).

Paul

Flavio

After 70 hours, memory usage for nTrack appears to be remaining steady at 87,224K (as per Task Manager and the program continues to use about 3% of the CPU resources.

Paul

Flavio

After 94 hours, memory usage for nTrack appears to be remaining steady at 87,224K (as per Task Manager and the program continues to use about 3% of the CPU resources.

Paul