FINAL UPDATE:
OP has summarised all his findings completely and concisely in his question post. I see no reason to delete my suggestions, but i recommend you read his post instead of mine if you are for a quick solution to your problem.
You should try two things:
In Explorer, click on "organize" -> "folder and search options" -> "view" -> put a checkmark in "always show icon instead of thumbnails" -> press apply and close.
Now right-click on the culprit folder -> "properties" -> "customize" -> under "optimize this folder for:" open the drop down menu and choose "general items" -> place the checkmark in the box under the drop down menu at "apply to all subfolders" -> press apply and close.
This will apply the new folder view settings to the chosen folder and all the subfolders which are contained within.
I am german and thus have a german version of windows, so maybe some of those options above are translated slightly differently, but you should be able to find them nonetheless.
Update 1:
I think you are on the right track with the metadata. Depending how the videos are encoded, the metadata could be either at the beginning, at the end, or even somewhere in the middle (which is rare, though). I am guessing that those video files were encoded with some unusual properties (you probably produced them yourself?) which makes explorer read in the whole file from beginning to the end to extract the metadata, which obviously takes a while if there are many big files in the folder. I have seen explorer read the full length of a giant exe file to display the embedded icon at the end.
So, i think you have it figured out there, identifying and disabling the columns which need to extract metadata from the view in explorer (together with the disabled thumbnails) should obviate explorer's need to read in those files, which should solve your problem.
Columns you should probably not use are something like: date taken (as mentioned in one of the links you posted, date taken is very differently from the creation date of the file), length, resolution, location.
Columns you should be safe to use would be attributes which can be read directly from the directory of the filesystem like: file creation date, file modified date, size, file type.
If you indeed need for your sorting some of the attributes which should be disabled, i think that maybe the most practical solution would be to look for an alternative file browser, and check if it handles the situation better. You could then use explorer like you are used to normally, and use the alternative file browser to handle your video folders.
You also have the possibility to perform many basic file-oriented operations from your built-in command line interpreter cmd, it doesn't care about metadata and can be a simple and efficient tool for copying, moving or deleting files and folders. You could then even automate things by using batch files. This is most probably not the solution you search for, though, since cmd doesn't even have a graphical user interface.
Update 2:
I just read your second update and i am happy to read that your problem seems resolved (for now, at least). Maybe it really was just a matter of the thumbnail cache getting overcrowded. I could imagine those thumbs.db files getting bigger and bigger, if you move files from folder to folder frequently. I suspect it actually keeps a thumbnail in that cache file for every file which ever was in the folder. Maybe there is some sort of garbage collection mechanism for those files, too, but it failed in your case.
So, if you were moving video files from folder to folder en masse, and always using the same folders for that (eg. not creating new ones) maybe we have found the source of your problem...
If your system shows the same symptoms again in the future, you could just try deleting the thumbnail cache.
For that you need to:
"windowskey + r" -> input "cleanmgr" and press return -> choose the drive where the video files are on (only if you actually have multiple drives/partitions) -> choose "clear thumbnail cache" or something like that -> run cleaner
Best Answer
You've been taught that hard disks contain files, but that's not the entire truth. Actually, hard drives contain one very, very big number expressed by a lot of single bits. But this interpretation doesn't make any sense to you nor your computer, because processing single big numbers isn't very common (and I'm talking about REALLY HUGE numbers). Instead, computer splits it into smaller 'words' (8-bit, 16-bit, 32-bit or whatever) and uses like that. Still, that's just a bunch of words (let's assume 8-bit words, i.e. bytes).
Now, that drive is partitioned. I have explained why partitioning is a good idea in this answer:
Now, every partition has its own filesystem. Modern versions of Windows use NTFS, but FAT, FAT32 and exFAT are supported for external media or legacy partitions. Everyday-use Linux installations usually use ext filesystems, ext4 being the latest one.
Filesystem defines the way files are physically located on the disk. You can think of it like this: if you had a 10000-page book without any chapters, page numbers or line breaks, it would be very hard to use. Of course page numbers and chapter titles take up some space on the page, but they make using the book a lot easier and faster. If you want to jump to chapter, let's say, 42, you just look it up in the table of contents. Then you leaf through the book until you find the chapter you want. Your files are chapters and your filesystem is the book. Filesystem metadata, like file boundaries, filenames etc. takes up space too, but it's a comparably small amount of space, and it makes things work a lot faster.
If your "chapter" is empty, it can still have a heading or a page number, right? Empty file contains zero bytes of data. Metadata takes up space, but it's not a part of the file, but of the filesystem. Otherwise you'd see filenames inside your text files?
By the way, that's why early versions of DOS were accepting only 8.3 names - the space reserved for filenames was very limited. NTFS allows filenames that are 255 characters long[1].
Just one more word on your comment:
That's completely possible to have valid files bigger than your hard drive thanks to a feature called sparse files. Hennes has an excellent explaination of these in his comment on this question: