View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0003119 | MMW v4 | Other | public | 2007-06-17 18:42 | 2007-07-23 20:31 |
| Reporter | rusty | Assigned To | |||
| Priority | immediate | Severity | major | Reproducibility | sometimes |
| Status | closed | Resolution | fixed | ||
| Fixed in Version | 3.0 | ||||
| Summary | 0003119: Podcasting: many feeds appear empty | ||||
| Description | Podcast feeds often appear empty even though testing with Juice shows that the feeds exist. The bug occurs sporadically. Sometimes feeds from CNN or CBS all appear empty, and other times they appear the way they should! | ||||
| Tags | No tags attached. | ||||
| Fixed in build | 1051 | ||||
|
|
This occurs because the method we use for reading HTTP doesn't seem to work correctly, it returns empty string sometimes (in this cases). But I have a feeling that it was working fine previously, but I haven't found anything (any change in code) which could infuence this. But it seems to depend on server (e.g. rss.cnn.com doesn't work and www.cnn.com works). For the feeds it sometimes works and sometimes doesn't (e.g. http://rss.cnn.com/services/podcasting/newscast/rss.xml ) |
|
|
Now, it is not possible to reproduce, but I have added five times trying if the data could not be retrieved from a server (empty string is returned) + a debug string. |
|
|
Upon discussion / investigation, it seems that there are 2 issues: 1) When I click the 'Subscribe' button to subscribe to some feeds (e.g. http://www.smarterbytheminute.com/?feed=rss2 ), and then click OK to subscribe to the feed, it doesn't work because I didn't wait long enough. 2) When I double-click the text for a feed (i.e. the text to the right of the 'RSS' button), for many feeds the list of episodes then appears, but for an equal number, the list of episodes doesn't appear--even if I wait 10-15 seconds. |
|
|
re 1) I have added a prevention, the channel data are mostly included in the first x KBs of the whole feed, it reads only first 5 KB to find out the data (like Podcast title and description) so that you needn't wait so long on the subscribe dialog. Fixed in build 1045. re 2) it means that the podcast doesn't include any episodes. |
|
|
Tested 1045: 1) This issue is still open. 50% of the time, the Title and Description either don't appear, or quickly appear and then disappear. I'm pretty sure that the parser for looking up the Title/Description are working fine and that there's just a logic issue--somehow the contents of these fields are emptied even after they've been looked up. 2) There are 2 cases of this issue: a) No episodes exist b) Episodes exist but they are in unsupported formats (i.e. video podcasts) Both cases should have relevant messaging: a) "No episodes found." b) "Episodes are in an unsupported file type." |
|
|
Re: 1) The logic is that firstly the title and description are received from OPML (which is cached on HDD) and then there is a running thread on the background which tries to read this data from rss feed, but if the feed is an empty string (instead of the XML data) then also title and description are emptied. The problem is still that some servers (depends of a day period) return us the empty string instead of the real XML content. i.e. the function silently fails by returning the empty string. e.g. if I try http://www.cbsnews.com/common/includes/podcast/podcast_sound_1.rss in the morning it is ok, but if I try it in the evening it sometimes returns the empty string. 2) this is fixed in build 1046 |
|
|
1) I've confirmed many times (including just now) that this isn't a time-related issue, but rather an MM specific issue. I've tested this by: a) first trying to access a podcast with MM b) then trying to access the podcast with Juice As an example of another manner in which this bug manifests itself: -I subscribed with MM to 'The Onion' podcast several days ago: http://www.theonion.com/content/feeds/radionews -Today I tried to update the podcast --> no updates -I then tried to look at the podcast episodes by clicking '+' in MM's OPML directory entry for the Onion --> the feed gets greyed out Both of the above tests imply that MM for some reason thinks that the Podcast doesn't contain any new episodes -I then try subscribing to the Podcast via Juice --> subscription works and there are 4 new episodes. This makes me wonder: perhaps the problem in MM isn't with reading the OPML but rather with looking up episodes, and that the subscribe function is disabled when no episodes are detected (just a hypothesis). |
|
|
The reason is obvious, as I wrote the function we use for reading HTTP doesn't work correctly (returns empty string sometimes - for me in the evenings). The function is included in Indy Project which we use for this. I tried to update to a newer version (version 9 released 2004) of Indy Project. It doesn't solve this problem :-( I'm going to try the newest version (version 10), but it is indicated as unstable. |
|
|
The version 10 doesn't solve this problem too. btw. The problem seems to be reproducable only in this day's hours (i.e. at 6 PM of european time), for all kind of the problematic servers. (at 1 PM it always works fine) I found out that a variable ( HandleRedirect) causes that it silently fails, if this variable is false then there is raised exception "HTTP/1.1 302 Moved Temporarily". This implies that problems occurs only if there is a need to redirect. |
|
|
After testing it unfortunatelly doesn't depend on redirecting. e.g. http://www.cbsnews.com/common/includes/podcast/podcast_innews_1.rss is redirected to http://feeds.cbsnews.com/podcast_innews_1 but the empty string is returned from both URLs. |
|
|
Ludek, I tested in build 1048 and couldn't reproduce this. Has anything been fixed? |
|
|
As I wrote it is reproducible after 6 PM of european time (after 12 AM of your time). e.g. at 10 AM or 3 PM of european time (4 AM or 9 AM of your time) it always works fine for all the feeds. It somehow depends on day's period. The period seems to be approximately 12 hours. |
|
|
Note: tested this again in 1048 with http://feeds.feedburner.com/ChubCreek MM could not successfully display feed properties or download any episodes Juice worked properly. |
|
|
Since it looks like that there's some problem with Indy library, we can try some alternative, free open-sources library, e.g. http://www.badfan.com/delphi/TIE_http_https.html Btw, for direct testing of the streams outside of MM, checking headers, etc. I use http://users.ugent.be/~bpuype/wget/ |
|
|
The servers returns: 'HTTP 1.1 204 No Content' According to RFC 2616 it means: RFC 2616 HTTP/1.1 June 1999 10.2.5 204 No Content The server has fulfilled the request but does not need to return an entity-body, and might want to return updated metainformation. The response MAY include new or updated metainformation in the form of entity-headers, which if present SHOULD be associated with the requested variant. If the client is a user agent, it SHOULD NOT change its document view from that which caused the request to be sent. This response is primarily intended to allow input for actions to take place without causing a change to the user agent's active document view, although any new or updated metainformation SHOULD be applied to the document currently in the user agent's active view. The 204 response MUST NOT include a message-body, and thus is always terminated by the first empty line after the header fields. |
|
|
Fixed together with 3148 by replacing the current Indy library by the new one. |
|
|
Verified 1051. |
