Another project ruined by the new EESCHEMA

Tried to access one of the old projects just to find that every symbol in the schematic was replaced by the dreaded square with a question mark inside. Not sure at what point this happened but last time I opened it everything worked just fine.

The reason for that is all of the symbols were renamed. Let’s say original symbol name was “R” residing in the library called “Device”. Now the name of this symbol is “Device:R” and it is being pulled from “Project-name-cache” There are variations as well. Using the same example some of the symbol’s names became “Project-name-rescue:R-RESCUE-Project-Name” and again it is in the “Project-name-cache”.

Any suggestions as to how I can rename all the symbols without going through every single one and renaming them by hand?

I use nightly builds normally. Going back to the release version didn’t help the situation.

Hi ArtG-

Before remapping, Eeschema will make a backup of your project. You should be able to revert to the previous version by copying those files over the re-mapped versions.

This sounds like the remapping did the correct thing. Is there a symbol called R in the Device lib? If it is then it is quite strange that you get a question mark. If not then the symbol should have been rescued. (Meaning it should have been copied from the cache lib to the rescue lib and the remapper should have added that instance instead.) You could try to place a new instance of the symbol and compare if it is stored the same way in the schematic file as the one that is now a question mark.

What do you mean with ‘pulled from cache lib’?

The same thing happened to me a few days ago, basic R and C became boxes. Maybe a bug has crept in to the Nightlies?

I guess if anyone is motivated, they could set up a Continuous Integration test suite for nightlies (a lot of work, but could be very useful for catching simple regressions).

Otherwise we are relying on the Mark I Eyeball to catch bugs…

There is no backup. All I see in the rescue-backup folder is a sym-lib-table file, project file, and project rescue library file.

I used R as an example for simplicity. ALL my symbols are missing and turned into squares. And yes they are still there in the library. The reason they are not coming up is because now they are all renamed.

I mean that now they are not being “populated” from the correct library, but instead are now residing in cache.

I was able to restore two separate projects both of which were corrupted (haven’t tried to access the other ones yet :scream:) What i did was:

  1. Open every schematic file with a Notepad++ and do search and delete for the “-RESCUE-Project-Name” and “Project-Name-rescue:”.
  2. Then downgrade KiCad to the release version and open the schematics. The nightly version of EEschema still can’t open the files correctly even after this step.
  3. Add all the libraries used in the project.
  4. Restart EEschema. At this point all the symbols were populated from correct libraries and all represented correctly.
1 Like

Yes it ruined several of my projects in a same way, what a pain, i am not touching latest nightly!
Now i have to rescue all these schematics manually, what a pain… my nightly Version that made this mess: (5.0.0-rc2-dev-20-g55edf1aad) BZR9613

Has anybody made a bug report about this?

Maybe with a minimalistic schematic that gets indeed ruined by remapping with the newest nightly? (Such that the developers have a testcase.)

I reported it with link to this forum thread.

Care to link the bug report here as well?

Sure https://bugs.launchpad.net/kicad/+bug/1759878

1 Like

Has anybody a project setup that reliably triggers the bug?

You work with nightlies without making at least a daily backup.zip of your project? You almost deserve what’s comming to you.
I used to proceed backup names with the ISO8601 date. That way they allways show up in the right order on the backup drive on the other disk.

I’m slowly getting used to Git now, which probaby is a better option, also for KiCad projects.
I love ascii based file formats :slight_smile:

I just tried a small 4.0.7 project and that remaps into V5 rc smoothly.
I now suspect that this is a V5 from a few months ago to V5 rc issue

I’m used to keep stuff on dropbox (for sharing/colab. purpose as primary reason) which takes care of that for me natively and i can recover all of the old versons in detail, but in this case project was local and being used to recover with no problem diving into file history on DB, got caught…

I just checked a copy of a project that was prepared for remapping with a nightly before symlib table (not touched by later version). The project remapped perfectly as before. Also already remapped projects opened perfectly.

Things to consider: Did library locations change or the reference to it? For instance with a Windows version, if the library is located under the user home directory but KiCad accidentally was installed with the environment variable ticked on (as per default), the environment variables will override KiCad settings and it will not find the right library location when KiCad is restarted. There might also have been some reorganization of the new official library lately. Personally I prefer not to have any refences directly to it (except the power library), but make copies as needed for my custom libraries.

If the rescue of a symbol changes symbol name to ProjectName-rescue:OriginalSymbolName-RESCUE-ProjectName, it indicates that a pretty old nightly is used. From early March only the library name is added, so the symbol reference will be ProjectName-rescue:OriginalSymbolName in response to bug report #174175. I just checked two backed up untouched projects (one from 4.07 and one from an old nightly) that had broken links to the libraries in the state before they were prepared for remapping but had intact cache libraries (I reorganized my library locations at that point) and they both remapped to the rescue library derived from the cache and kept the symbol names intact.

I used Windows version 5.0.0-rc2-dev-420-gf42ca89bb, release build for testing (downloaded from the Jenkins server yesterday as the official download site by some reason seems stuck at the April 9 version).

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.