View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0007551 | ardour | bugs | public | 2018-01-30 16:07 | 2020-04-19 20:18 |
| Reporter | johne53 | Assigned To | johne53 | ||
| Priority | high | Severity | major | Reproducibility | always |
| Status | closed | Resolution | fixed | ||
| Platform | PC | OS | Windows | OS Version | Win7 and Win8.1 |
| Product Version | 5.X git (version in description) | ||||
| Summary | 0007551: Timeline disappears after saving a session | ||||
| Description | Built from git master (30th Jan 2018). These steps needed to reproduce:- 1) Launch Ardour and open an existing session (or create a new one) 2) Make sure there are some clips on the timeline 3) Press 'Session->Save' followed by 'Session->Quit' 4) Re-launch Ardour and load the same session All the timeline clips will be gone | ||||
| Steps To Reproduce | Apparently this isn't reproduceable in the gcc build but is very consistent in my MSVC build (so not sure if it's some aspect of my particular build...) | ||||
| Additional Information | I've attached a zip file containing such a session (created from scratch a few minutes ago). The original session had 2 x tracks called "Audio 1 and "Audio 2" (with 3 x timeline clips between them). However, the playlists for those tracks seem to be empty. Instead, there are two other playlists present, called 'toBeRestetFroXML.1' and 'toBeRestetFroXML.2' respectively (which I didn't create). Maybe that's a clue to the problem? | ||||
| Tags | No tags attached. | ||||
|
|
|
|
|
Firstly, correct a typo (too many t's). The correct Playlist names (in my original report) should have been 'toBeResetFroXML.1' and 'toBeResetFroXML.2' respectively. Now for an observation which might be important... I decided to look in some older session-state files to see if I could estimate when the word "toBeResetFroXML" first started to appear. And I found out something quite interesting... That text appears quite often, even in very old sessions - but from what I can tell, it usually gets applied to 'Processor' type objects (most commonly to a meter AFAICT). This is the first time I've seen "toBeResetFroXML" getting used for a Playlist name. Does that give any clue to the problem.? |
|
|
I've a feeling this might be something to do with Routes getting corrupted. If I add a new audio track and save the session, the first line of the newly created Route looks like this (inside the session-state file):- <Route id="1909" name="Audio 3" default-type="audio" strict-io="1" active="1" denormal-protection="0" meter-point="MeterPostFader" disk-io-point="DiskIOPreFader" meter-type="MeterPeak" audio-playlist="1948" saved-meter-point="MeterPostFader" alignment-choice="Automatic" mode="Normal"> If I then close Ardour, open it again, load the session and then close (without saving) nothing changes - BUT - if I save the session before closing, the Route entry gets truncated - i.e. <Route id="1909" name="Audio 3" default-type="audio" strict-io="1" active="1" denormal-protection="0" meter-point="MeterPostFader" disk-io-point="DiskIOPreFader" meter-type="MeterPeak"> My guess is that this truncation is in fact happening when I load the session, rather than when I save it (because when I load the session, my audio tracks have bits missing - e.g. they don't have a 'record enable' button). Another thing I've noticed is that Routes no longer have a Diskstream object (within the session-state file). Is that intentional? |
|
|
I haven't really gotten much further with this but I did notice some suspicious looking code in 'libs/ardour/track.cc':- XMLNode& Track::state (bool save_template) { XMLNode& root (Route::state (save_template)); // rest of function. . . return root; } Aren't we returning a reference to a local object here? There's no guarantee that 'root' will still be in scope after Track::state() returns. |
|
|
No, Route::state allocates an XMLNode and then returns a reference to it, so the reference is valid after leaving scope. It is a confusing and a poor API design IMO and this sort of pattern is part of the reason why there are many XMLNode instance leaks, but I don't think it is related to your issue. |
|
|
That makes sense now Tim, thanks. I'm still confused about something though... Is a timeline audio track an object of type 'Route' or is it an object of type 'Track' now? The reason I'm curious is that those missing properties ("audio-playlist" / "saved-meter-point" / "alignment-choice" etc) all seem to belong to type Track. But when I load or save a session, neither Track::state() nor Track::set_state() ever seem to get called (however, Route::state() and Route::set_state() do seem to be getting called). This suggests either that something needs to be virtual, which isn't - or maybe something is still building objects of type Route when it now needs to be building objects of type Track. Or maybe this is still a work-in-progress? Perhaps I need to wait a bit before expecting it to work... |
|
|
I'm not too sure as to the state of master at the moment as I'm not using it with my projects. Using a linux(64bit) gcc build of master@942ca036aa0 I can create a new session and it will seemingly correctly restore playlists/regions. I think it may be a bit early to expect Sessions not created with a recent build of master to load correctly. If a Session created with master is not restoring correctly with your builds then it may be a MSVC specific issue. |
|
|
Thanks for helping with this Tim. I think I might have found the problem (hopefully!) 'build/libs/ardour/libardour-config.h' is a file which should only get #included when building with waf (in fact, I think it only gets generated when building with waf). However there were a few places where it was getting #included, even for my MSVC build. This had the effect of generating my session-state files at a very old format. I've pushed a change which seems to fix the problem - although I think there might be a few similar files to look at elsewhere (e.g. 'build/gtk2_ardour/gtk2ardour-config.h'). I'll need to take a look at the others over the next few days. [Edit...[ As an added bonus I just realised that 'Track::state()' and 'Track::set_state()' are now getting called when I save or load a session. Feels like I might be on the right lines here... |
|
|
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 |
|---|---|---|---|
| 2018-01-30 16:07 | johne53 | New Issue | |
| 2018-01-30 16:07 | johne53 | File Added: clip-test.zip | |
| 2018-02-01 08:42 | johne53 | Note Added: 0020139 | |
| 2018-02-02 09:44 | johne53 | Note Added: 0020140 | |
| 2018-02-02 18:24 | johne53 | Note Added: 0020143 | |
| 2018-02-03 00:59 | timbyr | Note Added: 0020144 | |
| 2018-02-03 01:00 | timbyr | Note Edited: 0020144 | |
| 2018-02-03 01:00 | timbyr | Note Edited: 0020144 | |
| 2018-02-03 09:55 | johne53 | Note Added: 0020145 | |
| 2018-02-03 10:43 | timbyr | Note Added: 0020146 | |
| 2018-02-03 14:16 | johne53 | Note Added: 0020147 | |
| 2018-02-03 16:06 | johne53 | Note Edited: 0020147 | |
| 2018-02-03 16:07 | johne53 | Note Edited: 0020147 | |
| 2018-10-25 09:14 | johne53 | Status | new => resolved |
| 2018-10-25 09:14 | johne53 | Resolution | open => fixed |
| 2018-10-25 09:14 | johne53 | Assigned To | => johne53 |
| 2020-04-19 20:18 | system | Note Added: 0023779 | |
| 2020-04-19 20:18 | system | Status | resolved => closed |
