Hey there, I was working on a 30-second scene(24 f/s, about 600+ frames) for three hours when it got stuck on “rendering…” during a stretch effect and when I restarted, both recently saved projects(within five minutes of program error) report "unable to load “…3932/3935/3942/3945… is missing link…” and so on. multiple error codes for the same error, is there any way to fix this? I did plenty of skeleton deformations and they are all within the .sifz file.
The project files(sifz) that synfig can’t read are 15.6 kb, and a clean save is 396 bytes on my computer, so clearly there is a lot of data that synfig can’t read for one reason or another.
Is there anyone with a suggested fix?
Synfig files (.sif) are XML documents.
SIFZ is a “zipped” SIF file, so if you unzip yours, you may open it on a text (or XML) editor and try to check the problems…
What Synfig version and what OS?
heyo, Linux, Ubuntu 18.04.04, Synfig 1.2.2. Synfig has been much more stable overall since I updated, this is the first time I’ve had a crash that afterward have been unable to open previously stable saves.
I’m completely new to this, can you point me in the direction for what to look for in the XML and what might help me recover this project?
Thanks for getting back to me so quickly
The problem can be anywhere. The “missing link” can refer not only to bones, but to converters, messed up XML node, etc. I can’t give you any hint rather than go to line number Synfig is pointing out and see what can be wrong there. It’s what I do in similar situations…
Sometimes the structure can be messed up so badly that restoring it would require you to delete the majority of the work (like all the bones for example). If you provide the full screenshot, I might point something out.
Avoid autosave (in the Settings) and keep “incremental” backups during your work.
Especially with an old version like 1.22
Only a manual inspection could maybe save it
I made several incremental backups, I have seven versions of this file, but have been unable to load any of them after I restarted the app. I’m assuming the length of the clip and number of skeleton deformations have to do with the problem.
So I found the skeleton deformation corruptions in the .sifz file, and can delete them, but how can I resave the file as a .sifz file? It looks like LibreOffice Calc only
For example, you can open a plain-text editor (like Gnome Gedit, Windows Notepad, …), paste the XML contents and save as
In windows, you should write the file name with quotes to Notepad does not enforce the .txt extension: something like
Okay, thanks much. I’m using Ubuntu, I’ve been trying to save as an .sifz, but of course that’s zipped. I didn’t even try saving as .sif. I’ll try, thank you for your help.
Hey Bob, the Synfig homepage has the latest stable version listed as 1.22, I figured that was the latest version. The incremental backups didn’t seem to work between app instances, unfortunately.
Do you mean that the developer’s version is a better bet?
When I do this manual inspection, should I just delete the specific error code lines, or everything in between? thanks
A common issue is messing up the XML file while saving.
Another is defects in skeletons.
Some parameters can’t be accessed in 1.2.2.
The Sif format is not documented and varies with Synfig’s version (some layers/parameters are added, modified or removed)
Not even talking about problems of compatibility between libraries’ version (pixbuff background transparency/colors for example)
The last dev version is supposed to be closer of the next “stable” release, less chances to be stuck to an old buggy version while creating a new project.
All this is often discussed in the forums, it has nothing new
And that’s why IMHO it would be better to debug, stabilize and document instead of “expand” with new features introducing new bugs
Good idea, u/svarov helped me figure out how to debug my Skeleton corruptions in xml, so I’m going to just get better at that for now and try to limit the scale of my current animations with skeletons.
Thanks for getting back to me, have a good one.
That’s really annoying indeed. Should we start to doc on docs-dev?
By the way, I second partially @blackwarthog on this comment:
Maybe layers themselves should load/save/serialize/deserialize their nodes. Not a single function.
This would ease to deal the different versions of a layer and compatibility.
As you are way more used to Synfig code, could you please explain me what libraries and their issues you talk about?
I do agree Synfig must ‘be stabilized’. But some stuff was very outdated and pretty poorly usable for current days.
I’d vote for writing automatic (unit) tests to improve code and search’n squash bugs whether hidden or not. Actually, I proposed that here in forum. But I couldn’t make almost anything related, because there were (is?) many unused stuff in ETL headers and in Synfig core library, for example. And lots and lots of things on them I don’t understand. So, I would barely know how to test them
Nevertheless, I’d be glad to help on this: writing tests, documenting synfig classes in code, restore doxygen doc generation, … But, as I said, I couldn’t go alone as I don’t know the code as you guys know.