View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0006558 | ardour | bugs | public | 2015-09-01 09:06 | 2016-09-09 21:06 |
| Reporter | napcode | Assigned To | timbyr | ||
| Priority | normal | Severity | minor | Reproducibility | always |
| Status | closed | Resolution | fixed | ||
| Product Version | 4.6 | ||||
| Summary | 0006558: Adding file with the same name results in missing files after reopening the session | ||||
| Description | Using Ardour 4.2 on Archlinux x64 - Create a session with 2 audio tracks - Add a sample named X from path A [via drag and drop] - Add a sample named X from path Y [via drag and drop] - Note: both samples are fine as long as the session is open - Save and reopen the session -> 1) Both items/samples are reported missing and ardour asks only for the "filename". Hence, even the user is unable to resolve the the missing links since the "origin"-path of the sample is not being shown. 2) Ardour actually asks sample.number_of_channels times for missing files. In case of adding a stereo and a mono sample in the example above, ardour will report 3 missing files. Expected behaviour: - Ardour references files by the absolute path if that file is not within the session folder (e.g embedded) - Files within the session folder should be referenced by relative paths. - Ardour reports missing audiofiles only for each sample and not for each channel | ||||
| Additional Information | In some cases, it could be helpful to ask the user whether a media item should be referenced by its relative or by its absolute path. That way multiple sessions could reference a local sample library that could be moved along with the session directories to another machine without breaking anything. You also wouldn't have to store multiple copies of the samples from that library that way. | ||||
| Tags | No tags attached. | ||||
|
|
When a file is imported into ardour either via drag and drop or via the import dialog with the "copy to session" option unchecked it uses the AudioFileSource constructor for external-to-session files(~audiofilesource.cc:93) which sets the FileSource::_origin member to an absolute path to the external file and it also adds the directory that contained the file to the audio-searth-path session property When the session is reloaded it uses the AudioFileSource constructor for internal-to-session(comment is innaccurate) files(~audiofilesource.cc:135) called via SourceFactory::create(). At that point the _path member contains the name of the external file ("name" property in the session XML) which is used along with the directories contained in the audio-search-path to find the file via FileSource::find(). This means that if there are two directories that contain a file with the same name the Ambiguous File dialog is shown. One solution to this could be to use the path contained in the FileSource::_origin member to set FileSource::_path before calling FileSource::init so that FileSource::find does not try and find the file and just uses the path provided. It has been suggested that the FileSource::_origin property is intended to be used for time stretch when re-stretching files so that there is not a cumulative degradation in audio quality. In which case perhaps an absolute path should be stored in the Source XML node as another property for external files. Another option would be to store a hash for files to determine equivalence and keep the find via audio-search-path+name+hash but that seems overly complicated and unnecessary for this use case(although it may be useful to find files in other circumstances) |
|
|
We have specifically avoided ever storing absolute paths with Sources, precisely because the idea is that their locations can move around. This is why we separate the search path from the filename. If someone stores their sample library on /media/bar/foo but one day it changes to /media/foo/bar, we don't want to consider every single missing sample as a special case - the problem is just the search path, not the sources. |
|
|
I understand the motivation behind using a search path and filename to identify a file. How to do propose to fix this issue where there are two files with the same name in the search path, the identity of the file is known on import(and stored) but then it can not be determined upon re-loading the session by just name and search path alone. I can't see how this is just a problem with the search path, can you please explain? |
|
|
Confirming this issue exists in ardour version 4.6 |
|
|
A change has been committed to master branch as dbf86a49 that implements the change I described in http://tracker.ardour.org/view.php?id=6558#c17876 so this issue should be fixed in the next release(5.4). If the reporter can confirm that this issue is now fixed that would be appreciated. |
|
|
Works as expected. Thanks timbyr! |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2015-09-01 09:06 | napcode | New Issue | |
| 2015-09-21 12:53 | x42 | Relationship added | related to 0006557 |
| 2016-01-28 11:32 | timbyr | Relationship added | related to 0005745 |
| 2016-02-04 02:07 | timbyr | Note Added: 0017876 | |
| 2016-02-04 02:19 | paul | Note Added: 0017877 | |
| 2016-02-09 23:35 | timbyr | Note Added: 0017892 | |
| 2016-02-17 03:11 | timbyr | Note Added: 0017960 | |
| 2016-02-17 03:11 | timbyr | Assigned To | => timbyr |
| 2016-02-17 03:11 | timbyr | Status | new => confirmed |
| 2016-02-17 03:11 | timbyr | Product Version | 4.1 => 4.6 |
| 2016-04-18 14:24 | x42 | Relationship added | has duplicate 0006859 |
| 2016-09-09 04:18 | timbyr | Note Added: 0018577 | |
| 2016-09-09 04:27 | timbyr | Note Edited: 0018577 | |
| 2016-09-09 04:29 | timbyr | Note Edited: 0018577 | |
| 2016-09-09 04:30 | timbyr | Note Edited: 0018577 | |
| 2016-09-09 21:05 | napcode | Note Added: 0018584 | |
| 2016-09-09 21:06 | napcode | Status | confirmed => closed |
| 2016-09-09 21:06 | napcode | Resolution | open => fixed |
