lister not showing avif images with spaces in the filename

[pi.degroote]

I did the following test :

On drive D : everything works.

On drive C :
Only this works: c:\Intel\Cursed_Programming_Sticker_Sheet-il_fullxfull.3601476621_nj57.avif
(without any spaces, but with long filenames)

These instances do not work :
"c:\Intel\Cursed Programming Sticker Sheet - il_fullxfull.3601476621_nj57.avif"
"c:\Users\User Account\Pictures\Cursed Programming Sticker Sheet - il_fullxfull.3601476621_nj57.avif"
"c:\Users\User Account\Pictures\Cursed_Programming_Sticker_Sheet-il_fullxfull.3601476621_nj57.avif"

[petermad]

I can reproduce it on all my drives for AVIF files with spaces in the name.

It only affects Lister when using IrfanView - the same file (with spaces in the name) opens fine with the Imagine plugin.

The same file also opens directly in IrfanView - also If I pass the path/name of the image without quotes.

If I replace i_view64.exe with xnviewmp.exe in Listers settings, the file is displayed in TC without problems (I cannot test with xnview.exe since it does not support the avif samples I have).

So it is hard to say whether it is a bug in TC or IrfanView.

[white]

On drive C :
Only this works: c:\Intel\Cursed_Programming_Sticker_Sheet-il_fullxfull.3601476621_nj57.avif
(without any spaces, but with long filenames)

I speculated that the AVIF.dll plugin might expect short filenames in this case. That doesn't mean that the plugin wouldn't work with long filenames without any spaces, but that it doesn't expect spaces in the filename.

[petermad]

I speculated that the plugin might expect short filenames in this case

I thought of the same, but most people only have support for short filenames on drive C: and that is where it does not work for pi.degroote in contrast to his drive D. where it is less probable that he has support for short filenames.

[pi.degroote]

Please note that I believe it has only to do with spaces in the names of the files and/or paths, since I did those tests with long filenames and folder names.

[white]

I speculated that the plugin might expect short filenames in this case

I thought of the same, but most people only have support for short filenames on drive C: and that is where it does not work for pi.degroote in contrast to his drive D. where it is less probable that he has support for short filenames.

You are not getting what I am speculating. I am speculating that Irfanview normally passes short names to its plugins whenever possible. Of course it cannot do so if there are no short names available, so it sometimes passes short names, sometimes long names. The plugin for Irfanview works when Irfanview is used in the normal way, so the plugin can handle long names with spaces too. But perhaps the plugin checks what to expect, when the drive has short filenames enabled -> expect short names (no spaces), else expect long names. But TC uses Irfanview as a service window (Irfanview is started by TC with parameter /hidden). Perhaps that Irfanview in this case, is always passing long filenames to its plugins, causing this plugin to fail. Note that the WebP.dll plugin doesn't have this problem.

Note that this is all speculation and I have not looked into it.

[petermad]

Sure - when referring to short filename support it means support of keeping 8.3 filenames for every long file name.

that means that a file like "Cursed Programming Sticker Sheet - il_fullxfull.3601476621_nj57.avif" also has a name like cursed~1.avi - you can see that name if you disable "Configuration" -> "Use long names (recommended)" - if you do not see a short name like cursed~1.avi - then the drive is not configured to support 8.3 names.

[petermad]

The plugin for Irfanview works when Irfanview is used in the normal way, so the plugin can handle long names with spaces too. But perhaps the plugin checks what to expect, when the drive has short filenames enabled

That could be the case.

[pi.degroote]

Now I did the test to disable "Use long names (recommended)" in TC's Configuration.
Only on drive C, I see truncated names, like "cursed~1.avi" and "cursed~2.avi".
On drive D, I see all long names in lowercase.

Then the 'binary view' problem persists with those files on drive C.
Now the file c:\Intel\Cursed_Programming_Sticker_Sheet-il_fullxfull.3601476621_nj57.avif (without spaces) is now also showing as a binary file, since its name and path is now c:\Intel\cursed~2.avi in the short notation.
Otherwise, this one showed as an image.

Also note that IrfanView, using the same AVIF.DLL displays all AVIF images correctly, regardless of spaces or not, long of 8.3 names.

Only note: opening a file with "Use long names (recommended)" disabled, like "cursed~1.avi" and "cursed~2.avi" results in opening the Media Player instead of IrfanView (since AVI is associated with the Media Player instead of IrfanView).
Right Click on it and choosing "cursed~1.avi" or "cursed~2.avi" still opens it correctly in IrfanView, displaying the images.
IrfanView then shows the long name instead of "cursed~1.avi" or "cursed~2.avi".

[petermad]

On drive D, I see all long names in lowercase.

That could indicate that support of 8.3DOS names is of importance. I have 8.3DOS names enabled for all my drives, and that is the reason that I can reproduce the bug on all drives.

And this also lines up with whites speculation about the reason.

[white]

Moderator message from: white » 2026-06-11, 16:02 UTC

Topic merged with this topic
» [TC 11.58 RC3] Displaying *.avif (via IrfanView) fails on some PCs

It appears I've looked into this before.
Rename the extension of your .avif file to .vif and change *.avif to *.vif in TC configuration, and the file will display correctly.
(Not meant as a solution, but to illustrate what has been discussed in this thread.)

[pi.degroote]

Rename the extension of your .avif file to .vif and change *.avif to *.vif in TC configuration, and the file will display correctly.

Thank you, this eliminates the problem in TC (with the IrfanView connection), but indeed, introduces another problem (or situation) of its own kind.
That way, all of my AVIF images with now the '.vif' file extension display correctly, and without any issues.

Perhaps, could there be a sort of overlap with the really old AVI file, with for instance a codec which gets triggered and then refuses because it 'sees' an AVIF header instead ?
This since the file extension is then truncated from AVIF to AVI.

Would this be a problem with TC, or with the IrfanView AVIF.DLL ?
So it turns out that it only affects the '.avif' file extension, and not, for instance, a '.vif' file extension.

„This problem was almost driving me N.U.T.S. ... (and while I know what nuts are, I don't know what 'N.U.T.S.' would be).“

[pi.degroote]

Furthermore, IrfanView has no problems to open this kind of 'VIF' files, and thus automatically invokes 'AVIF.DLL' for this.
In theory, I could rename all those files from AVIF to VIF, and get rid of this problem on my computers.

I also did a test by renaming the AVIF file extensions to VIFF (with a double F), then in the Lister's Multimedia section, I changed *.avif with *.viff, and this also turns out to work without any issues.
So I guess we can perhaps consider this a conflict with the old AVI files (when AVIF gets truncated to AVI by the 8.3 filenames setting or policy).

When disabling the "Use long names (recommended)", it breaks VIFF in a way, but it also breaks JPEG (the 4-letter extension), since they get truncated to VIF and JPE respectively. While both JPG and JPEG are valid extensions, JPE is not.

I would guess that the Lister does some kind of request (call) to the system to 'render' or 'read' an AVI file in that way, even if the "Multimedia (AVI, WAV,...)" check box is disabled. Maybe, could this conflict with AVIF in that specific case ?

[beb]

Imagine.wlx displays AVIF files for me flawlessly, no matter what their names are.
It kind of drops a hint that something is wrong with another viewer mentioned here.

[Horst.Epp]

For me Lister has no problems to show AVIF files with spaces in the name.
This is true for internal use of IrfanView from Lister and also works using the TCIrfanView plugin.