I have also tried this, and for me the ratsnests are also ok. @louigi600 , do you agree or do you see something wrong? If so, please, share some screenshots.
In this case, the only bug is that Fritzing should not allow to having two identical labels for a component.
@louigi600 , do you remember if you used the “Delete Ratsnest Line” command when you were wiring or doing the PCB? I wonder if that command is causing the error (under certain conditions) or if we can remove it from the things to check.
I don’t think this is likely in previous cases. They have typically been beginners, and made changes in more than one view but likely wouldn’t know about delete rats nest line (but unfortunately also don’t know what exactly they did to cause the problem!)
Regarding the simple circuit you may be right … I may have missed that it recalculated a new rats nest line which looks different but still does connect to the right places.
Unfortunately the project on which I noticed the problem came from an earlier one ant it had far too many changes to it to remember exactly which one might have initiated the problems.
Is there a way to load manually the data into a sqlite database so I can investigate in the corrupted file I have ? If I were a developer I could probably extract it from the sources … but I’m not so I will get lost in the sources.
@fai : no at some point , I forget exactly when, I upgraded from what was previously packaged in rpmforge (0.9.8) to a source built 0.9.9 and then switched back to rpmforge when they updated to 0.9.9.
I’m not sure if I had the corruption before … I may have pinpointed it later … and I remember having to do a major rewire before I noticed the corruption because of some other similar issue.
@vanepp : I do the wiring in the schematic view … but I may well have deleted a rats nest line from the pcb view at some point. I will surely avoid this in the future.
@fritzing_developers: I really wish these problems would be fixed because I’ve tried several free alternatives and for me Fritzing the most intuitive one I’ve tried so far. I don’t want to give up on Fritzing but I’m also reluctant on it because of this issue.
I have an idea … since pinpointing what is causing the corruption is difficult how about making a repair tool … how about making a tool that would recreate the connections on the corrupt view from the functional view.
In my case the schematis view seems to be still good: is it possible create a tool to recreate the pcb view connections from the schematic ?
First this is a rare problem (5 or 6 reported cases in 5 or 6 years) and typically hasn’t had a non corrupted view. Your .fzz is the first one I have seen that doesn’t have unwanted rats nest lines in another view (usually going somewhere utterly incorrect!) That said it should be possible (if not necessarily easy) to do this manually from the .fz file. I have been poking at the .fz file from your post and it appears the problem (as I have seen before) is that parts of some components have been partially but not completely deleted (there is an incomplete deletion of a wire in the D1 part definition in the .fz file for instance.) leaving the .fz file inconsistent. If I can figure out the parts that are in error, I should be able to delete the incomplete parts of the .fz file and that should allow me to load the modified .fzz file and proceed successfully from there. The difficulty is finding all instances of the corruption because the wire in the D1 part definition should also have a part definition elsewhere that references the connection to D1 (but that may have been deleted already!) In your case it is a large file, and I need to delete all the parts that are incomplete (or that may cause other problems later) which is likely to be difficult. It may also cause some previously working paths to be deleted if they are incomplete, but they can be re-added reasonably easily. I suspect this manual solution is going to be as much as can be done. I don’t think there is enough information available to make an automatic correction work (but I too am not a developer, so could be wrong there!) As well I suspect it isn’t a serious enough problem to have a high priority against new development and bug fixes because, as noted, it is a rare occurrence (although very annoying, which is why I have continued to poke at it over the years!).
I think that it is a high priority bug as it makes people to loose they work, but it is very difficult and time consuming to debug as it cannot be reproduced.
True, but as noted it doesn’t happen (or at least get reported) all that often. As noted I have been trying to reproduce it for 5 or 6 years now (with only 5 or 6 reports of problems over that time) so it isn’t very common and it is very hard to reproduce so far. I have some suspicion that it is a race condition, that two QT threads interfere with each other if the timing is just right and wires don’t get fully deleted causing the problem, but that is just a guess from what I have seen so far. Most examples I have consist of multiple changes (perhaps some that are not shown in the final result to make things even harder.) One case is fairly obvious, and I had high hopes for it, the user made a wrong assumption about how a part should connect (a voltage regulator custom part with ground where Vin should be and Vin on ground in schematic) and wired it backwards in pcb against schematic, but even then re doing what I think he did I haven’t been able to recreate the problem and the corruption isn’t in the part of the circuit where the error was made (or there was another change I’m not aware of.) I think all we can do is keep investigating these reports as they occur until we find a way to reproduce it, and we may never find that way, since it is usually beginners who don’t remember what they did . The ideal case would be for someone to notice it in an active sketch. At that point we could get them to use the undo /redo mechanism to figure out the sequence of actions that causes the problem (although as noted if it is a race condition even that may not help!) I’ve thought about writing the undo stack to the .fzz file on save so we could try that but that is likely to be a lot of work for not that much gain. Another part of the problem is that it usually shows up after the sketch is saved (I think anyway!) or at least that is when it gets noticed and reported usually.
For that to work you would have to notice in time and the undo would need to be also able to undo the database corruption (before images are kept somewhere ?).
If it is a race condition it is likely that even reproducing the same sequence of events will not reproduce the corruption as the threads may not be doing the exact same thing, relative to each-other, in the precise point in time where it needs to happen to recreate the condition.
On the other hand reviewing the locking mechanisms to prevent such events might be beneficial.
. The ideal case would be for someone to notice it in an active sketch. At that point we could get them to use the undo /redo mechanism to figure out the sequence of actions that causes the problem (although as noted if it is a race condition even that may not help!) I’ve thought about writing the undo stack to the .fzz file on save so we could try that but that is likely to be a lot of work for not that much gain. Another part of the problem is that it usually shows up after the sketch is saved (I think anyway!) or at least that is when it gets noticed and reported usually.