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|
|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.|
clip-test.zip (3,578,541 bytes)
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':-
Track::state (bool save_template)
XMLNode& root (Route::state (save_template));
// rest of function. . .
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.
|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|