I’ve just tested out the new 3.3.1 release (Windows, AppImage HDFViewApp-3.3.1-win10_64-vs17.zip), having previously used the AppImage 3.3.0 without issues.
When comparing 3.3.0 and 3.3.1 side-by-side on the same computer, I see that 3.3.1 fails to open any actual NetCDF data, only giving me the following error message popup:
An error occured while loading data for the table:
failed to read scalar dataset: Can’t open directory or file
The text console in the bottom shows
*** Error: unable to load table data ***
Metadata information on all variables is still shown for those files, though (as far as I can tell).
When opening HDF5 files, I see that some variable data can be read as expected, but for some others it fails with the above error as well. So far I cannot spot why it works for some variables and not for others.
The exact same files and variables are all readable on version 3.3.0.
Could this be related to any VC runtime package missing? As far as I can tell they are all installed. Did I miss anything else that could explain this?
No, I cannot explain it as 3.3.1 fixed some issues that should allow additional combinations of datatypes to work. In addition, 3.3.1 did pass all our existing tests, so we must be missing a file of your datatypes.
Would it be possible to send us a sample file?
While I can’t share the original data I have been testing this with at this point, I have found at least one file which shows the same problem and is publicly available. It can be found here: ptcuo005457_2D_HOMO_notps_3energies.h5 - Peter Grünberg Institut – Quantum Nanoscience (PGI-3)
It is relatively small and only contains four variables. I can open all of them in 3.3.0 and none in 3.3.1. Hope this helps to narrow it down.
As for NetCDF: All version 3 files I tested seem to work, the problem is with the version 4 - and thus HDF5 files. So my best guess is that it’s the same problem.
Your file has the datasets compressed with gzip! I wonder if the windows hdf5 binary that we used to build HDFView on windows did not have gzip included.
Interesting! That would certainly explain why NetCDF3 still worked (no compression supported) and why most of our NetCDF4 and HDF5 fail, as they are usually compressed. I assume you’ll fix this in a new release?
I assume you mean 3.3.1 as this was never a problem with 3.3.0?
I also did not see any announcement and was still waiting for this to be fixed as well. The download page also does not seem to have any indication that something was re-released, so this is hard to keep track of.
I cannot confirm any fixes, unfortunately. I just downloaded all available 3.3.1 Windows Versions from https://www.hdfgroup.org/downloads/hdfview
All of the ZIP files show that the files were packed on Aug 23rd. This is well before I reported the problem here in early September, so those are likely no re-released files. To confirm I tested with HDFViewApp-3.3.1-win10_64-vs17.zip - the same I reported above - and I’m still getting the same error.
Can you clarify if those files were actually rebuilt and re-released and if, where?
Okay, we have had a breakdown somewhere in the process. I apologize for not doing the due diligence in making sure the updates were completed.
The updated binaries should have 9/26 dates. Of course the source and support files would keep the original dates of 8/23.
I will figure out the step I missed in getting them uploaded to the download site.
I guess it was the last step that was missed - unfortunately (we can only say the people involved were very busy) we can only learn from the mistake going forward.
So this is what I’m seeing right now with a fresh download of the files: HDFViewApp-3.3.1-win10_64-vs17.zip: 9/26 datestamp HDFViewApp-3.3.1-win10_64-vs16.zip: (?) 8/23 datestamp - but I never tested this, so I don’t know if it was ever a problem HDFView-3.3.1-win10_64-vs17.zip: 9/26 datestamp HDFView-3.3.1-win10_64-vs16.zip: 8/23(?) datetamp
I’ve only tested HDFViewApp-3.3.1-win10_64-vs17.zip further and can say that this runs with my test file now. From this I assume that at least the vs17 variants are OK now. Were the vs16 builds just not affected or did something go wrong in their re-upload? It doesn’t really matter to me, but it should be consistently working if possible.
The binaries need to have the 9/26 timestamp. This is because the hdf5 binary had missing compression libs. Once hdf5 binaries were reproduced, then the HDFView binaries were regenerated.
9/26 datestamp
(?) 8/23 datestamp - but I never tested this, so I don’t know if it was ever a problem