Podcasting feeds broken [#21924]

I was trying to work this out on the forums and Dries Buytaert suggested I post a bug report so here's what's going on:

If I set the "Download Method" setting to "Public" then the link in the RSS enclosure for my Podcast is absolute and fully qualified but lands on a Drupal "page not found" error page. This setting also breaks all the photos in my galleries. Furthermore, if I put the location of the image on the server in the address bar of my browser I get the Drupal "Page Not Found" error page. Isn't this the opposite of how "Public" is supposed to work.

Setting the download method to "Private" fixes the galleries but then all my RSS enclosures are converted to relative links. These don't seem to work at all in Podcast recieving programs (I'm testing with iPodder and Doppler). I checked the RSS of some of the other Podcasts that I listen to and all their enclosures have absolute links to the media files.

Comment	File	Size	Author
#15	file-create_url.patch	625 bytes	walkah
#15

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Comment #1

gmills@gregmills.com CreditAttribution: gmills@gregmills.com commented 11 May 2005 at 02:27

Would it be possible for me to just patch the code where the following line is generated?

If I could just get it to add in my full URL I think everything would work fine.

ex:

Comment #2

gmills@gregmills.com CreditAttribution: gmills@gregmills.com commented 11 May 2005 at 02:29

Sorry,

Change:
<enclosure url="system/files?file=050805.mp3" length="5205243" type="audio/mpeg"/>

to:
<enclosure url="http://www.miamichurch.org/system/files?file=050805.mp3" length="5205243" type="audio/mpeg"/>

Comment #3

gmills@gregmills.com CreditAttribution: gmills@gregmills.com commented 14 May 2005 at 02:49

Title:	"Download Method" having unexpected effects on Podcasts and Galleries	» Podcasting feeds broken
Priority:	Normal	» Critical

I found it and changed it myself but it didn't alter the behavior.

With the download method set to "private" iPodder finds the feeds and see the "episodes." But when it tries to download the episode it just says "downloading" but never makes any progress. I can enter the URL exactly as it appears in the enclosures into my web browser and it downloads just fine.

I downloaded the XML from a feed that I knew worked and I substituted the URL from Drupal's enclosure into it. Then I saved it back to my server and subscribed to it in iPodder. The result was exactly the same. It still says "Downloading" but never makes any progress. It doesn't work in Doppler either.

With the download method set to "public" iPodder downloads Drupal's "Page Not Found" page with the MP3's filename. This setting also breaks all the photos in my gallery.

I've spent a lot of time trying to isolate the cause of this and I'm getting nowhere. I've also been searching Google and fishing in Drupal's forum for a working example of Podcast in Drupal and I can't find one. Everyone doing a Podcast is currently using Feedburner to create the feed. I upgraded the priority to critical because I believe that this is important functionality that may be completely unusable. I hope that's alright.

Any help is greatly appreciated and I've turned on mail so I can work directly with whoever will look into this. My programming experience is very limited but if I can help troubleshoot in any way then I am available.

Thanks

Comment #4

zirafa CreditAttribution: zirafa commented 1 June 2005 at 21:36

Check out echoditto's podcast at radio.echoditto.com. It might help to ask them how they got theirs working. As for this podcasting problem, it seems like there should be a way to fix it by inserting the site_url variable or something right before the path so that the result is a completely absolute path when the enclosure url is created. I don't have the means to immediately fix this but I can see how this completely breaks anybody that is trying to use drupal to make podcasts (including myself). I'll work with you on pushing this and fixing this, Greg, but my drupal coding knowledge is pretty basic. You can get in touch with me by emailing me directly.
Farsheed

Comment #5

Bèr Kessels CreditAttribution: Bèr Kessels commented 23 June 2005 at 08:55

Could you please share the url of the feed? without that it remains wild guessing.

Comment #6

Bèr Kessels CreditAttribution: Bèr Kessels commented 23 June 2005 at 08:56

Priority:

Critical

» Normal

oh, and IMHO this is not "critical". Maybe for you it is, but "critical" is meant as "critical for drupal"

Comment #7

gmills@gregmills.com CreditAttribution: gmills@gregmills.com commented 30 June 2005 at 23:14

Critical... Normal... It doesn't matter. Either way it's been a month and a half since I first posted. I've managed to piece together workarounds for several problems I discovered in the process of setting up my feed. It's working now and I'm focusing on making the RSS output compatible with iTunes.

Unfortunately, I'm not a PHP programmer so most of my workarounds involve taking out dynamic references in the source and hard-coding it for my site. The fixes aren't transferable so I don't really have anything I can share back to the community. This also takes me out of the main development trunk so I don't know what's going to happen when I apply the next upgrade.

I've gotten a little help by posting in the forums and posting bug reports but for the most part I've been on my own in fixing problems I've found with Podcasting in Drupal. If the community wants this software to spread the community is going to have to become more diligent about addressing issues like this in a timely manner. Podcasting support was a key factor in my decision to use Drupal and this site was not shy about advertising it as a feature. Still, I don't know of any Podcast created entirely in Drupal other than my own. All the ones I've seen use a third party web service.

Comment #8

chx CreditAttribution: chx commented 30 June 2005 at 23:27

You speak a lot and tell us little. Ber asked for the feed URL but you have not given it.

We do not know anything about your setup. Webserver, PHP version, Drupal base URL etc.

Before criticizing the community, create a proper bug report. And guess what -- if you google on good bug report you'll get two excellent documents in the top three...

Comment #9

gmills@gregmills.com CreditAttribution: gmills@gregmills.com commented 1 July 2005 at 22:47

None of that matters now. I messed around in the code for a couple of weeks and finally got it to work on my own.

Check the date on the original report, it was almost two months ago. I'm not criticizing anyone. This is free software so I don't expect any kind of "customer" support. I'm simply recommending that if you want the install base for Drupal to grow the response time to requests for help is probably something that needs to be considered. You can take that as a criticism or you can take it as advice.

Rest assured, you won't be getting anymore improper bug reports from me.

If anyone is curious there is an actual working Drupal generated Podcast feed at:
http://www.miamichurch.org/taxonomy/term/11/0/feed

That's mine, and it's the only one I know of.

Comment #10

Bèr Kessels CreditAttribution: Bèr Kessels commented 3 July 2005 at 07:52

Greg,

You must really try to be more polite when posting in the drupal issues. Your comment about us no knowing what wwe should do to get our software spread is insulting, and so is your comment about our timing.

If you dont like the way drupal works, then change it, or move ver to another community. Insulting people definately does not work.

Oh, and BTW, afaik drupals uploads are used as aclosed files in any feeds, so we automagically have podcasting!

Comment #11

gmills@gregmills.com CreditAttribution: gmills@gregmills.com commented 5 July 2005 at 02:40

You guys are totally reading way too much into this. I do appreciate your offer for assistance. It's just that it's a month and a half too late. There's no hard feelings and I intend to continue to use Drupal. I just think perhaps we should look at how issues like mine are addressed.

I do not believe that Podcasting works "automagically" in Drupal. If it did, I think you'd be able to find more people than just me doing it. In fact, it would probably make Drupal one of the leading platforms for Pocasting. Instead of getting all indignant with me about the tone that you're reading into my comments, why doesn't somebody just look into this?

Comment #12

dumell CreditAttribution: dumell commented 9 August 2005 at 14:06

Component:

upload.module

» node.module

If your Drupal 4.6 has "access control" set to "public", podcasting will work out-of-the-box automagically. Great.

But if your site has "access control" set to "private" - and there may be very good reasons to user this setting - you will probably not be able to get podcasting to work at all.

And changing access control setting once you are up and running will probably mess things up.

I have gone down the same road as Greg on this one. First I noted that if you use "public", your RSS feed will have absolute addresses to the MP3 files, like this:

<enclosure url="http://example.com/system/files?file=test.mp3" length="223680" type="audio/mpeg" />

and if you have "access control" set to "private" the links will be relative and your RSS will contain something like this:

<enclosure url="/system/files?file=test.mp3" length="223680" type="audio/mpeg" />

In this case, using relative url's, podcasting clients like ipodder and doppler will not be able to download your MP3 files. I presumed the fault was the relative url, although the XML file started with a base url definition like:

<rss version="2.0" xml:base="http://example.com">

However, tweaking the upload.module (line 306 in version 1.31.2.5 2005/05/25) to force a "http://example.com/" to be inserted before the url to make it absolute, did not help. And yes, anonymous users have access to files.

So I tried to download the file directly from the original HTML node with IE. On the HTML page of the node, the base url is defined as "http://example.com" and the link to the MP3 file is relative as "system/files?file=test.mp3". If I place the pointer on the link, IE tells me that the url to the file is: "http://example.com/system/files?file=test.mp3", no surprises here. When I click on the link to the MP3 file, a IE file download requestor appares saying "file name: text.mp3". And if I confirm, the file is downloaded correctly.

But if I right click on the link and use copy shortcut "http://example.com/system/files?file=test.mp3", IE opens a file requestor and tells me the name of the file is "files?file=test.mp3". This is a suprise. And if I confirm this, IE will tell me that it can not download the file because it is "not albe to open the internet site".

So, with a base url defined and a relative link to the file in the html page, I can download the file, but if I try to paste the absolute path to the file into IE, I can not download the file.

With Firefox both alternatives work.

Unfortunatelly, it seems both iPodder and Doppler runs into the same problem that IE does. Switching of "clean url's" does not make any difference.

Is the HTTP request to drupals access control mechanism (that system/files?file= thingie) getting corrupt in some way, or Drupal returning a HTTP respons that is not accepted by most clients? We are using Drupals multi-site feature and this might be adding to our problems. The problem does not seem to be in upload.module but perhaps in node.module?

Comment #13

dumell CreditAttribution: dumell commented 9 August 2005 at 14:43

Obviously I tried to write too much text at once :)

If your access control is set to public, the absolute links will not look like in my example above, since they will not contain that "/system/files?file=" -thingie. It would instead look something like "http://example.com/files/test.mp3". And this is important since requesting the file TROUGH Drupal instead of directly from the web server is what seems to be causing the problem for many or all (podcast) clients, atleast in a multi-site setup.

Comment #14

Boris Mann CreditAttribution: Boris Mann commented 8 September 2005 at 14:46

I can confirm this.

This is the same issue with *all* enclosures if files are set to "private". Something is busted somewhere, this needs to be fixed for both 4.6 and 4.7.