Ardour git sometimes returns empty region after stop recording

I’m running self-compile debug from latest master (Increase process-thread stack size (same value as jack2) · Ardour/ardour@bc1d19a · GitHub). I’m repeatdedly runinng into issue where the last region I recorded shows the waveform fine as it is recording, but then when I press stop, the recorded region is replaced by an empty region. I don’t hear that recorded region when I playback.

However, if I look in my filesystem I can see the region recorded with names

recorder:BassClarinet 1-7%97.wav
recorder:BassClarinet 1-7%98.wav
recorder:BassClarinet 1-7%99.wav

and I can open those wavs and see my recorded audio in them. So ardour knows to save the audio to a file, but maybe ardour doesn’t properly load the same file back?

Maybe I shouldn’t be using git builds when recording, lol!

so this is really interesting, I see in the region list, there are two regions of idential length that were just recorded named:

recorder:BassClarinet 1-7%97.1
recorder:BassClarinet 1-7%97.2

And it turns out that that second one shouldn’t be there. And it is actually covering up the real recorded region. Simply clicking on the that extra region and pressing delete, then I can uncover the real recorded region. So the problem is somehow for some mistaken reason, ardour thinks there is an extra region.

The more worrying part is that there a filenames with the recorder: prefix.
The current git version should not do that anymore.

Have those been recorded with 6.6.119 or later, and if so could you share the .ardour session file for us to investigate?

hmm…here is ardour file from

But it says created-with="Ardour 6.6" modified-with="Ardour 6.6-102-ge07b3104bb, so maybe I actually wasn’t using the latest git. Sorry.

Well what I think I’ll do is make sure I’m on the latest git and start a fresh session and see if it happens again. It happened a handful of times, so hopefully it will reproduce.

I had simply forgot to ./waf install the compiled build, that is why I wasn’t actually on the latest build.

I’ll try again, this time on the latest

/usr/local/bin/ardour6 --version
bind txt domain [gtk2_ardour6] to /usr/local/share/ardour6/locale
Ardour6.6.250 (built using 6.6-255-gced5918e22 and GCC version 10.2.0)

In general we recommend to just run self-builds of ardour from the source-tree without install:

cd gtk2_ardour/
./ardev

not only does that not clutter up your system’s /usr/, but it’ll also simplify debugging in case something comes up. – The only downside of doing that is that translations won’t work

ok, thanks for the tip. I started on fresh git checkout and used ./ardev to run, and started a fresh project on this latest git… Buy unfortunately I’ve managed to encounter the glitch again.

Ardour 6.6.250 "Desert Island Selection" (rev 6.6-255-gced5918e22) Intel 64-bit - debug

Here is the ardour session files:

I’ve also at this moment of encounter the glitch am making a tar.gz of the project, it will be a big file, but let me know if you would like to inspect that.

I don’t know how to debug this glitch cause it happens very sporadically. Let me know if there is any way I can help.

reopened the project, recorded some more, and got the glitch again:

here is current state of session files:

I think the likelihood of this bug happening increases as the number of tracks and regions in the project get larger.

Just a heads up, I had a quick look, but no explanation for this. Nor can I reproduce it.

The only issue is ambiguous capture alignment (and ambiguous I/O latency) due to parallel port connections (the “No align” button blinks). But that only leads to a region being placed incorrectly after rec-stop.

It would be preferable to file a bug report at tracker.ardour.org about this, The forum is not great to keep track of issues and it’ll likely be forgotten.

PS. Can you start ardour from a terminal and check the first few lines it prints. There should be a message:

Ardour: [INFO]: Your system is configured to limit Ardour to 1048576 open files

What is the limit on your system?

[e@Ryzen5-Radeon560 gtk2_ardour]$ ./ardev 
bind txt domain [gtk2_ardour6] to /usr/local/share/ardour6/locale
Ardour6.6.250 (built using 6.6-255-gced5918e22 and GCC version 10.2.0)
Ardour: [INFO]: Your system is configured to limit Ardour to 524288 open files
Ardour: [INFO]: Loading system configuration file /home/e/ardour/system_config
Ardour: [INFO]: Loading user configuration file /home/e/.config/ardour6/config
Ardour: [INFO]: CPU vendor: AuthenticAMD
Ardour: [INFO]: AVX-capable processor
Ardour: [INFO]: AVX with FMA capable processor
Ardour: [INFO]: CPU brand: AMD Ryzen 5 1600 Six-Core Processor            
Ardour: [INFO]: Using AVX and FMA optimized routines
Ardour: [INFO]: Loading plugin meta data file /home/e/ardour/share/plugin_metadata/plugin_tags
Ardour: [INFO]: Loading plugin statistics file /home/e/.config/ardour6/plugin_metadata/plugin_stats
Ardour: [INFO]: Loading default ui configuration file /home/e/ardour/build/gtk2_ardour/default_ui_config
Ardour: [INFO]: Loading user ui configuration file /home/e/.config/ardour6/ui_config
Ardour: [INFO]: Loading 451 MIDI patches from /home/e/ardour/share/patchfiles

I guess 524288 is less than 1048576. But still that seems like plenty.

(for whatever reason, tracker.ardour.org is not sending me an email to confirm my account, and I’ve tried with both a hotmail and gmail address and looked in my spam & junk folders.)

and today Mantis bug tracker has sent me registration email finally. So I’ve made a bug report: 0008665: when stop recording, ardour sometimes puts undesired empty region ontop of recorded region - Ardour Bug Tracker

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.