by Sproaticus » Wed Feb 17, 2016 11:19 pm
I saw this same issue with the Overthinking It Podcast at
http://feeds.overthinkingit.com/otipodcast , which is hosted on the Feedpress network. Exact same error code and message.
My theory is that, about a month ago, this URL responded with an HSTS header, meaning that all traffic was required to be forwarded to HTTPS. This HSTS header is no longer present in the server response headers, but both MediaMonkey and Firefox remembered the HSTS setting. Unfortunately, the server does not have a valid SSL certificate for that server name, and so we get an SSL error.
In Firefox, this HSTS preference survived even after wiping out site cookies, storage, preferences, and permissions. Only after clearing out the Firefox profile file SiteSecurityServiceState.txt then restarting Firefox did this behavior fix itself.
I can't find a similar fix for MediaMonkey. I can't actually confirm if MM is caching this HSTS header or not. I couldn't find much in mm.db or in the profile directory that might store this setting. I'm only guessing that, based on the timing of seeing the HSTS issue in Firefox, MediaMonkey is somehow affected with the same behavior.
I'm running MediaMonkey v4.1.10.1778 on Windows 7 64-bit w/SP1.
I saw this same issue with the Overthinking It Podcast at http://feeds.overthinkingit.com/otipodcast , which is hosted on the Feedpress network. Exact same error code and message.
My theory is that, about a month ago, this URL responded with an HSTS header, meaning that all traffic was required to be forwarded to HTTPS. This HSTS header is no longer present in the server response headers, but both MediaMonkey and Firefox remembered the HSTS setting. Unfortunately, the server does not have a valid SSL certificate for that server name, and so we get an SSL error.
In Firefox, this HSTS preference survived even after wiping out site cookies, storage, preferences, and permissions. Only after clearing out the Firefox profile file SiteSecurityServiceState.txt then restarting Firefox did this behavior fix itself.
I can't find a similar fix for MediaMonkey. I can't actually confirm if MM is caching this HSTS header or not. I couldn't find much in mm.db or in the profile directory that might store this setting. I'm only guessing that, based on the timing of seeing the HSTS issue in Firefox, MediaMonkey is somehow affected with the same behavior.
I'm running MediaMonkey v4.1.10.1778 on Windows 7 64-bit w/SP1.