recovering corrupted session

Installation & Configuration Linux
#1

Hi,
I have an Ardour session that crashed and which I now can’t open. other sessions seem to work normally. I’m looking for suggestions for how to recover the data. (I’d also be interested in submitting a bug report, except that the initial crash happened on an outdated version and I haven’t reproduced that yet.)

Initial crash: I was doing some recording and editing in Ardour. I selected a range (on the order of a minute long) over three or four tracks, copied it, and pasted it to just after itself. At this point I heard a buzz (I assume it was XRuns) and the GUI went at least partially unresponsive for a few seconds (can’t remember exact details of this). At this point I ctrl+s’d (not sure if good idea, but I didn’t know when I’d last saved) and closed Ardour.

Subsequent crashes: When I try to open the session in question, the little Ardour splash screen shows up as usual, and then (usually after it displays “Setup Editor”) a bunch of XRuns happen and Ardour closes (link to Jack output below). Other sessions, old and new, open as normal. I have not been able to reproduce the initial crash / set corruption in other sessions.

System: Arch Linux on Lenovo T420s. When the initial crash occurred my system was some months out of date and I believe I was running Ardour 3.5.308. Subsequently I updated Arch; I now have Ardour 3.5.380 (update had no apparent effect on re-opening the corrupted set). Currently running jack2 1.9.9.5; not sure what release it was during initial crash. For audio hardware, during initial crash I was using a Zoom H2 for external soundcard and mic. During subsequent attempts to open the set I’ve tried running jack with the H2 and with my internal soundcard (HDA Intel).

Data:
Ardour session in question: http://njoliat.the-nsa.org/ardour_issue/cph_organ_jam_bak.tar.gz
Just the XML files from session: http://njoliat.the-nsa.org/session_files/
Jack output during an attempted-session-opening crash: http://pastebin.com/rfyrqBsx
(I haven’t gotten a decent stack trace yet as I’m running the Arch package; if/when I do I’ll add that.)

Here are a few things I’ve tried so far; not sure if they’re relevant:

  • temporarily moving session-folder/instant.xml and ~/.config/ardour3/instant.xml out of the way
  • replacing session.ardour with session.ardour.bak
  • removing the plugins (namely 12-band EQ, Compressor, and Analyzer, all by Calf) from the .ardour file.

Thanks!

#2

sorry, the link to the XML files from the session is wrong; here is the correct link: http://njoliat.the-nsa.org/ardour_issue/session_files/

#3

ive never tried to fix a corrupted ardour session but i had something similar happen to kdenlive before they found a way to stop it happening.

If you open the xml in a text editor that supports xml (i think kate might understand the formattting) it should up some syntax errors in the file which i corrected to get the session working again.

ofcoarse this may only work with kdenlive or other programs so it may not be the case for ardour.

but its worth a shot, any errors should be highlights in red, you can reference that with a known good file to see if you can work out whats wrong.

#4

@nickj4096

First off make a backup of your session file.

Second we need to see the console output of Ardour, and yes a stack trace would help tremendously.

Since you made a backup of the session file, remove all the references to plugins in the session file and see if it opens then? The most common cause of this is a plugin issue. You can restore from the backup you made depending on the outcome.

       Seablade
#5

Thanks for the help!

@seablade: I tried recording some console output.
Console output of “usr/lib/ardour3 ~/session_file”: http://njoliat.the-nsa.org/ardour_issue/cmd_out

Also tried using “–debug all”, which caused Ardour to spew output for a few minutes (until I killed it) instead of crashing quickly. Here’s the output of that, with a few million lines of “DEBUG::TempoMath: Add Beat at 163|4 @ 15624000” (or “@ [other integer]”) deleted. http://njoliat.the-nsa.org/ardour_issue/cmd_out_debug_all

Here’s the same thing but after I removed the plugins and references to their id’s.
http://njoliat.the-nsa.org/ardour_issue/cmd_out_plugins_rmd_debug_all
(Here’s the modified session file for that http://njoliat.the-nsa.org/ardour_issue/cph_organ_jam.ardour.no_plugins)
One thing which might be relevant is that with this version (plugins removed and --debug all), instead of the typical XRun buzz sound, when it’s hanging and spewing messages I can actually hear the feedback from Ardour’s track monitoring.

(For another variation, instead of editing the XML I used the “-d” cmd option: http://njoliat.the-nsa.org/ardour_issue/cmd_out_d_P_D)

Anyway does this seem helpful at all, or is it still not much good without a trace?

I’m afraid I’m actually a little confused about what version of Ardour I need in order to get a backtrace; i.e. whether or not I need to build it myself. This page https://ardour.org/debugging_ardour.html says “If you built Ardour yourself and did not explicitly turn debugging off, then your version will have debug symbols available. If you got Ardour from ardour.org, then (… mumble …)”, so I wasn’t really sure what that was supposed to mean. I tried running my Arch package version with just “–debug” as mentioned later down on that page but it said it the option required an argument. Anyway, would you recommend trying this with a version downloaded from the site?

#6

@seablade
here is the trace: http://pastebin.com/3P3imcky

#7

You’re using a version of Ardour which allows absurd zoom levels. The zoom level in your session’s instant.xml and the instant.xml file in ~/.config/ardour3 needs to be changed to a value like “512” rather than the crazy value it has now. Both files need to be corrected before the problem will go away.

This has already been fixed in the ardour git repository.

#8

@paul
thanks for the reply. I set the zoom levels in session/instant.xml and in ~/.config/ardour3/instant.xml to 512 but I still get a crash on attempting to open. here are new console output and backtrace:
http://njoliat.the-nsa.org/ardour_issue/cmd_out_fixed_zoom.txt
http://njoliat.the-nsa.org/ardour_issue/backtrace_fixed_zoom.txt

#9

Same cause. Email the files in question to me (paul@linuxaudiosystems.com)

#10

Put a little differently, you have a region positioned roughly 6 million years into the timeline … I can fix this.

#11

for general thread closure: I was able to repair the session file with Paul’s suggestion; it was a matter of finding the region-length timestamp that was 6 million years in frames and editing it down. thanks all!

#12

geeez 6 million years in the future!

mental!

#13
geeez 6 million years in the future
At last, the year of the Linux desktop... :)
#14

@linuxdsp

Well played sir… I grant you one internets!

Seablade
#15

Hi Paul,

I seem to be having the same issue that Nickj4096 had. Looks like the same error (I reported it as a bug, but wasn’t really sure how and what to report!) Could you walk me through how to recover the session please?

I adjusted the zoom level to 512 in both instant.xml files as suggested.

Here are the original file sessions and debugging report. The session concerned is SICK2.46 am.ardour

Thanks very much for your time!

#16

Nohing obviously wrong with the session. I can’t debug it further without actual data files. I’m using current git, rather than the most recent release.

#17

If it helps, I can email you a link to the audio files. I’m pretty stuck as the files were recorded to picture and would be impossible to get them in sync again otherwise. Is there anything you suggest I can try myself? Thanks

#18

http://ardour.org/debugging_ardour

#19

jonesints

I could be entirely wrong here but recently I had a session that I had been working on for a couple of years suddenly wouldn’t open and would crash Ardour at the splash screen, I had the devs look at the session file and nothing obvious was found to be wrong yet the problem persisted… long story short somehow I had added a plugin that incorrectly added an LV2 MIDI port where it didn’t belong and the current released versions of Ardour don’t handle that very well. What worked for me was opening the session with a recent GIT build of Ardour (from the former Cairocanvas branch) which is more flexible with weird LV2 port layouts and this allowed me to open the session remove the offending wrong port and fix the session for both old and new Ardour versions…

As I said this may not be the case for you at all, but worth investigating. I’m not sure if you are comfortable building a newer development version of Ardour for yourself to try this or not… I can offer another option but it isn’t released yet…

#20

Thanks for the suggestion GMaq, building ardour seems to be something that could potentially sort out opening this session…
I don’t have any plugins at all, it was the simplest session: just recording files, without processing or even fades!

I have a deadline to meet and am working around the clock and without much sleep so will probably look into building ardour when I’m finished with the project. As I still need to access the files (in sync to picture), what I might do is open the .ardour file, search for every recorded sound and find the BWtimeStamp, copy it and embed it into the actual file via SoundMiner. That way I could create a new session in PT (or Ardour if it supports spotting via timecode/BWtimestamp) and bring all the recordings into the right place that way.

Thanks again for the suggestions, very much appreciated!