View Issue Details

IDProjectCategoryView StatusLast Update
0005681ardourbugspublic2020-04-19 20:16
Reporternettings Assigned Tox42  
PrioritylowSeveritymajorReproducibilityalways
Status closedResolutionfixed 
PlatformopenSUSE TumbleweedOSLinuxOS Version3.11
Summary0005681: POTENTIAL DATA LOSS due to duplicate playlist reference after renaming tracks
DescriptionI 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...
TagsNo tags attached.

Relationships

has duplicate 0006523 closedx42 (4.2) Serious problems with playlist names 
related to 0006497 closedx42 Two playlists of the same name causing user confusion and random changes in the session 

Activities

nettings

2013-09-26 21:24

manager   ~0015347

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.

nettings

2013-09-26 21:33

manager   ~0015348

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.

nettings

2013-09-26 21:43

manager   ~0015349

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

 

x42

2016-11-28 11:20

administrator   ~0019081

Since Ardour 5.4-470-ge9eea8d playlist names are unique.

system

2020-04-19 20:16

developer   ~0023271

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
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