HDFView 3.3.1 regressions

Hi all,

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?

Thanks for getting back to me!

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.

They are just floats. Could it be a windows vs linux issue 64-bit floats as the file opens on my fedora linux.

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.

1 Like

Yes I just verified that the compression libs are missing in the windows binaries for hdf5.

1 Like

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?

Once we figure out why - absolutely!

Any update on this fix? We are also suffering from the same issue where we are stock unable to open tables compressed with GZIP on windows.

I thought we had announced this.
There have been updated 3.3.0 release files for quite awhile. Check the HDFView download site.

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.

Yes I meant 3.3.1. I’ll take the blame for that, as I should have followed up.

There were no source changes as it was a build configuration issue, so we just rebuilt the binaries, after fixing the configuration.

1 Like

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 just reinstall the HDFView-3.3.1-win10_64-vs17.zip binary, the problem is gone on my side, appreciate the work, thank you very much.

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.

Thanks for your work and help in any case!

So this is what I’m seeing right now with a fresh download of the files:
HDFViewApp-3.3.1-win10_64-vs17.zip: :white_check_mark: 9/26 datestamp
HDFViewApp-3.3.1-win10_64-vs16.zip: :x:(?) 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: :white_check_mark: 9/26 datestamp
HDFView-3.3.1-win10_64-vs16.zip: :x: 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.

Binaries with correct timestamps are available at Index of /ftp/HDF5/releases/HDF-JAVA/hdfview-3.3.1/bin. The binaries in https://www.hdfgroup.org/downloads/hdfview/ need to be reviewed/replaced.