View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0001650 | ardour | bugs | public | 2007-05-06 04:08 | 2008-11-24 12:35 |
| Reporter | seablade | Assigned To | |||
| Priority | normal | Severity | major | Reproducibility | always |
| Status | closed | Resolution | open | ||
| Product Version | 2.0 | ||||
| Summary | 0001650: Routing Lost on Jack Zombification | ||||
| Description | Ok the title makes it seem like a 'duh' moment, and maybe it still is, but it is a bit more than my first thought on reading the title, it may also be a jack issue not an ardour issue, not sure. When Jack is killed, in my case often zombified for some reason which I cannot figure out, I restart Jack and reconnect Ardour. However on recconection with Jack, ardour is now named ardour-01 instead of ardour in terms of jack ports, the result of which is NONE of my routing can be reconnected(As they are looking for the ports beginning with ardour:... not ardour-01:...). To make matters worse if I save right then I lose all my routing, which on a decent sized project is a fair amount of work lost. As mentioned this seems to be a possible issue with Jack, but also it would be nice if Ardour could compensate for it(And maybe it should?). I will be more than willing to forward to jack folks(If I can find their email;) if it is determined it should be fixed there. Seablade | ||||
| Tags | No tags attached. | ||||
|
|
I don't suppose any work has been done on this at all? I just lost MANY hours of work on a project on a timeline on 2.0.5 because of a reoccurance of this bug, this time though it did not need Jack to zombify as it seemed to happen after recovering from a crash, and crashing again immediately. Now instead of recovering or attempting to again, it loads up a session file that has all regions and edits on the regions in place, and even tracks and automation in place seemingly, but all routing including plugins and their settings are completely gone. When restoring the routing by hand it appears that the fader and pan automation remains, I can't speak for plugin settings as I had tuned those by hand and left them on manual. My guess on to a cause to look at might be the order of operations when writing sessions. I am not sure how it is done, but an older session file should not be deleted until the writing of the new session is complete, that way if the new session file does not complete for whatever reason(Crashes which seem to be getting more numerous lately in my case) the old session file is still there and can still be recalled. Since they are text files it may be worth it to keep a bzip2 archive of them about when saving and just archive older session files to be recalled as needed. Seablade Going to go destroy some things now before getting back to work on this session.... /vent |
|
|
I have attempted to make it impossible to save session state when disconnected from JACK (precisely because we lose any way to derive routing information; we could make Ardour cache it but that has its own risks). You have apparently uncovered some new way for the session to be saved OR you have uncovered a problem with the connect/reconnect process that leads to the alternate client name. What settings are you using with JACK? It sounds as if JACK fails to detect that Ardour has disconnected, and thus forces a new name upon it when the reconnect happens. Plugin settings are never related to JACK, BTW, since they don't know anything about JACK. |
|
|
Hmm the most recent time it happened the client was not renamed in Jack, so it sounds like what you did fixed the problem directly related to zombification, but this one was not a result of a zombification, but rather two crashes in a row. I was considering whether or not to make a new report for it, and decided it was close enough to likely be related, but apparently I should have made a new one for it. What happened was Ardour Crashed(Most likely due to a bug in the Mackie Protocol, I am finding a few of those lately and need to get svn working to test that to se if John may have already fixed a few of these). At the time I believe it was writing automation information on a few tracks as I was laying out my basic mix. Upon reopening it asked about recovering data lost in recording, I told it to go ahead and do so, and it restored perfectly and got the data I had written even. It then crashed again however before I could save it, only a few seconds after opening, again likely due to a bug I am about to report as well for myself or John, or whoever to take a look at in the Mackie code when I am done with this project as I am now very behind in it, and upon reopening it had no routing information (Track I/O, etc) whatsoever. As such Pan etc was not able to be accessed, but upon adding routing back in by hand Pan at least was able to be recovered. However along with all routing information all Plug-Ins and their settings were lost. Thankfully I was trying out the preset system and had made a couple of default starting points for my tracks, so I wasn't quite as far behind as I thought, but I still had a fair amount of work there lost in all plugins and routing going down the tubes. As you mentioned the plugins are unrlated to routing, however I am wondering if because all track I/O was lost, and the plugins are designed to work with a specific number of ins and outs, if that might clear invalid plugins? Just a shot in the dark though. Seablade |
|
|
Paul do you still need Jack settings? If so currently they are 48K, realtime, 1024 frames/period, 2 Periods/buffer, 512 port maximum(Upped as the default 128 was far from sufficient), timeout 500ms, dither Triangular, and patchbay persistance. Any settings I can get you for ardour etc? I don't have time to do a debug build right at the moment as I am now pretty far behind on this project, but if it is desperately needed I can see about doing so. Seablade |
