Cannot open UNC path from command line

[Unobyte]

I try to open an MP4 video on UNC share \\MYSERVER\TheShare\br.mp4 from Windows Exprorer "Open with" context menu and Avidemux reports "Could not open the file".

Opening this file from File->Open menu, when I search for the share manually, happens just fine.

[eumagga0x2a]

Do you refer to a MinGW or to VC++ build (it should be the latest nightly)?

(Not that Windows Explorer integration has high priority, but maybe someone gets interested in looking into it)

[Unobyte]

The installer file is named *VC++64bits.exe

[eumagga0x2a]

I tried and failed to reproduce the issue with both my own MinGW build off git master and the latest official VC++ nightly. In both cases I had to create "Open with" Windows Explorer context menu entry for Avidemux by pointing to respective executable. After that, I could open MP4 videos on my share via "Open with" --> "avidemux.exe" without problems.

The only obvious difference is that my share is referenced by its IP address only.

Please provide more information about the issue, starting with admlog.txt from an attempt to open a MP4 file on your share in Avidemux via Windows Explorer context menu.

[Unobyte]

How to make it write admlog.txt again? Last write date of this file is 5 years ago.

[eumagga0x2a]

admlog.txt in %localappdata%\avidemux is created or overwritten each time Avidemux runs. You must be looking at a wrong location (like %appdata%\avidemux).

[Unobyte]

Please, take the log file from the attachment. This file contains only this failed event.

[eumagga0x2a]

First of all, please retry with just released Avidemux 2.8.1 – both VC++ (Avidemux_2.8.1 VC++ 64bits .exe from here or from FossHub) and MinGW (r220917).

Regarding the log, it turns out to be that Avidemux unfortunately doesn't log file errors, i.e. if ADM_fopen(const char *filename) fails, there is no trace in admlog.txt whatsoever. But VC++ and MinGW builds use different implementations of ADM_fopen(), so that while one flavor of Avidemux fails, the other one might work.

Just in case, does removing the space in the filename "Relaxing Fireplace.mp4" --> "RelaxingFireplace.mp4" have any influence on the outcome?

[Autopilot]

I encountered the same problem in version 2.8.1.
avidemux_2.8.1 r220917_win64.exe
Avidemux_2.8.1 VC++ 64bits .exe
avidemux_r221002_win64Qt5_144.zip

I open files through the application menu (File -> Open) and select a file from the network drive \\shared\c\any.mp4

But previous versions of 2.8.0 opened files over the network without errors!
avidemux_2.8.0_win64.exe
Avidemux_2.8.0 VC++ 64bits .exe

[sauv0168]

My problem started after installing these updates: Win11 22H2, KB5017271, and KB5017389.

The files work if copied to this PC before sending it to Avidemux but directly from the network path provides "Could not open the file".

I tried installing the latest nightly build 2.8.2.

[ThomasPGH]

No matter what I try to open a file, the error message is always cannot open file.
\\server\d$\folder\...

Neither drag and drop nor opening from the menu.

The only thing that does work is when I have the folder open in Explorer I can open every file with Avidemux, i.e. the shell's open verb works (Open with Avidemux). That's annoying if you want to convert a bunch of files with the same settings, though.

[ThomasPGH]

Just had a look at https://www.avidemux.org/admWiki/doku.php?id=build:compiling_avidemux .

Is there a better (i.e. easier way) to build Avidemux on Windows for debugging?

[eumagga0x2a]

The instructions in the Wiki are entirely obsolete, applicable to 2.5.x at best.

I haven't mastered native build with Microsoft Visual Studio, which is the precondition for being able to create debug builds. However, cross-compiling is quite easy, and as far as adding a few printf to the code is enough to analyze an issue, it is the only way to go at the moment.

https://github.com/mean00/avidemux2/blob/master/cross-compiling.txt

[eumagga0x2a]

Today I tried opening a file located on a SMB network share via "open with" context menu entry of Windows Explorer and pointing to location of avidemux.exe, which has worked just fine on Windows 10 22H2.

This means that I cannot investigate the problem as it indeed seems to be specific to Windows 11 with KB5017389 looking like a possible culprit.