View Issue Details

IDProjectCategoryView StatusLast Update
0004032ardourbugspublic2020-04-19 20:15
Reporterin0giro Assigned Tocth103  
Status closedResolutionfixed 
Platformx86_64 Intel Core2 DuoOSGentoo amd64 + Pro-Audio OverlayOS Versionstable
Target Version3.0-beta1 
Summary0004032: problems with paths when loading session file from the command line
Descriptionthere seem to be substantial path problems with session files loaded from the command line:

1) when loading a session file from the command line with some audio regions, the regions are not found with the default audio region location (<Option name="audio-search-path" value="">), but the path needs be set explicitly, even though it is the default.

2) when recording a new audio region with a session file loaded from the command line, the new region is not saved to the default audio region location (<session-name>/interchange/<session-name>/audiofiles), but instead it is saved to <session-name>/interchange/audiofiles

note that i have not tried this with MIDI regions and these problems do not occur if the session is loaded via the Ardour startup wizard or via Session/Open.
Steps To Reproduce1) start Ardour 3 with no command line arguments
2) create a new session in the startup wizard
3) create a track and record some audio on it
4) check where the audio was saved to (should be default <session-name>/interchange/<session-name>/audiofiles)
5) save and quit Ardour 3
6) from command line, start Ardour 3 with the just created session file name as the only command line argument
7) a dialog opens saying that the audio region recorded in step 3 cannot be found (i.e. problem 1 from above). if you manually add the default audiofiles location, then it is found and the session loads
8) create a new track and try recording audio on it. this audio region will be recorded to a non-default location of <session-name>/interchange/audiofiles, which seems to be missing the <session-name> folder between interchange and audiofiles (i.e. problem 2 from above).
9) even editing the session file by hand to set the audio-search-path back to <Option name="audio-search-path" value="">) will result in audio regions being recorded to the new, non-correct location as in step 8.
Additional Informationi have tried this with both my native locale it_IT.UTF-8 and the locale of en_EN (as suggested by Paul on IRC), and the same result regardless of the locale setting.

from this log messages, which appears with problem 0000001 above:

[ERROR]: Filesource: cannot find required file (Audio-1.wav): while searching ./interchange/./audiofiles

it seems that when loading from the command line, the session file name is lost, and the default audiofiles location is thus adjusted to the incorrect "<session-name>/interchange/audiofiles" instead of "<session-name>/interchange/<session-name>/audiofiles"
TagsNo tags attached.



2011-05-06 15:45

reporter   ~0010700

update: it seems that this problem also is messing with recording of sessions loaded from the command line. as you can see from the Log Window messages below, Ardour is trying to record a region to the non-correct audiofiles location as described above, resulting in a failure to record:

[ERROR]: cannot open directory ./interchange/./audiofiles (No such file or directory)
cannot open directory ./interchange/./audiofiles (No such file or directory)
cannot open directory ./interchange/./audiofiles (No such file or directory)
cannot open directory ./interchange/./audiofiles (No such file or directory)
SndFileSource: cannot open file "./interchange/./audiofiles/chitarra 01-1.wav" for read+write (System error.)
[ERROR]: AudioDiskstream 159: cannot write to disk
[ERROR]: Butler write-behind failure on dstream chitarra 01
[ERROR]: SndFileSource: cannot open file "./interchange/./audiofiles/chitarra 01-1.wav" for read+write (System error.)
[ERROR]: AudioDiskstream 159: cannot write to disk
[ERROR]: AudioDiskstream "chitarra 01": cannot flush captured data to disk!
[WARNING]: attempt to flush an un-opened audio file source (./interchange/./audiofiles/chitarra 01-1.wav)

it seems like that in some cases Ardour simply creates the non-correct audiofiles location (as in step 0000008 above), or as in this case here (with a different session), it cannot find the non-correct audiofiles location and fails recording.

  regardless, it all seems to hinge on something screwing up the strings/paths of the session file when loaded from the command line.


2011-05-06 16:19

reporter   ~0010702

update: it seems that providing a full path to the session file from / makes everything work, but when using relative paths (as i do when i launch the ardour3 from the same directory as the session file, i just type "ardour3 <session-file>.ardour), the problems occur as described above.


2011-09-18 20:41

administrator   ~0011536

I can reproduce this by doing something like

ardour3 test.ardour

when the CWD is a test's session folder. In this case the session_path in ARDOUR_UI::get_session_parameters is set to '.', and it is subsequently used to build the path for audio files.


2011-09-23 14:26

reporter   ~0011563

i get the same behavior.

could having symbolic links to another partition in the path be a cause?



2011-10-22 21:46

administrator   ~0011737

Should be fixed in SVN 10285.


2011-11-21 02:54

reporter   ~0012148

confirmed fixed in 10722. thanks! do i need to change the bug state to "fixed" or is that something you devs do?


2020-04-19 20:15

developer   ~0022573

Issue has been closed automatically, by Trigger Close Plugin.
Feel free to re-open with additional information if you think the issue is not resolved.

Issue History

Date Modified Username Field Change
2011-05-06 14:54 in0giro New Issue
2011-05-06 15:45 in0giro Note Added: 0010700
2011-05-06 16:19 in0giro Note Added: 0010702
2011-05-16 22:36 cth103 cost => 0.00
2011-05-16 22:36 cth103 Target Version => 3.0-beta1
2011-09-18 20:41 cth103 Note Added: 0011536
2011-09-18 20:41 cth103 Status new => confirmed
2011-09-23 14:26 in0giro Note Added: 0011563
2011-10-22 21:46 cth103 Note Added: 0011737
2011-10-22 21:46 cth103 Status confirmed => resolved
2011-10-22 21:46 cth103 Resolution open => fixed
2011-10-22 21:46 cth103 Assigned To => cth103
2011-11-21 02:54 in0giro Note Added: 0012148
2020-04-19 20:15 system Note Added: 0022573
2020-04-19 20:15 system Status resolved => closed