Preview mp4 works not after moving the file in other folder

Hello, a very strange issue I found.

The Preview (F7-plane) of a mp4-file works. Then I copy the file in an other folder - here it does not work - I see only a back area. When I move the file back on the first folder it works here again.
The original folder is the automatic Camera Upload folder from my dropbox. Here I get the new photos from my Android phone. The second is an other where I sort in the file.

Any ideas ?

Is the same true using File Explorer's viewer?

What about when double-clicking the file after copying it?

Is there anything special about the target folder? e.g. NAS device, or unusual characters in the name? (Opus shouldn't mind either, but some video playback components might.)

I am not very familiar with the explorer - always use Dopus :slight_smile:
Ok, I have checked it: Here I see in the preview a film frame with a static picture (first or so). The explorer has no playing in the preview plane.

After double-clicking the responsible program from windows open an plays the film correctly.

I tested more. It seems that on drive C: all works. The whole local drive D: does not work. Both are SSDs - C: -Window System D:Data. D: has the name "Volume".

Exists a Windows/Dopus-setting for drive D that prevents the playing in the preview ?????

It's probably not anything within Opus, but something wrong with the video codecs/splitters on your syatem.

If Explorer won't play video at all then something definitely seems broken in that department. (Unless we're talking about a fairly obscure video format, but then Explorer would not show thumbnails either.)

Have you installed any codec packs or similar? Some are better than others and few are really needed these days as Windows has a lot built in.

Should the explorer play video in the preview plan. Has it this feature ? I think not.

I will point again to the fact that the SAME video works on Drive C and NOT on Drive D with Dopus. Not in the preview plane and not with Diashow function.
So I cannot believe that it has something to do with codec.

I have tested more
Network-Drive -> works
USBStick -> works
I have 2 USB-Drives for backups (NTFS two different drive letters): One works the other not. !???

How can it be dependent on the drive ?

Supplement - found more.
I was able to play the file after renaming. Dopus does not like Spaces in the file-name (and that only on drive D !?)

Explorer certainly used to preview videos, and the Windows Media Player preview handler still exists and works in Opus if I enable it, but you're right, in Windows 10 the preview pane in Explorer no longer plays videos for me, now that I check.

Unless it's been broken by something I have installed that changed the filetype/registry settings, which is possible. (We use the same settings in Opus, but have fallbacks in case they are missing, as things often break them.)

Getting back to Opus:

Something to try is using a different viewer for videos in Opus:

  • Preferences / Viewer / Plugins
  • Disable the Movie plugin
  • See if that's enough on its own. If not...
  • Configure the ActiveX + Preview + Office + Web plugin
  • In the Preview Handlers section at the top, turn on Windows Media Player:

Sorry that I answer so late - I had to do a lot.
I checked all - nothing works.
The main problem stays:
A perview of a mp4-file with a space in its filename works only on drive C: not on dirve D: .
This should/must be a bug in Dopus. This looks (without knowing something about the code) as if maybe in the command-line-paramer what calls the prviewer is a " " bracket missing. Dont know why this is for C and D different. Can this be ?

There is no command line involved in playing videos in the viewer pane, only COM objects and the video codecs/splitter DLLs on your machine.

Some COM objects don't cope well with spaces in names so Opus will try to send a short file path to them (8.3).

If you have disabled short paths on your D:\ drive then that might explain why things work on your C:\ drive but not the D:\ drive. A lot of things still depend on short file paths for interop/compatibility reasons, such as this. (It's not something we want to use, and if it's not available we don't use it, but it's something you need for some components as they do not work properly otherwise.)