View Issue Details

IDProjectCategoryView StatusLast Update
0006557ardourbugspublic2020-04-19 20:17
Reporternapcode Assigned Tox42  
PriorityhighSeveritymajorReproducibilityalways
Status closedResolutionfixed 
Product Version4.1 
Summary0006557: Renaming the session root folder results in all media items missing
DescriptionUsing Ardour 4.2 on Archlinux x64
Steps to reproduce:
- Create a session
- Record some audio and draw some midi clips
- Save and close the session
- Rename session root folder
- Reopen that session
-> all media items are reported missing even though they reside in the interchange folder

Expected behaviour:
For an "embedded" session like the above, renaming should not lead to any files missing.
Additional InformationArdour looks up in the wrong folder after renaming the root. It does look for
$SESSIONDIR/interchange/$SESSIONDIR

Hence, ./interchange/$SESSIONDIR would have to be renamed as well.
TagsNo tags attached.

Relationships

related to 0006558 closedtimbyr Adding file with the same name results in missing files after reopening the session 

Activities

x42

2015-09-19 13:54

administrator   ~0017324

Renaming session the session should be done via Menu > Session > Rename

Since you can configure multiple search-paths in Session > Properties, one could argue that the current behavior is not a bug.

napcode

2015-09-21 13:01

reporter   ~0017331

Thanks for the pointer to the "rename" functionality. I wasn't aware of that.
Nevertheless, why should a DAW also be a file manager? In the end, this report boils down to having self-contained projects that can easily be moved between systems (and hence, folders). In my case, I'd like to sync them between systems (via rsync, syncthing or something like that) but the root folder of the sync varies between systems.

x42

2015-09-21 20:05

administrator   ~0017332

it's a tricky situation.

By design, ardour-sessions are "bundles" the dir-name defines the session-name.

All the .ardour session files inside are just project snapshots (the .ardour file-name is irrelevant).
On some system (e.g OSX such bundles appear as "file" (right click to inspect content). the internal structure is by default hidden from the user's view.

The actual problem at hand is referencing files (hence the relationship to 0006558).

Back in the day, there was the idea that power-users can re-use or share the "interchange" folder between sessions... or combine sessions. or symlink "interchange" to a different disk,... In reality almost nobody does that. Still changing the session-layout and search-folders now is not something to be done lightly.

x42

2015-11-19 15:12

administrator   ~0017628

fixed in Ardour 4.4-248-g03518b9

x42

2015-11-21 10:23

administrator   ~0017654

the current logic (after 4.4-248)

 * if there is a single folder in "interchange/" use it (regardless of the name)
   (if the name does not match the session's containing dir, log a info-message and suggest Session > Rename)
 * if interchange does not yet exist, create a dir using the name of the containing folder (usually the session-name, not the snapshot name)
 * if there is more than one dir in "interchange/": abort. Let the user sort things out (ardour won't ever create more than one dir there, the user must have created it)

napcode

2015-11-27 18:08

reporter   ~0017664

Thank you for the fix! Works nicely for my use cases.

system

2020-04-19 20:17

developer   ~0023517

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
2015-09-01 08:49 napcode New Issue
2015-09-18 19:43 BenLoftis Priority normal => high
2015-09-18 19:43 BenLoftis Severity minor => major
2015-09-18 19:43 BenLoftis Status new => confirmed
2015-09-19 13:54 x42 Note Added: 0017324
2015-09-21 12:53 x42 Relationship added related to 0006558
2015-09-21 13:01 napcode Note Added: 0017331
2015-09-21 20:05 x42 Note Added: 0017332
2015-11-19 15:12 x42 Note Added: 0017628
2015-11-19 15:12 x42 Status confirmed => resolved
2015-11-19 15:12 x42 Resolution open => fixed
2015-11-19 15:12 x42 Assigned To => x42
2015-11-21 10:23 x42 Note Added: 0017654
2015-11-27 18:08 napcode Note Added: 0017664
2020-04-19 20:17 system Note Added: 0023517
2020-04-19 20:17 system Status resolved => closed