View Issue Details

IDProjectCategoryView StatusLast Update
0007551ardourbugspublic2020-04-19 20:18
Reporterjohne53 Assigned Tojohne53  
PriorityhighSeveritymajorReproducibilityalways
Status closedResolutionfixed 
PlatformPCOSWindowsOS VersionWin7 and Win8.1
Product Version5.X git (version in description) 
Summary0007551: Timeline disappears after saving a session
DescriptionBuilt 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 ReproduceApparently 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 InformationI'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?
TagsNo tags attached.

Activities

johne53

2018-01-30 16:07

reporter  

clip-test.zip (3,578,541 bytes)

johne53

2018-02-01 08:42

reporter   ~0020139

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

johne53

2018-02-02 09:44

reporter   ~0020140

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?

johne53

2018-02-02 18:24

reporter   ~0020143

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.

timbyr

2018-02-03 00:59

developer   ~0020144

Last edited: 2018-02-03 01:00

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.

johne53

2018-02-03 09:55

reporter   ~0020145

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

timbyr

2018-02-03 10:43

developer   ~0020146

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.

johne53

2018-02-03 14:16

reporter   ~0020147

Last edited: 2018-02-03 16:07

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

system

2020-04-19 20:18

developer   ~0023779

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