Session recovery - linux - Failed to load state

Ubuntu Studio 18.04 Ardour 5.12.0-3
Came back to finish project and found this:
(project name) did not load successfully:
Failed to load state

The project files seem intact - I can view the XML in an editor.
Started a new session, imported the audio files (6 files - 1 hour 30 minute live concert to mix for CD, will end up about 20 tracks)
Really don’t want to think about re-doing sevrtal days work . . .

Did you try loading the session with safe mode enabled? That is, when starting Ardour and you get to the session selection screen, there is a checkbox one line up from quit at the bottom that says safe mode. If it starts with that checked then one of your plugins is causing trouble. Maybe replace that plugin with another similar plugin.

Already tried that, no joy.

First question, do they open if you use the demo version from this website instead of the Ubuntu Repo version?

Second question, if you remove instant.xml do they open?

Third question, are you using Jack or ALSA for audio? If Jack does it work when you use ALSA? Are you sure your audio hardware supports the sample rate of the project and is set correctly?

Realistically we need more info than is currently in your report to determine why it isn’t opening, if you run from the terminal is there any output there?

     Seablade

and if you see “Could not understand session file…” message, please upload the .ardour XML file to some place (pastebin.com, google-drive, or tracker.ardour.org) for us to look (and hopefully fix)

$ ardour5
bind txt domain [gtk2_ardour5] to /usr/share/ardour5/locale
Ardour5.12.0 (built using 1:5.12.0-3 and GCC version 7.3.0)
ardour: [INFO]: Your system is configured to limit Ardour to only 1048576 open files
ardour: [INFO]: Loading system configuration file /etc/ardour5/system_config
ardour: [INFO]: Loading user configuration file /home/tlwest/.config/ardour5/config
ardour: [INFO]: CPU vendor: AuthenticAMD
ardour: [INFO]: AVX-capable processor
ardour: [INFO]: CPU brand: AMD FX™-6350 Six-Core Processor
ardour: [INFO]: Using SSE optimized routines
ardour: [INFO]: Loading default ui configuration file /etc/ardour5/default_ui_config
ardour: [INFO]: Loading user ui configuration file /home/tlwest/.config/ardour5/ui_config
Color shuttle bg not found
ardour: [INFO]: Loading color file /usr/share/ardour5/themes/dark-ardour.colors
ardour: [INFO]: Loading ui configuration file /etc/ardour5/clearlooks.rc
ardour: [INFO]: Loading ui configuration file /etc/ardour5/clearlooks.rc
Found 1 along /home/tlwest/.config/ardour5/templates:/usr/share/ardour5/templates
run dialog

Errors/Messages:
ERROR: Session file . . . is not a session

removing instant.xml has no effect

Have been using jack and the Delta 44 for years at 44.1. The session was working fine for several days, but failed to load after my last work. Using exactly the same hardware, software, and audio files, I started a new session which seems to be working okay.

And Downloading the demo Ardour-5.12.0-x86_64.run, allowing it to reinstall Ardour in /opt, and running it in a terminal with full pathname gives exactly the same resluts.

That indicates that you didn’t select a “*.ardour” Session file.
At least there’s no <Session ...> root element in the Session XML file.

$head WPC201912reh.ardour

<?xml version="1.0" encoding="UTF-8"?>

Let’s try that again:

$head WPC201912reh.ardour

<?xml version="1.0" encoding="UTF-8"?>

and nothing else? head should by default print 10 lines and the root-element should be Session

<?xml version="1.0" encoding="UTF-8"?>                                                                                                                                                         
<Session version="3002" name="...

Hmmmmm. The file displays okay in a terminal, but only the first line will post.

Here is the full file:

Okay, I’ll do it the right way . .

https://pastebin.com/V3kZDeab

This may work better:

Odd, that session loads just fine here in Ardour 5.12 (audio is obviously missing, and there a warning of a missing plugin, but the XML is fine):

Can you create new sessions?

FYI you need to mark it as preformatted text, otherwise Discourse is trying to treat the backeted XML as info about the post, instead of content. See below…

$head WPC201912reh.ardour
<?xml version="1.0" encoding="UTF-8"?>
<Session version="3002" name="WPC201912reh" sample-rate="44100" end-is-free="0" id-counter="10293" name-counter="1" event-counter="1491" vca-counter="1">
  <ProgramVersion created-with="Ardour 1:5.12.0-3" modified-with="Ardour 1:5.12.0-3"/>
  <MIDIPorts>
    <Port name="MIDI Clock in" direction="input"/>
    <Port name="MIDI Clock out" direction="output"/>
    <Port name="MIDI control in" direction="input"/>
    <Port name="MIDI control out" direction="output"/>
    <Port name="MMC in" direction="input"/>
    <Port name="MMC out" direction="output"/>

Beyond that x42 has most things covered I think:)

Sorry for disappearing, the system locked me out for too many posts.

I can, and have, created new sessions. I rebuilt the whole thing last night in a new session - all seems well. Would it be worth trying to delete the first couple of lines in the session file and re-enter them manually - thinking there might be a corrupt character ???

I recall sometimes Ardour/Mixbus can even fail to start the first pop-up dialog if a plugin caused a crash just previous. A problem I was having awhile ago, was a session crashing due to a faulty plugin, and the end-result was that the application would not even start later(the plugin in question finally got fixed by the company and now works correctly with Ardour/Mixbus so this is good)… though I haven’t yet fully uncovered what was causing the application to fail, the issue was pointing to corrupted configuration rather than session data. I tried removing things from ~/.cache/mixbus5 (there’s an ardour5 path as well), … I don’t think that made a difference, so I figure I can keep an old/working copy as a backup to compare to in case this rare type of a bug happens, though it would have to take a program crash, and that is more rare as the plugins I have filed for repair are no longer crashing. I make a backup of my configurations just in case. – I suppose the same thing can be done for basic session configuration data – should there ever be a crash/corruption happening, the user can use the commands diff, etc… and maybe spot 1 or 2 things out of place…

IIRC I think erasing the plugin cache somehow had a positive efffect for a problem I was having regarding a session-load issue. You can remove ~/.cache/ardour5 which contains the plugin cache – and possibly also the ~/.config/ardour5/plugin_statuses file, and then see if your session is able to load. You would want to run a plugin-scan before loading that session of course (open a “blank session” and do a plugin rescan)-- and maybe by chance this can help.

It would be better if Ardour provided diagnostic tools to run against the session data folder to show where there is invalid data, as I think this can help for certain cases. I don’t think the auto-recovery would work correctly for all cases, and the user can apply their own fix along with the help of such tools. Currently I am not doing any large sessions, as I am still kind of learning bits of working with the daw, …though eventually I would like to learn of ways of doing recoveries that are better than what I have in mind of backing up basic session data from time to time and run a comparison test to see what configuration files may have gotten corrupted. I’m not sure why there are no such tools, I think it can be very good if such a tool was available.

hope this helps