View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0005662 | ardour | bugs | public | 2013-08-17 01:00 | 2013-08-28 03:26 |
| Reporter | solarbird | Assigned To | |||
| Priority | normal | Severity | major | Reproducibility | always |
| Status | new | Resolution | open | ||
| Product Version | 3.0 | ||||
| Summary | 0005662: Import of 2.8.16 project to Ardour 3.3.0 loses playlist | ||||
| Description | Importing this linked 2.8.16 sample project into Ardour 3.3.0 results in the playlist "sbounce" being lost in 3.3.0. The playlist "sbounce.1" is retained. https://dl.dropboxusercontent.com/u/48493064/test-2x.tar.gz The audio regions which were on the missing playlist are still available in the regions list; the playlist on which they were located vanishes. This bug was discovered while trying to make a simple repro case for another bug which will be reported separately. Tagged as "major" since it's data loss. | ||||
| Tags | No tags attached. | ||||
|
|
ADDITIONAL BUG: Upon loading this project into Ardour 3.3, create a new playlist on the sbounce track, "sbounce.2" sbounce.1 disappears. It's not hidden; it's gone. |
|
|
we are not striving hard for 2.X => 3.X session importability. Ardour 2.X will continue to be available - this is not proprietary software where old versions vanish. we advised people at the launch of 3.x that they should plan to continue to use 2.x to work on sessions created there, in general. 3.x creates a backup of the 2.x version of the session file precisely to make sure that this continues to be possible after 3.x fails to handle a 2.x session. |
|
|
Not striving for good A2 to A3 import is a perfectly reasonable decision. THAT SAID: given that, 3.x really should not claim to import 2.x sessions, as it currently does, or it should import them read-only but allow export. Silent data loss and/or delayed session corruption(!) is a brutally horrible user-case scenario. It's the kind of thing that drives people away forever. At very, _very_ least, A3 should warn users. Say, have it bring up a second dialogue, after the user selects an unimported A2 project, but before running the import code. It could say something like: "This project was created in Ardour 2. Some Ardour 2 projects fail to import successfully into Ardour 3. DATA LOSS OR CORRUPTION MAY OCCUR. [Cancel] [I Regret Nothing]" ...with Cancel being the default. Okay, [Continue] instead of [I Regret Nothing]. But the point remains: make it really clear: THIS COULD REALLY HURT YOU. At least this way, they'd be warned. I was hesitant about importing A2 projects into A3, but then it said "here y'go! All done!" so I took that as a sign of dev team confidence, which was _highly misleading_. I ended up having to rebuild every project where I did that. It cost me _days_ of time. Had I seen a dialogue like that, I would've hit cancel. I kept 2.6.14 on my machine for that very reason. I am _fine_ with that being the decision. It's the land mines laid down that I'm not fine with. (If you want to be REALLY nice you could point to the 2.6.14 download point after they hit Cancel, in case they didn't.) (See also my comments on bug 5663, which results in a corrupted session (in A3) or lost-to-the-session data if you revert to A2, which doesn't know about the new files - you have to know about the internals of Ardour's project structure to find them and try to bring them back.) |
|
|
Ardour 3 already makes a backup copy of the session for use by Ardour 2 should things go wrong with Ardour 3. It even tells the user about this (or tries to). This backup file is never loaded, modified or touched in any way by Ardour 3 after its creation. |
|
|
Yes, I know. That's part of the point. That's one of the ways in which you lose the data. Remember, the A3 project corruption (which we should be talking about really in bug 5663 because that's where it's documented) doesn't happen immediately. Everything seems fine, and the user _doesn't know this is going to explode_. So the user _keeps working on the project in A3_ - or, at least, I did - until, some number of sessions later, _then_ it explodes. In my case, I had _six more recording sessions_ across _four projects_ that were affected. Now, when this happens, here's what you have: A2's version of the project master file (the -2000 project) doesn't know about any of the new work done in A3. As far as loading the A2 version is concerned, I hadn't done anything. So just reopening the project in A2 would've meant throwing out six sessions. And, of course, from the A3 perspective, the project is corrupted. And the more you create new recordings in it, the worse it gets. Once in this position, users have a choice of two failure modes: 1. losing all the work they've done since importing the project into A3 (by going back to A2 and using the A2 version of the project file) or 2. Continuing to try to use an A3 project which will continue to degrade as they record more material (obviously unacceptable). The only way to recover from this position without session loss is either to find all your new A3 recordings and re-import them into the A2 version of the project using A2, or create a new A3 project, find all the pieces, reimport all of them, and reimplement all your mixing and effects. I chose the latter. But either requires knowing (or learning about) the project file and directory structure. As before, I can and did do this, but it is an unreasonable expectation of users who haven't been software developers at some point in their lives, and a _miserable_ user experience. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2013-08-17 01:00 | solarbird | New Issue | |
| 2013-08-17 01:06 | solarbird | Note Added: 0015271 | |
| 2013-08-17 01:06 | solarbird | Note Edited: 0015271 | |
| 2013-08-21 01:24 | paul | Note Added: 0015278 | |
| 2013-08-28 01:12 | solarbird | Note Added: 0015286 | |
| 2013-08-28 01:35 | paul | Note Added: 0015287 | |
| 2013-08-28 03:26 | solarbird | Note Added: 0015288 |
