TikiWiki Podcasts

• Blog Actions

OK. I got this working with the iTunes client..... feedcheck complains some but it complains about other public feeds that I checked (e.g. NPR feeds). Had to tweek some of the tags to get the right information to show up in the iTunes columns but no big deal.

• Need to document what I've found in the Theory of Operations
• Need to make a tracker of open development items, there are quite a few enhancements that are needed
• Need to create some "real" test content so I don't get sued
• Need to check out the iTunes music store, but I think support for album art will be required for that

The RSS version number Elizabeth choose is a problem.  Turns out that the RSS version is stored in the TikiWiki databases as a single character.  Not a byte, but a single character.  So the number 10 overflows the field.  I temporairly reused the number 6 which was assigned to OPML.  This will need to be addressed later.

I was going to call this debugging PHP, but the struggle is particular to TikiWiki. Turns out that tiki-setup.php overrides the error reporting level set in the php.ini file. The solution is to temporairly hard code the error reporting leve in each module that calls tiki-setup.php while debugging. Now on to the real problems......

I pulled a couple more examples from FeedBurner, thisWEEKinTECH, and MSNBC just for comparison. Those are now in the RSS_Comparison.xls file.

I also started studying the changes needed for generate_feed() so that the podcast variables are compartmentalized. One thing that I'm wondering is if it will hurt anything to include ALL the non-itunes tags in the basic RSS 2.0 feed. For instance would it hurt anything if all RSS 2.0 file gallery and image gallery feeds included the tag?

I spent most of the day sorting through the iTunes technical specification and the current output from FeedBurner based on the rss_lib.php changes from Elizibeth. There are a number of items that TikiWiki already supports that just need to be included in the feed; that's my next task. However there are a number of items that file galleries do not track (e.g. categories, keywords, etc.) that must be addressed with UI and database changes. I am keeping a comparision in the attached spreadsheet
RSS_comparision.xls

There is a problem with the RSS versioning for, at the least, file galleries when generating individual feeds for each gallery. The RSS link on the file gallery does not specify a version, tiki-file_gallery_rss.php does not specify a version, and lib/rss/rsslib.php:RSSLib->generate_feed() uses a default of RSS 0.91. It is quite likely that we will need to specify and store either a custom version that applies to all file galleries or possibly a custom version for each file gallery. More data to store.....

Might need to consider the XSL and CSS returned when the user clicks on the RSS feed in a normal browser. RSS 2.0 uses both an XSL and CSS but Elizabeth only added the CSS reference for PODCAST.

Now that I "think" I have the file extension issue figured out, I need a plan for getting all this into TikiWiki. My initial plan is to extend the work done by Elizabeth Dalton; she supplied me the files she modified. She really got far with the concept, but ran into the URL file extension problem with iTunes.

She was focused on making the feature available in a blog, but I'm going to concentrate on file galleries first because it is a simple extension to the existing functionality. I don't think that I'm ready to create a completely new feature "blog file attachments".

Found this rule that allows a podcast xml feed to be permanently moved. When iTunes or the iTunes music store podcast section accesses the link, the 301 will permanently update the subscribers url.
RewriteRule ^new_name.xml$ /feed [R=301,L]

301 - move permanently

I finally managed to get TikiWiki, CVS, and Elizabeth's code changes loaded. Studying the iTunes technical specification, I realized that the problem Elizabeth ran into might be quite simple. The iTunes specification says:



Now the example changed both the part before the ? And the part after the ? to end in .mp3, but the text implies that only the part before the ? matters. "If" the text is true, then this can be easily accomplished with an Apache rewrite rule; well we might be able to rewrite both portions. Something like this:

• Published Podcast URL: http://tikiwiki.org/tiki-download_file.mp3?fileId=9.mp3
• Rewritten URL for tiki: http://tikiwiki.org/tiki-download_file.php?fileId=9

a2enmod rewrite
Creates a symlink in /etc/apache2/mods-enabled from mods-available/rewrite.load
/etc/init.d/apache2 stop
/etc/init.d/apache2 start

Add to the virtual server in the section for the wiki document root:
RewriteEngine on
RewriteRule ^tiki-download_file\.mp3$ tiki-download_file.php

Test:
http://www.stovenour.net/tiki-download_file.php?fileId=1
http://www.stovenour.net/tiki-download_file.mp3?fileId=1

Now the podcast xml file needs to refer to the tiki-download_file.mp3?fileId=xx in the sections.