Podcast Problems: XML Parsing Issues?

[wbmccarty]

Maybe the textfield for the URL should be paste-only rather than enterable so that the application doesn't get prematurely excited when the domain has been entered but the path hasn't yet been entered. That'd take some fancy validation handling of events fired by the control, of course. I'm not sure of this notion. I'm mainly thinking out loud concerning the problem.

[Peke]

Bug I added should be enough as in such cases MMW do not try to load anything unless there is >0.5 Sec delay in typing.

[wbmccarty]

You know best. At least, I've learned I apparently often pause 0.5 seconds between typing the components of a URL, probably because I memorize and type one component at a time.

Cheers,

[Ludek]

MM must fetch the podcast XML file while the dialog box is open. Otherwise the podcast subscription will not succeed. Some sites may take several minutes to load and the user may be tempted to close out the dialog box immediately after specifying the podcast URL, as done with other podcast catchers. But if the user enters the podcast name manually and then clicks Enter the podcast will never actually be subscribed. In that case MM misleadingly reports that it's updating the podcast but it's apparently doing something else entirely because Wireshark shows no network activity.

Hi, I cannot replicate this and I also don't see a reason for it. If the podcast is subscribed before fetching the info (by entering podcast title manually) then everything works same way, because the same URL is used when updating the podcasts. Could you put here example podcast URL for which you observes the issues?

[wbmccarty]

Ludek, here's a URL for you: http://podcast.fightingforthefaith.com/FFTF.xml. However, my experience isn't due to a strange site or URL. I see the problem fairly often, but intermittently, with a variety of URLs. The problem is somewhere in the MM code because I can see via Wireshark that when MM says it's updating nothing is really happening. And, I can see that when MM says it encountered a download error the podcast XML file was successfully transmitted. I think that the problem is that MM doesn't/can't successfully download the XML file unless it does so while the dialog box is still open. But it's hard for me to be sure of that merely by observing program behavior. What I have learned is that if I leave the dialog box open for a long, long time the incidence of problems tends to zero. So it looks as though I have a workaround, at least for my own use. Cheers,

[Ludek]

Hi, the feed http://podcast.fightingforthefaith.com/FFTF.xml seems to be inaccessible most of the time I tried it.

It is issue with the feed server rather than MMW issue.

[donaxme]

I installed this software last week, and almost uninstalled it the same night because of this problem. I gave it another try yesterday, and stumbled onto a 3-keystroke solution:

Paste the URL into the Edit Subscription box. With the URL still highlighted, hit END, then hit BACKSPACE twice. Close the box, and if the podcast doesn't update automatically, do it manually. When the screen refreshes, you should be good d'go.

This works for me in Windows 7. I have no idea why; I don't know nothin' 'bout computers. I guess there's more to a URL than meets the eye - literally!

[wbmccarty]

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.