.
(1) Windows Explorer & Metadata (eBook Title, etc)
Several years back, MS rewrote file-explorer (Vista timeframe). At that point they allowed new property-handlers where any proprietary format's metadata could be exposed.
At the same time, they began including a fair number of standardized file-format property handlers, for certain types of audio/video, images, etc. Around this same time they wrote the search-index, creating "ifilters" that allow access to a proprietary file's full content.
In the case of ePub's, they're just .ZIP files with embedded HTML, essentially. Therefore, I had assumed that ePub's were being handled intrinsically within Windows; however, it appears that in my case, SumatraPDF is handling my ePub metadata. Installing SumatraPDF should address ePubs.
Adobe and PDF-XChange, two of the more capable PDF tools, will install property handlers for your PDF's
At this point, you should be able to see more eBook metadata (Titles in this case) directly in any modern File Explorer, or in the case of TC, you may need that shell-tools addin, I'm not certain.
began supporting metadata of several common files. Around that same time, they
.
.
(2) Calibre Workaround -v- Scripted ISBN scraper
A simple Python+BS script would allow easy scraping of OpenLibrary without downloading the entire DB; however, a DB call is obviously more reliable if you don't mind the hassle of continually updating every month, re-importing, etc.
A Python+BS scrape is very easy because it's a simple HTTP call w/ISBN concatenated to the URL:
https://openlibrary.org/books/ISBN-GOES-HERE
However...
There is no need for this as the Calibre workaround is a lot less work -- and the eBook-Tools is the pre-existing alternative.
I don't understand the suggestion that the Calibre workaround is complex. Yes there is overhead; however, it's one single command to copy-out all files it process. It's one single command to delete all files it processed. That's either two CLI commands or a half-dozen clicks in a GUI.
Between book for myself, my wife, and my family -- I have about 15,000 eBooks. Both solutions work fine in my case; I simply process new eBooks in a batch, when I get around to it. That might be 500 books at a time.
.
.
(3) Bad Filename Issue
I believe [Login to see the link]'s point is that the file extension was incorrectly replaced?
Taking the last period "." in a filename, the characters to the right are assumed to be the file-extension. Because [Login to see the link]'s file was renamed "filename.sanet.st", the extension appeared as "st" rather than "pdf".
As a result, no amount of RegEx (or renaming) would have helped in his case, because the error would be on the uploader's side, where the file-extension was {accidentally?} removed.
[Login to see the link] makes an excellent suggestion of using the linux command "file". When that's not an option, it's crucial to have a quick/simple hex editor on-hand. Also, in Windows, there is a open source version of the linux file command ( [Login to see the link] ).
Don't forget to notify the uploader on the actual SA upload blog page, using the "comments" section. These comments get forwarded to the uploaders and they will often fix the issue. While that's reactive and won't help you; when enough people do this, it ultimately yields a karmatic result that helps all of us.
.
.
(4) Automating Processes to Eliminate These Issues
Don't forget about the benefit to using an automation solution to run pre-scripted workflows; I've provided this above. Just drag-in files when you download and have that run preconfigured scripts based on rules you've setup.
Also ... Don't forget about using jDownloader to rename files upon downloading, saving you from the rename issue (although not in [Login to see the link]'s case). I've explained this somewhere above, as well.