Please see the attached for illustration:
I can't reproduce that in a small folder, at least.
Was the metadata still populating further down the window? It's possible the files starting with # were sorted at the end of the queue rather than the start (depends on the sorting algorithm/locale, which might differ to the one used to display the list). If so, it may just be that it hadn't got to them yet.
To double-check, I moved the files and refreshed the screen, but the following columns shown in the screenshot previously still have no metadata populated, oddly: video bit rate, audio bit rate, samples, frame rate, and aspect ratio.
MediaInfo displays it fine, though.
The columns that are populating look like ones added by a script, not built-in ones, which may explain the difference there. Looks like Opus is failing to read those files at all for the built-in columns.
If you rename one of the files to remove the # does it work then?
As soon as I delete the hash tag, all metadata is then correctly displayed.
The missing video and audio bitrate metadata are from the columns built into Opus, not from scripts for some of the other columns, which is why it's even odder because it's fine once the initial # is deleted in the file name.
Very strange.
If you copy the file to your Desktop folder, does the problem still happen there?
(I'm wondering if the full path, path length, or drive type has any connection to the # character being treated specially, which could explain why I'm not seeing the same.)
Strange, indeed, as when I copy a file beginning with a # to the desktop folder, it does exactly the same: no metadata populated for those blank columns shown in the previous screenshot, yet it displays absolutely correctly upon deleting # from the start of the file name.
Would it be possible to make a ProcessMonitor log of what happens when you navigate into the folder?
That should show us if it's trying to open the file with a # in the name, and maybe getting blocked by something, or opening the wrong path for some reason.
Might also be worth testing what happens if the script that adds those other columns is disabled. It's possible that (or the underlying components that ultimately get the data for it) is keeping the files locked if they have a hash in their names, maybe.
I've figured it out, thanks. Files needed remuxing because they were missing their headers to allow for the aforementioned columns' metadata to display. As always, thanks for your input and patience 
1 Like
Glad it's working now!
I wonder why the filename mattered there as I'd expect the data to still be missing if the hash was removed.
1 Like
Very odd! 
Indeed—especially as all metadata displayed when removing the # from the beginning of the file name without remuxing. Something within the files must have been off slightly to make it behave so strangely until I decided to try remuxing one file, then all of them after seeing metadata then displayed.
This gets stranger. Upon updating to the latest beta today (13.0.35), all MKVs beginning with a # do not display the metadata shown by the blank columns in the original screenshot when scanning my video folder on my external drive, despite MediaInfo showing it. Remuxing obviously did not change anything my end as I had thought and stated (the files were fine originally, then, I can only conclude).
However, when I delete the # from the file name, all metadata displays—even after restoring the # so the file name is as it was, but this time with the metadata showing. Weird.
Any ideas what's going on here and what a solution might be?
Have you tried disabling the script that's adding the extra columns, in case it's involved?
Failing that, a Process Monitor log is probably the best thing to try next.