Show more information when requesting a new podcast feed fails

[sengsational]

I get "There was a problem requesting the feed from the specified URL" when I try something like this

https://rss.samharris.org/feed/?token=e475a8b0-ffff-ffff-ffff-5f327c8dc1f5

NOTE: I overtyped ffff in the GUID so as to protect my account (I paid for a subscription and this was the RSS feed link provided by the site).

Also note: I typed the same URL into "Podcast Addict" Android application, and it worked.

Finally, my assumption is that there might just be a parsing issue; it appears that the URL contains a space character, and that might be an issue. I will be glad to beta test if given the basic instructions to replace my production 0.36-d6758c19 version.

Sorry, I didn't take the time to read how to get a log/trace, so please give quick advice if I need to do that first.

[ribbons]

Ah, now that is an interesting problem! In fact there isn't a way of grabbing a trace or sending an error report for that particular issue as I don't think someone has raised an issue before with a private RSS feed - previously when people have had difficulty with public RSS feeds they've just been able to include the URL in the issue report as an easy way to reproduce it...

I'm guessing your mention of a space is in the audio file URL(s) as I can't see one in the feed URL you've given or am I misunderstanding something?

Some of the feed handling code in Radio Downloader isn't all that robust so it isn't a huge shock that there is a feed that Radio Downloader can't deal with - certainly Podcast Addict is a great app so I'm not surprised it handles it fine.

I guess there are a few ways we could move this forward:

• If you're happy sharing your private URL directly with me say via email I can take a look at the issue myself.
• If you are comfortable with debugging you could load up Radio Downloader in Visual Studio, step through what's happening and let me know what is going bang.
• I can add some extra debugging to that part of the podcast handling code and point you to an updated build.

Let me know which you'd prefer :smile:

[sengsational]

Thanks for the quick attention. I was wrong about the space in the URL; there is no space after all.

I see that there's a community edition of Visual Studio and I was tempted to download it, but wasn't sure what extra stuff I needed, and besides, I've got several (bloated) IDE's on my system already, and not sure my system would manage another IDE very well.

That leaves me with the email sharing option. I took a guess at your email address. My name is dale, and you could take a stab at mine (hint, use my github id).

[ribbons]

Well, now this is curious! I fired up Visual Studio, pasted in the URL you sent over and... It happily switched to the episodes view and started listing them :smile:

Has the problem 'gone away' for you now too or does it still occur? If it still happens, I'll add some code to dump the exception when the 'There was a problem' message is displayed and give you a link to download an updated build from.

[sengsational]

Still getting the same thing when I try it on my system.

[ribbons]

Right, okay - I've made a change to the error handling when adding a new podcast so that it includes the error details as well as the existing more generic message. Could you download the latest installer from the link below and let me know what the result is? https://ci.appveyor.com/api/projects/ribbons/radiodownloader/artifacts/installer/Radio_Downloader-win64.msi?job=Image%3A%20Visual%20Studio%202017%3B%20Platform%3A%20win64&branch=master

[sengsational]

It says "There was a problem requesting the feed from the specified URL. The request was aborted: Could not create SSL/TLS secure channel".

This sounds like maybe my OS isn't able to use the right version of SSL/TLS? I probably should have mentioned, I'm on Windows 7. It's still in extended support, but yeah, maybe some assumption in the Visual Studio build has it breaking on lack of support for a protocol instead of falling back?

Here's my HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders]
"SecurityProviders"="credssp.dll"
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SaslProfiles]
"GSSAPI"="Kerberos"
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL]
"EventLogging"=dword:00000001
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers]
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\CipherSuites]
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Hashes]
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\KeyExchangeAlgorithms]
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols]
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 2.0]
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 2.0\Client]
"DisabledByDefault"=dword:00000001
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\WDigest]
"Debuglevel"=dword:00000000
"Negotiate"=dword:00000000
"UTF8HTTP"=dword:00000001
"UTF8SASL"=dword:00000001
"DigestEncryptionAlgorithms"="3des,rc4"

[ribbons]

Yes, I think Windows 7 is relevant here. From what I remember, the .NET framework effectively shares networking code with Internet Explorer, so it wouldn't surprise me if you can't access the feed URL using IE11 either (Chromium based browsers or Firefox use their own, separate implementation).

Looking at the SSL Labs report for that domain, the site appears to support an unusually short list of ciphers which I think is the issue here - there isn't an overlap between what the site and IE11 on Windows 7 support, so the TLS connection fails.

The 'Handshake Simulation' section of the page seems to hit the nail on the head - it doesn't believe that IE11 will be able to access that site except on Windows 10 (which would explain why my testing under Windows 10 worked okay):

As this is caused by a combination of the OS/.NET framework and the site rather than anything specific that Radio Downloader is doing wrong I'm inclined to close this issue (the vagueness of that error message has been resolved by adding more detail), unless you think there is something that Radio Downloader is doing wrong here?

[sengsational]

Thanks for digging into this. I agree, not a bug, just a guy clinging to an old OS.

I appreciate you creating and supporting this handy tool. Still going strong on Win 7, just not with the narrow cipher list on that one site.

[ribbons]

I appreciate you creating and supporting this handy tool. Still going strong on Win 7, just not with the narrow cipher list on that one site.

Thank you and glad to hear it :smile: