View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0005681 | ardour | bugs | public | 2013-09-10 21:36 | 2020-04-19 20:16 |
| Reporter | nettings | Assigned To | x42 | ||
| Priority | low | Severity | major | Reproducibility | always |
| Status | closed | Resolution | fixed | ||
| Platform | openSUSE Tumbleweed | OS | Linux | OS Version | 3.11 |
| Summary | 0005681: POTENTIAL DATA LOSS due to duplicate playlist reference after renaming tracks | ||||
| Description | I have reason to believe that Ardour3 will lose data under the following circumstances: * Create a template session for a live recording, one track is named FOO, the other BAR. * Do a brief test recording. * During setup, you realize that the FOO instrument is really wired to BAR, and vice versa. * Rename FOO to BAR.1, BAR to FOO, and finally BAR.1 to BAR. * Record. It seems that the file names for the regions on disk are determined at some point and not updated when a track is renamed. I ended up with tracks FOO and BAR both having regions BAR.n in their playlists. But it was not simple playlist corruption - there were no FOO.n files whatsoever. Sorry for the vagueness of this bug report, I haven't found time to reproduce it yet - this is just a quick heads-up to warn other users. The scenario is probably rare, but not so much for live recording jobs... | ||||
| Tags | No tags attached. | ||||
|
|
it appears the root cause was not a duplicate file name or corrupted playlists, but rather a the fact that two tracks ended up using the _same_ playlist, even during recording. i believe this has ultimately caused one track to constantly overwrite the data of the other. the problem was evident in the session after recording: each edit in track FOO was immediately replicated in BAR and vice versa. the only way to fix that was to assign BAR a copy of its current playlist, at which point the connection was broken and the useless BAR track could be safely removed. |
|
|
i played around a bit, and it is not readily reproducible. looks like under normal conditions, ardour will suffix playlists with .N to avoid name clashes. all i can say for now is there is at least one (race?) condition where this doesn't work as expected. |
|
|
got it. but i have to be really nasty to trigger it: new session. create track foo. its playlist is "foo.1" create track foo. ardour will name it "foo 1" and the playlist "foo.1.1". verify the names of both playlists, in case they turn out different. now change the name of the second track to that of the first _playlist_. you should end up with two tracks referencing the same playlist. record some data. while the session lives, the playlists appear to be separate, in that you can trim regions in one track without affecting the other. after you reload the session however, both tracks will be affected by any region operation, and you will notice any recorded data of the second track to be missing. i agree that this is a really pathological corner case. but i was able to trigger it in production, due to the very normal confusion about the stage patch and instrument names... |
|
2013-09-26 21:45
|
|
|
|
Since Ardour 5.4-470-ge9eea8d playlist names are unique. |
|
|
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. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2013-09-10 21:36 | nettings | New Issue | |
| 2013-09-26 21:24 | nettings | Note Added: 0015347 | |
| 2013-09-26 21:33 | nettings | Note Added: 0015348 | |
| 2013-09-26 21:43 | nettings | Note Added: 0015349 | |
| 2013-09-26 21:44 | nettings | Reproducibility | have not tried => always |
| 2013-09-26 21:45 | nettings | File Added: duplicate-playlist.tar.bz2 | |
| 2013-09-28 10:02 | nettings | Summary | POTENTIAL DATA LOSS due to duplicate region and file names after renaming tracks => POTENTIAL DATA LOSS due to duplicate playlist reference after renaming tracks |
| 2015-08-19 20:06 | nettings | Relationship added | related to 0006497 |
| 2016-11-28 11:17 | x42 | Relationship added | has duplicate 0006523 |
| 2016-11-28 11:20 | x42 | Note Added: 0019081 | |
| 2016-11-28 11:20 | x42 | Status | new => resolved |
| 2016-11-28 11:20 | x42 | Resolution | open => fixed |
| 2016-11-28 11:20 | x42 | Assigned To | => x42 |
| 2020-04-19 20:16 | system | Note Added: 0023271 | |
| 2020-04-19 20:16 | system | Status | resolved => closed |
