Loading of MRHead sample data set failed

Hello
I download 3Dslicer when i try to doawnload sample data the give me this answer
Requesting load MRHead from C:/Users/mima/AppData/Local/Temp/Slicer/RemoteIO/MR-head.nrrd…
Load failed!

Can one help me please

Hi!

Which version of Slicer do you use?
Can you copy any file to that folder? (i.e. is it somehow inaccessible)
Please send us the log: About / Report a bug.

Hi
I use 3D slicer 4.6.2

That version is quite old now, please use 4.8.1.

If the same thing happens with 4.8.1, then please:

Hello

  • I try with 4.9.0
  • Yes i can copy any file to that folder
  • I send you the log

Thanks for the answers and the log!

It seems that the file was downloaded halfway the first time and is in a corrupt state, that’s why it cannot be loaded. You’ll need to delete the file 'C:/Users/mima/AppData/Local/Temp/Slicer/RemoteIO/MR-head.nrrd’
and try again.

@pieper @lassoan Should we do this automatically when loading fails like this on a sample dataset?

That’s a good idea! Would you take a stab at implementing this?

OK I’ll give it a go. I implemented similar things recently anyway.

Yes, excellent idea! Thanks for looking into this. In other places we have used md5 sum checks as well, but redownloading on failed load sounds simpler.

@cpinter Maybe you should even add some check if the download directory is accessible and if not have a message box telling the user about the issue and maybe let them choose a location where to store sample data?

1 Like

Choosing the location might be an overkill, as the temp directory should be writable at all times, but I’ll add the check and the warning.

@cpinter Note that the sample data uses the cache directory which is already settable in the Cache page of the user preferences. So it is possible that it could be set to an invalid directory.

1 Like

If Sample Data uses the centrally set cache folder, then I think checking whether it’s writable should not happen in a module, but somewhere more central, like when setting that folder at startup. And because the same goes for DICOM database folder etc, this could be handled the same way for all these folders. Thoughts?

Fully agree, it should not be checked in a module.

The DICOM folder is checked when you switch to the DICOM module (not ideal, but in general you import DICOM using the DICOM module, so it is OK). However, temp and cache folder are not checked. This caused problems on some Linux systems, where earlier temp folder was not always initialized to a writeable location, but that problem is now fixed.

It’s not easy to figure out when and how the user should be notified about invalid temp and cache folders and they should happen very rarely, if ever. So, I think it is acceptable to handle this exceptional case by only logging an error and letting the user figure it out from that.

I was thinking the validity of the settings could be checked at application start time.

For the record, the re-download feature was added in

1 Like