dive
dive copied to clipboard
Kitware
[BUG] Undeletable dataset entry in dataset list
You should be able to use this button to resync the data in the folder and this will remove any lingering dead datasets:
Naive user isn't going to know that or it won't be obvious, instead of error condition on an unsynced folder maybe it should just remove them from list?
I think it would be reasonable to gray out or outright remove missing items if they're not on disk. The trouble is when DIVE should attempt to figure out that there was a change. We could put in some kind of inotify support or something but it would be a pretty complex change.
@BryonLewis, is there something small we can do to improve UX around this problem?
On launch we may be able to a quick auto sync with the dataset (For most people hopefully this is quick). Then on launching or trying to delete a non-existent dataset we can give them an option to sync, that way they don't have jump to a separate section of the interface to run it.
On launch we may be able to a quick auto sync with the dataset (For most people hopefully this is quick). Then on launching or trying to delete a non-existent dataset we can give them an option to sync, that way they don't have jump to a separate section of the interface to run it.
I like this approach.
I'm concerned about running this on launch. It's a disk crawl. Disk may be filled with lots of data or otherwise very low I/O such as a network mount. We know some people use a network mount like this. There's no way to know how long such an operation will take.
I thought there was a reason we didn't check it on launch. So maybe we provide the a button on failure to delete/launch because of missing data. Then we provide a mechanism for the user to exit out of the process if it is taking a significant amount of time?
Another tidbit of info, but when I press sync, the entries disappear from the current running instance of DIVE. However, when I reboot, they're still in the list and still undeletable.
I think I only had 1 that I was using at once, though not 100%.
As an alternative to potential large load issues, you wouldn't necessarily need to check every image file, just that the high level folders are there at least, or the first image file in each sequence. 99% of the time that would do it, at least for my use cases and that wouldn't be slow cause it's just a O(1) check for each video.