CTRL-C clipboard delay for media files (file extension-based, reproducible)

[White Knight]

Hello OneCommander team,

I’d like to report a reproducible performance issue related to copying files to the Windows clipboard (CTRL-C).

Observed behavior:
When pressing CTRL-C on files with common media extensions (e.g. .mp4, .avi, .mkv), there is a consistent delay of ~1–2 seconds before OneCommander reports that the file has been copied to the clipboard. During this time, the UI briefly feels blocked.

Expected behavior:
Clipboard copy (CTRL-C) should complete instantly, as it does for non-media files.

Important details / reproduction steps:

1. Open a folder containing two files:

   • One non-media file (e.g. .txt, .zip)

   • One video file (e.g. .mp4)

2. Select the non-media file → press CTRL-C → clipboard copy is instant

3. Select the video file → press CTRL-C → noticeable 1–2 second delay

4. Rename the same video file to a non-media extension (e.g. .mp)

5. Press CTRL-C again → delay disappears

Additional notes:

• File size does not matter

• Disk type does not matter (SSD/HDD)

• Encrypted volumes are not involved

• Drag-and-drop copying does NOT show this delay

• The delay appears to be triggered purely by the file extension

• Copying folders (even those containing video files) is instant

This suggests the delay may be caused by synchronous media metadata/property handling during clipboard population, rather than actual file I/O.

Given how fast OneCommander is otherwise, this small delay stands out in daily CTRL-C / CTRL-V workflows.

Thank you for the excellent work on the project — overall performance and usability are fantastic. I hope this report helps narrow the issue down quickly.

Best regards,
James

[OneCommander Support]

Hi James,

Do you have Google Drive installed? I was able to reproduce your scenario exactly with video files, but then I killed all Google Drive processes in Task Manager and the delay completely disappeared. Please let me know if see the same behaviour. 

This is my go-to thing to terminate whenever Windows is slow with clipboard, context menu or stalled file operations, and it almost never fails to be the culprit.

[White Knight]

Hi,

thanks again for taking the time to look into this and for confirming that you were able to reproduce the issue — I really appreciate that.

I wanted to follow up with a consolidated summary of my testing, because after quite a bit of investigation I think there’s a clearer picture now of when and how the lag occurs, and why it’s inconsistent.

///Short summary

• This does not appear to be hardware-related.

• This does not appear to be version-specific (tested portable versions back to 2022).

• The behavior is session-state dependent and can become “latched” until OneCommander is fully restarted.

• A clean boot significantly reduces the likelihood, but does not eliminate it entirely.

• The issue is strongly correlated with media file interactions (video formats extensions only).

///What exactly lags

Only for video files (mp4, avi, etc.):

• Ctrl+C (copy to clipboard) causes a 1–2 second stall

• Right-click (context menu) causes the same stall

This does not happen with:

• Non-media files

• Audio files

• Image files

• Drag-and-drop copy operations

• Windows Explorer (same system, same files)

Renaming a video file to a non-video extension immediately removes the lag, which strongly suggests extension-based shell handling rather than file size or I/O.

///Session behavior (very important)

Once the lag appears in a session:

• It persists for the entire lifetime of the OneCommander process

• It does not recover on its own

• Only a full exit from the system tray and restart clears it

Simply closing windows or tabs is not sufficient.

///“Priming” workaround (reliable but non-obvious)

There is a reproducible workaround that prevents the issue for the entire session:

1. Start OneCommander fresh.

2. Immediately perform several Ctrl+C operations on non-media files (let the notifications "populate").

3. After that, media files remain fully responsive (Ctrl+C and right-click are instant).

4. This remains true until OneCommander is fully exited.

If the priming step is skipped and the first interactions are with video files, the lag is much more likely to appear and then remain for the entire session.

If priming fails, restarting OneCommander is required — further attempts within the same session do not help.

///Clean boot findings

• With all non-Microsoft services disabled, the issue becomes much harder to trigger and sometimes does not appear at all.

• However, I was still able to trigger it once after window focus changes, after which restarting OneCommander again cleared it.

• This suggests a race condition or shell interaction issue, rather than a single specific third-party service.

Note. I do not use Google Drive nor any cloud related services software on these machines.

///Additional observations

• I typically use classic single view, often with two OneCommander windows open and "snapped" in place.

• I usually launch OneCommander via hotkey (winkey+alt+e) or taskbar (winkey+1) - not via mouse.

• Launch/restore behavior seems to matter: restarting cleanly from the tray reduces the likelihood compared to restoring an existing instance.

///Test environments

• High-end workstation (Windows 11)

• Older laptop (Windows 10)

• Identical behavior on both systems

Test machines specs:

Workstation: Windows 11 Enterprise 24H2 26100.7462, i9-14900K, 128GB RAM, RTX 5070 GPU, SSD (I did connect HDD for test to USB once, but it doesn't seem to be relevant).

Laptop: Windows 10 Enterprise LTSC 21H2 19044.4894, i7-4710HQ, 12GB RAM, GTX 850M GPU, SSD

///Hypothesis (for context)

From the outside, this looks like a session-initialization or shell/clipboard interaction issue where:

• Media-specific shell handlers are involved early

• An unfavorable first interaction puts OneCommander into a slower code path

• That state persists until process restart

I hope this breakdown is helpful and gives you a clearer, more actionable picture.
If you’d like me to run any targeted tests or gather additional diagnostics, I’m happy to help.

Best regards,
James

[White Knight]

  Hi again, just a heads up, I’m still testing the issue and may have found a workaround related to certain background services. I want to verify it over the next day or two before sending full details, but I’ll update you once testing is complete.  

[White Knight]

Hi,

I wanted to share some additional findings after spending quite a bit more time testing the issue in detail.

Sadly I failed to find a long term workaround and was only able to find ways to delay the issue. Here are my findings.

1. Third-party software influence:
I confirmed that disabling certain background software, such as Daemon Tools and a VPN client, noticeably delays the onset of the issue. It doesn’t remove it entirely, but it makes it occur much less frequently. This may explain why disabling Google Drive helped you earlier — anything that hooks into the shell or file system seems to increase the likelihood of triggering the slowdown.


2. Preview and view layouts:
I tested every available layout (Classic, Dual, Standard) and toggled the preview pane. None of these affected the issue. Hiding the preview doesn’t change behavior, which suggests that the preview subsystem is still active in the background.


3. CPU affinity / threading tests:
Restricting One Commander to a single CPU core does not prevent the issue; in fact, it slows everything down further. That points to something blocking the UI thread rather than a hardware or scheduling quirk.


4. Folder enumeration with video files:
I discovered that when a folder contains many video files, opening it becomes dramatically slower — sometimes taking several seconds if "sort by media duration" is chosen.
The interesting part: if the folder is sorted by media duration, the delay is extreme, but sorting by name restores normal speed instantly.
This strongly suggests that the slowdown is related to how One Commander reads or queries media metadata (duration, codecs, etc.) for sorting or preview purposes. It might be a blocking metadata handler call or a shell extension conflict.

Note. Point number 4 is more of a sorting by metadata issue, but I'm including it here as it may or may not be related.

5. Overall pattern:
Non-media files are unaffected. The issue seems tied to One Commander’s interaction with Windows’ media property handlers, which may get stuck in a blocking state after certain shell extensions or services have been active in the session. Once this state appears, performance remains degraded until One Commander is fully restarted.


At this stage, I can reproduce the problem consistently enough to believe it’s somewhere in the metadata / media-handling layer.
Disabling shell-integrated tools only reduces the frequency but doesn’t eliminate it, which means the root cause likely sits in how One Commander queries or caches media attributes.

Hope this helps narrow things down.
Let me know if there’s anything specific you’d like me to test further.

Best regards,
James

[OneCommander Support]

Hi James,

4. is expected. To sort by some property, data has to be avaialble. Properties like size, name, date, type are filesystem properties and OC gets them for free while enumerating files, so that's why it is instant. Metadata like duration go through slow Windows COM, so until it is extracted for all files and all the data is ready, UI can't sort files (in theory it could do this asynchronously and thel live-sort files, but then it would keep shuffling files for a few seconds while each one is extracted and file moved into the next-correct place, which would be worse and slower)

The way shell extensions work is roughly that on each context menu open, the Windows has to initialize COM server for each registered shell extension and these then are loaded as part of OC process. If COM server doesn't turn off after providing menu item, then it keep slowing down OC. Due to the nature of COM and all the duct-taping that is Windows shell extensions system, there is no way around it. I didn't drill yet into how the Windows chooses which shell context menu extension to initialize (I suspect it chooses which to start according to file type), but somewhere in registry there is a pointer for mp4, for example, which tells which shell extensions should test if they can handle the file (it loads their COM server and it either is added to shell context menu or not). Even if I find that, I doubt there is a way to get context menu items without triggering all the COM servers for that extension, and if there is, I am not sure if it is worth trying, as there will always be some extension that polutes the menu. Loading each individually and measuring each execution time, trying to figure out if it shuts down or not, is just not worth it even if it ends up being possible. Clean system doesn't have that issue so it is up to finding what extensions are badly written. This is all independent of file metadata, so all is on Windows side.

[White Knight]

Hi,

Thanks for the detailed explanation — I understand and largely agree with your description of how Windows shell extensions and COM servers behave, and why this is fundamentally hard (or impossible) to fully control from an application side.

Just to clarify one thing on my end: I’m completely fine with sorting by duration being slow — that behavior is expected and avoidable by simply changing sort order. That part is not my core issue.

The real, workflow-breaking problem for me is the Ctrl+C / right-click context menu delay on media files, because that path is unavoidable when working with hundreds of video files daily. Once the slowdown starts, the only workaround is restarting OC, which makes it impractical for longer sessions.

Given your explanation, I’m not asking OC to outsmart or “fix” Windows shell extensions. Instead, I wanted to suggest a possible user-level escape hatch:

Would it be feasible to offer an opt-in mode (global toggle, restart required is fine) that treats selected file types — e.g. video/audio — as generic files for shell interactions?
In other words:

• no preview handlers

• no metadata/property extraction

• minimal or bypassed shell context handling where possible

Essentially a “fast / safe mode for media files”, trading integration for responsiveness and stability. For users like me, this would immediately make OC workable again without requiring you to solve the underlying COM mess.

If scope is a concern, I could even see this as a PRO-only / power-user feature — I’d happily pay for it, and I suspect others dealing with large media libraries would too. Even a coarse implementation would already be hugely valuable.

Totally understand if this doesn’t align with your goals — I just wanted to float the idea since it avoids the hardest parts of the problem while giving users back control.

Thanks again for taking the time to explain things in detail and building this amazing software.
Best,
James