by wbmccarty » Wed Oct 23, 2013 1:33 am
Ludek, that site happened, by sheer coincidence, to have had a problem earlier today. At the time of this writing, the site is up and working. I chose that site because it has quite a large number of episodes and so I find it especially prone to subscription failure. More specifically, closing the subscription dialog box before the XML file is completely downloaded--an operation potentially requiring quite a few seconds in the case of this particular podcast site--generally causes MM to erroneously report the download as having failed.
Please be reminded that there was nothing wrong with that site several days ago when I reported the problem. At that time, the
majority of URLs I tried failed. Please also bear in mind that other users, such as donaxme (above, Tue Oct 22, 2013 7:05 pm), have reported the same problem I've reported. I fully understand how difficult it can be to replicate screwy problems of this sort. But, please be certain of this: the problem is
not that I am trying to access bad or even intermittently bad podcast sites or that the XML download fails. As I explained, using Wireshark I have captured and analyzed, TCP segment by TCP segment, the network traffic related to the fetching of the XML file. I included the reconstructed data stream for the podcast
http://www.aomin.org/podcast.xml in my posting, so that readers can see for themselves that the XML file was, in fact, successfully downloaded. Since the XML file was successfully downloaded whereas MM reported it as having failed, whatever the problem is, it's internal to MM. And, in my experience--just as reported by donaxme--the problem appears to pertain to the UI code for the dialog box that captures the URL. (Please see also droozilla » Tue Dec 20, 2011 7:17 pm, CanUdian » Fri Dec 23, 2011 2:40 pm, wbmccarty » Wed Apr 18, 2012 12:19 pm, wbmccarty » Wed Apr 18, 2012 12:41 pm, etc.) I can think of no other way to explain the fact that re-pasting the URL, hitting backspace, or similar fiddly tricks can rescue a failed subscription when the reported failure occurs, as in my case, in the context of a network stream that demonstrates successful download of the XML file even though MM reports that the download failed.
The bottom line is that, under some circumstances yet to be precisely identified, MM is mistaken in thinking the podcast XML file download has failed. And, by various means, MM can be induced to try again, often with a positive result. Meanwhile, my other podcast catcher successfully subscribes to the same podcasts for which MM reports failure and successfully downloads each and every episode. These facts cannot be adequately explained by reference to a temporary feed server issue for the
http://podcast.fightingforthefaith.com/FFTF.xml podcast.
Ludek, that site happened, by sheer coincidence, to have had a problem earlier today. At the time of this writing, the site is up and working. I chose that site because it has quite a large number of episodes and so I find it especially prone to subscription failure. More specifically, closing the subscription dialog box before the XML file is completely downloaded--an operation potentially requiring quite a few seconds in the case of this particular podcast site--generally causes MM to erroneously report the download as having failed.
Please be reminded that there was nothing wrong with that site several days ago when I reported the problem. At that time, the [i]majority[/i] of URLs I tried failed. Please also bear in mind that other users, such as donaxme (above, Tue Oct 22, 2013 7:05 pm), have reported the same problem I've reported. I fully understand how difficult it can be to replicate screwy problems of this sort. But, please be certain of this: the problem is [i]not [/i]that I am trying to access bad or even intermittently bad podcast sites or that the XML download fails. As I explained, using Wireshark I have captured and analyzed, TCP segment by TCP segment, the network traffic related to the fetching of the XML file. I included the reconstructed data stream for the podcast [url]http://www.aomin.org/podcast.xml[/url] in my posting, so that readers can see for themselves that the XML file was, in fact, successfully downloaded. Since the XML file was successfully downloaded whereas MM reported it as having failed, whatever the problem is, it's internal to MM. And, in my experience--just as reported by donaxme--the problem appears to pertain to the UI code for the dialog box that captures the URL. (Please see also droozilla » Tue Dec 20, 2011 7:17 pm, CanUdian » Fri Dec 23, 2011 2:40 pm, wbmccarty » Wed Apr 18, 2012 12:19 pm, wbmccarty » Wed Apr 18, 2012 12:41 pm, etc.) I can think of no other way to explain the fact that re-pasting the URL, hitting backspace, or similar fiddly tricks can rescue a failed subscription when the reported failure occurs, as in my case, in the context of a network stream that demonstrates successful download of the XML file even though MM reports that the download failed.
The bottom line is that, under some circumstances yet to be precisely identified, MM is mistaken in thinking the podcast XML file download has failed. And, by various means, MM can be induced to try again, often with a positive result. Meanwhile, my other podcast catcher successfully subscribes to the same podcasts for which MM reports failure and successfully downloads each and every episode. These facts cannot be adequately explained by reference to a temporary feed server issue for the [url]http://podcast.fightingforthefaith.com/FFTF.xml[/url] podcast.