DOpus.LoadThumbnail vs OneDrive

Depending on file type, DOpus.LoadThumbnail(fileItem) is very slow (10+ seconds) when fileItem is located in a OneDrive folder, whether or not the file is locally available. Some file types are fine - e.g. .txt - but others such as .xlsx or .exe or .pdf are not. I have resorted to using DOpus.LoadThumbnail(fileItem,nnn) to give up after nnn milliseconds but am hoping that this is a bug rather than a limitation. There is no delay when accessing the same files from a Synology Cloud folder.

What happens when viewing the same files in Explorer in thumbnails mode?

They all show instantly. The same is true with DOpus when viewing in a lister as thumbnails.

It's not just because the script cause the thumbnails to be cached, so they're fast to load the second time, is it?

No, and it's consistent across two PCs. Opus and Explorer both show the thumbnails instantly. DOpus.LoadThumbnail(fileItem) also returns thumbnails instantly in all other folders I have tried. In the case of OneDrive folders the speed of thumbnail being returned varies by file extension but is very slow for many different filetypes which are returned immediately if the script is run against the same files which have been copied to a non-OneDrive folder.

DOpus.LoadThumbnail was causing offline files to be downloaded to generate their thumbnails.

In the next update, we'll change it so it requests thumbnails for offline files via OneDrive (etc.), similar to what the lister itself does.

1 Like

Aha. That explains it, and I expect it is file size, rather than extension, that drives the delay. TIA for the fix.

1 Like

Just FYI, there is an issue with OneDrive whereby thumbnails for videos are not displayed whether or not the video concerned has been downloaded and is available locally unless the Files On-Demand setting in OneDrive is unchecked. This is not an Opus issue because the same applies to thumbnails in File Explorer. It is simply a PITA that we have to live with until MS decide to do something about it. Whilst unchecking Files On-Demand eliminates the issue it also means that 100% of your OneDrive content is always downloaded locally which may be okay if you are in the fortunate position of having no concerns with either bandwidth or local disk space.

Dopus 12.22.1b implemented the following change to DOpus.LoadThumbnail

  • The DOpus.LoadThumbnail scripting method now requests thumbnails from OneDrive (etc.) for offline files, instead of causing the files to be downloaded for thumbnail generation.

This change works perfectly for everything else I have tried but not for Office files (.docx, .xlsx) on OneDrive, whether or not they are available locally. The attached test button cycles through selected (or all) files and either loads an image preview or a thumbnail for non-image files. By default, it allows up to 500ms for a thumbnail to load. On my system I have to increase the delay to 12500ms in order for Word or Excel thumbnails to appear. Other thumbnails (.txt, .zip, .pdf) appear instantly and in non-OneDrive folders Office file thumbnails also appear instantly.

Test code is appended for info. The .dcf file contains the relevant dialog template. Increase the delay by selectively uncommenting the var msThumbLoad = nnnn statements.

LoadThumb.dcf (5.1 KB)

// Global variables
var dlg = DOpus.dlg, msg_obj;
// Button code
function OnClick(clickData)
{
	// --------------------------------------------------------
	//DOpus.ClearOutput();
	// --------------------------------------------------------
	var cmd = clickData.func.command;
	cmd.deselect = false; // Prevent automatic deselection
	// --------------------------------------------------------
	var currTab = DOpus.listers.lastactive.activetab;
	var candidates = (currTab.selected_files.count===0) ? currTab.files : currTab.selected_files;
	if (candidates.count==0) return; // No files to process
	// --------------------------------------------------------
	dlg.window = DOpus.listers.lastactive; // Lock the dialog to the active lister
	dlg.template = "dlg1"; // Set the correct dialog template
	dlg.detach = true;
	dlg.title = "LoadThumb Test";
	dlg.create;
	var n = 0;
	loadNextFile(candidates(n++));
	// --------------------------------------------------------
	do{
		msg_obj = dlg.getmsg();
		if (msg_obj==false) break;
		if (n==candidates.count) n = 0;
		if (msg_obj.event=="click") loadNextFile(candidates(n++));
	}
	while (msg_obj);
	// --------------------------------------------------------
}
function loadNextFile(currItem)
{
	// --------------------------------------------------------
	var isImage = (currItem.metadata=="image");
	var rotItem = (isImage) ? currItem.metadata.image.rotation : 0;
	var rotAdjust = (typeof rotItem=="string") ? 0 - rotItem : 0;
	var msThumbLoad = 500;
	//var msThumbLoad = 5000;
	//var msThumbLoad = 10000;
	//var msThumbLoad = 12500;
	dlg.Control("grpPreview").label = currItem;
	if (isImage) {
		if (rotAdjust!=0) dlg.Control("staticImage").visible = false;
		else dlg.Control("staticImage").label = DOpus.LoadImage(currItem,400,400);
		dlg.Control("staticImage").rotate = rotAdjust;
		dlg.Control("staticImage").visible = true;
	}
	else {
		dlg.Control("staticImage").rotate = 0;
		dlg.Control("staticImage").label = DOpus.LoadThumbnail(currItem,msThumbLoad);
	}
	// --------------------------------------------------------
}

How long do the same thumbnails take to generate in the file display?

Is it the same in Explorer?

Instantly in both Dopus (12.23.1b) and Explorer.

Do you actually see a thumbnail for Excel files in OneDrive folders? Not just a large icon but a thumbnail of the file contents?

I don't see any here. Behind the scenes, the thumbnail request always takes a long time and eventually times out (OneDrive never seems to actually return a thumbnail, unless it is taking an extremely long time). This is somewhat hidden from you in the file display, since it will show an icon and request the thumbnail in the background. But if a script calls LoadThumbnail, that will block the script until the thumbnail either loads of times out.

@Leo
I had, apparently incorrectly, assumed that the large icon was a thumbnail. What happens with an insufficiently long LoadThumb delay is that nothing shows - i.e. no associated icon appears. Any residual thumbnail in the label field is eventually replaced by a blank label when the delay expires.

When the delay is long enough, which on my test system is around 12 seconds, the relevant Excel or Word icon is eventually displayed. In a non-OneDrive folder the icon displays immediately.

Have you checked the Office-specific settings in the OneDrive client? You can ask it to handle Office-filetyps differently in order to do concurrent work with several users. Sorry, running this in German, but you will find that setting easily:
image

Thanks for the suggestion which was certainly worth a try but it didn't make a difference. :slightly_frowning_face: I tried it with both options under Sync Conflicts.

image

This is caused but what I can only assume is a bug in OneDrive, where when we ask it for a thumbnail for these documents, it returns a result code that means "thumbnail is pending, please wait" - and so we do, until the timeout, after which time we stop waiting and return a large icon instead.

In the next update we'll add a flags argument for DOpus.LoadThumbnail which will let you tell it not to wait for retrieval of a remote thumbnail - if the thumbnail can't be generated without waiting it'll return immediately with a large icon.

2 Likes

Excellent @jon. Thanks for this. As I have discovered through further testing it's not just Office documents. Opus .dcf files and .url files also behave the same way and there are probably other file types I haven't encountered yet. The only thing they seem to have in common is metadata type = doc but other type = doc files such as .js and .pdf work just fine.

I have tested this change with 12.23.2. It works well in conjunction with a short delay. e.g.

DOpus.LoadThumbnail(someFileItem,200,"ic")

On my test system a delay of 175ms or more is needed for reliable large icon loading, when required.