CVPCB non-existing libraries cause a pile of existing libraries not to load properly

[Janne Kaikkonen]

Versions: 6516, 6608
Windows 10 64bit

Using unmaintained library list and therefore have deprecated now non-existing libraries in it causes CVPCB to fail load multiple actually existing libraries in "landslide" fashion. Libraries are all listed normally but some come out as totally empty which is not the case for existing libraries. Footprints are visible with pcb footprint editor.
Pattern of properly loaded and not properly loaded libraries is clearly visible in attachement screenshots marked with red and green dots. Red = failed, Green = loads properly.
Removing deprecated objects from library list releases earlier "empty" libraries for use so that all footprints are visible in the footprint list.

Also:
CVPCB fails to report all errornous objects all at once. Only 4 or so is visible. May be seperate problem or caused by the problem itself.

Related screenshots and files.
https://drive.google.com/folderview?id=0B2GcdpJiNGfKT3UydnlrOEI5dkE&usp=sharing

[Nick Østergaard (nickoe)]

I can confirm this behaivour. It seems to me like there might be an issue where the local fp-lib-table fails, then the libs from the global is never loaded.

[Wayne Stambaugh (stambaughw)]

The attached patch should fix the issue. There is an error limit which
bails out of loading any remaining footprint libraries in the load
footprint library code. Please test it to make sure it resolves the
issue. The only drawback to doing this is that if every library load
fails (for example all libraries are accessed via github and you have no
internet connection) and you have a large number of libraries, CvPcb may
appear to hang for a long time as each connection times out. That's
most likely why the failure limit is there. Unfortunately it has the
unintended consequence of ignoring any reachable libraries. If it fixes
the issue, I will commit the changes.

I'm also working on a progress dialog to keep the user informed of the
library load progress. This will be important in the case where many
github library load failures slow the footprint loading.

On 3/8/2016 6:04 PM, Nick Østergaard wrote:
> I can confirm this behaivour. It seems to me like there might be an
> issue where the local fp-lib-table fails, then the libs from the global
> is never loaded.
>

[Wayne Stambaugh (stambaughw)]

Has anyone tested my patch to make sure that is resolves this issue or if it causes the footprint loading to take too long when there are lots of errors?

[Nick Østergaard (nickoe)]

I have not yet had time to test it. But on a side note related to this, shouldn't the error dialog be with scroll able text, since many error makes the window go higher than the screen.

[Wayne Stambaugh (stambaughw)]

Yes, scrolling should be enabled because the error messages can be quite
verbose. If it's not, I'll make the change as part of this patch.

On 3/21/2016 11:37 AM, Nick Østergaard wrote:
> I have not yet had time to test it. But on a side note related to this,
> shouldn't the error dialog be with scroll able text, since many error
> makes the window go higher than the screen.
>

[Wayne Stambaugh (stambaughw)]

I committed a fix for this in the product branch r6676. Please test this to confirm that it fixes this bug. I tested it on windows and it seems to work correctly. At least good footprint libraries are loaded. You may end up with a very large error message depending on the size of your footprint library table and the number of load failures.