Category: Technology

Flowplayer and Podcast Producer 2: The Code

I’ve received quite a few comments about my previous post “Adding Flowplayer to Podcast Producer 2.” I’m pleasantly surprised by this feedback regarding my workaround to what is, in my opinion, a significant deficiency in Snow Leopard Server. I’ve responded to a couple of these commenters by direct e-mail, but perhaps it would be more efficient if I just shared the relevant code and provided some step-by-step directions.

Let me begin by speaking to this “significant deficiency in Snow Leopard Server.” As I said in my previous post: while there “might be valid reasons for Apple sticking with the Quicktime plugin rather than using a more modern-looking javascript player…I can’t think of any reasons that would excuse Apple from not providing its Snow Leopard Server customers with the option to make videos look as good as on Apple’s site.” I am still hopeful that Apple will come to the realization that they should share with their Server customers the javascript player code they use on their own site to present videos. It would be in their best interests to do so, especially given the recent comments by Steve Jobs that Adobe Flash is a “CPU Hog” and the source of 90% of Safari crashes. Committing Apple to standards-compliant HTML 5 is noble, and I agree that Flash deserves to be criticized. Flash does hog CPU cycles, and I’m a believer in the future of HTML 5.

But as a practical matter, Apple’s SL Server customers need to be able to deploy videos on the web NOW, and to be able to have those videos viewed by ordinary people using ordinary web browsers on ordinary computers…including the vast numbers of ordinary Windows computers out there. And the Quicktime plugin doesn’t cut it as a Flash player replacement. Isn’t that why Apple’s own web site uses javascript extensively to present videos without using Flash players? Apple doesn’t rely on the Quicktime plugin to present videos on its web site, so why do they sell a server product that uses the Quicktime plugin to present videos on the web? It isn’t for lack of javascript in SL Server: there’s oodles of it all over the pages produced by Wiki Server. And I suppose Apple could say you could roll your own javascript player to mimic what Apple does on their own web site, but why should we have to reinvent the wheel?

I suspect one reason why we don’t see the slick javascript used by Apple on its website integrated into Wiki Server is because Apple’s own web developers don’t talk much with the developers of Apple’s Server software. And that’s a shame. Steve Jobs, if you’re listening…could you get these two groups together for an afternoon of sharing? If you really want to wean the world off of Flash, why don’t you start by giving your server customers a real alternative to Flash—a full-featured javascript player—rather than relying on the Quicktime plugin in your server product?

Until Apple delivers a real alternative to a Flash player in their server product, here is my detailed description of the workaround I’ve developed. In essence, I have modified the javascript in Wiki Server so that videos are presented using Flowplayer (a very nice Flash player) rather than the Quicktime plugin. Here’s how I did it:

Step 1: Download Flowplayer from http://flowplayer.org/, and upload it to a directory on your web site. As I write this, a basic download of Flowplayer will include the files flowplayer-3.1.5.swf (the core flash player) and flowplayer.controls-3.1.5.swf (the core flash controller bar). It will also include (inside the example folder) the flowplayer-3.1.4.min.js file, which is some basic javascript you need to load into the pages where you want to use Flowplayer. (Technically, Flowplayer will work without this bit of javascript, but in most cases you will want to have this javascript loaded onto your pages so that you can use Flowplayer’s javascript API.) So in order to add this javascript reliably, I add a SCRIPT tag that references this file in a custom theme, which is the next step…

Step 2: Create a Wiki theme that includes a reference to the Flowplayer javascript. The easiest way to do this is to copy an existing theme and make changes to the copy. You’ll find these themes in /Library/Application Support/Apple/WikiServer/Themes/. I used the Snowleoplard theme as the basis for my custom theme. I opened a terminal window, changed to the theme directory, and used the ditto command as root to make an exact copy like this…


cd /Library/Application\ Support/Apple/WikiServer/Themes/
sudo ditto snowleopard.wikitheme/ customthemename.wikitheme/

Replace “customthemename” with a descriptive name of your choice (no spaces). In my case, I called my new theme “snowleopard-wcu.” If you have the “Wiki Server Administration” manual handy, you might want to refer to chapter 3 for more information about creating a custom theme. There you’ll see that an important step is to edit the theme.plist file so that your new custom theme can be selected in the wiki settings. At the very least, you’ll want to change the “display name” and “name” values to match your new theme. Here’s what my custom theme’s plist file looks like…


<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>displayName</key>
<string>WCU Theme</string>
<key>name</key>
<string>com.apple.snowleopard-wcu</string>
<!--
<key>mobileHeaderColor</key>
<string>#3772bc</string>
-->
<key>commentSortDirection</key>
<string>DESC</string>
<key>version</key>
<string>2</string>
</dict>
</plist>

Now I need to add a line to the theme’s default.xsl file that inserts the Flowplayer javascript file. Below is the relevant portion of my default.xsl file (with the vertical ellipses indicating there is code above and below this snippet):

.
.
.
<xsl:template match="page">
<html lang="{context/locale}">
<head>
<script src="http://communication.wcupa.edu/flowplayer/flowplayer-3.1.4.min.js" language="JavaScript" type="text/javascript"></script>
<!-- meta tags -->
.
.
.

Of course, you’ll want the URL in the src attribute to point to where you’ve saved your flowplayer-3.1.4.min.js file (please don’t point to mine!). Now save the default.xsl file, and reboot the wiki server by issuing this command in a terminal window…

sudo serveradmin stop teams; sudo serveradmin start teams;

Alternatively, just issue the stop command, wait for confirmation, then issue the start command. Once the wiki (teams) service has restarted, go into a wiki that you want to change to the new theme. Login, click on settings, and click the “choose themes” button (on the Blog tab). If all went well, your new custom theme should be available in the list. Select it and click OK.

Now you have a theme that will include this all important little bit of Flowplayer javascript on every page. Wherever you want Flowplayer, use this theme. If it’s important that you have Flowplayer in all of your themes, I suppose you could make the changes I describe above to all of your themes. But keep in mind that Apple could overwrite the stock themes that come with SL Server in a software update. If you want to insure Flowplayer works even after a software update, I recommend that you use a custom theme.

Step 3: Edit the wiki.js and compressed_wiki.js files to use Flowplayer instead of the Quicktime plugin. These two files are essentially the same, although the compressed file isn’t formatted with a lot of spaces and indents. It’s a lot easier to edit the wiki.js file, and then just use your favorite text editor to do a search and replace to make the exact same changes in the compressed file.

First, make a backup of these files, just in case. Both of these files are located in usr->share->collaboration->javascript. Make a backup of the files using your favorite method (using ditto in the terminal or just copy using the finder). Put the backups in a safe place. I can’t stress this enough: save a backup of the original files in case you need to revert to them.

Next, open wiki.js in your favorite text editor (I use TextMate). We’re going to change the value of the variable objectHTML. Here is what this variable looks like before our edit…


var objectHTML = '<object classid="clsid:02BF25D5-8C17-4B23-BC80-D3488ABDDC6B" width="'+img.width+'" height="'+(img.height+(extendHeight?16:0))+'" codebase="http://www.apple.com/qtactivex/qtplugin.cab"><param name="SRC" value="/collaboration/fake.qti"><param name="QTSRC" value="'+fullSrc+'?sessionID='+server().sessionID+'"><param name="TYPE" value="video/quicktime"><param name="SCALE" value="aspect"><param name="AUTOPLAY" value="true"><param name="CONTROLLER" value="true"><param name="TARGET" value="myself"><param name="BGCOLOR" value="'+backgroundColor+'"></object>';
// Firefox wants only an embed tag, and it has to be written using innerHTML. Also, have to hide image *first*
if (MozillaFixes.isGecko) {
Element.hide(img);
embed.innerHTML = '<embed src="/collaboration/fake.qti" qtsrc="'+fullSrc+'?sessionID='+encodeURIComponent(server().sessionID)+'" type="video/quicktime" autoplay="true", controller="true" target="myself" bgcolor="'+backgroundColor+'" width="'+img.width+'" height="'+(img.height+(extendHeight?16:0))+'" pluginspage="http://www.apple.com/quicktime/download/" scale="aspect" />';
}

…and here is what this variable looks like after my edit…

var objectHTML = '<object width="'+img.width+'" height="'+(img.height+(extendHeight?16:0))+'" data="http://communication.wcupa.edu/flowplayer/flowplayer.commercial-3.1.4.swf" type="application/x-shockwave-flash"><param name="movie" value="http://communication.wcupa.edu/flowplayer/flowplayer.commercial-3.1.4.swf" /><param name="allowfullscreen" value="true" /><param name="allowscriptaccess" value="always" /><param name="flashvars" value=\'config={"plugins":{"controls":{"height":"16","backgroundColor":"#330033","timeColor":"#eeee99", "progressColor":"#cccc99","bufferColor":"#774477","sliderColor":"#777777","timeBgColor":"#222222"}},
"key":"#####","clip":{"url":"'+fullSrc+'?sessionID='+server().sessionID+'"}, "canvas":{"backgroundColor":"#550055"}}\' /></object>';
// Firefox wants only an embed tag, and it has to be written using innerHTML. Also, have to hide image *first*

if (MozillaFixes.isGecko) {
Element.hide(img);
embed.innerHTML = '<embed src="http://communication.wcupa.edu/flowplayer/flowplayer.commercial-3.1.4.swf" allowFullScreen="true" bgcolor="#333333" width="'+img.width+'" height="'+(img.height+(extendHeight?16:0))+'" align="middle" type="application/x-shockwave-flash" pluginspage=http://www.macromedia.com/go/getflashplayer" flashvars=\'config={"plugins":{"controls":{"height":"16","backgroundColor":"#330033","timeColor":"#eeee99", "progressColor":"#cccc99","bufferColor":"#774477","sliderColor":"#777777","timeBgColor":"#222222"}},
"key":"#####","clip":{"url":"'+fullSrc+'?sessionID='+server().sessionID+'"}, "canvas":{"backgroundColor":"#550055"}}\' />';
}

Note that you’ll want to change the src values to point to the URL of the location of the Flowplayer swf file that you’re using on your site. I’m using the commercial version on my site, although I’ve changed the key value in this post to just #####. I don’t think the Flowplayer folks would like me sharing my key value, and besides, I don’t think it would work outside of my domain anyway. If you’re not using the commercial version of Flowplayer, take out this key value. I’m not sure if all of the “flashvar” options I’ve set here will work in the same way with the noncommercial version, but I think most will, as I don’t think I’m doing anything too exotic. You might want to change the color values of the player to match the look of your site, and fiddle with the flashvars to taste.

Once you’ve changed the value of the objectHTML variable in wiki.js (and in compressed_wiki.js), I would suggest backing up these modified files, and saving them in a safe place. That way, if a software update ever overwrites these javascript files, you can easily copy back your modified files. Of course, I’m hoping that one of these days, a software update to SL Server will modify this variable so that it doesn’t use the Quicktime plugin, but until that day comes, you can use the method I’ve described here to use Flowplayer instead.

You may need to restart your server after making these changes. And you may need to study my code and the example code on Flowplayer.org to get Flowplayer looking just right on your site. But with patience and determination, you should be able to get Flowplayer running on your site without too much trouble.

I hope this helps those of you who commented on my previous posts, and anyone else in a similar situation who stumbles across this post. And if you discover any additional tweaks or insights into this process, please consider sharing in a comment.

Why iWant iPad

Apple has officially announced the iPad. And iWant one.

The iPad hasn’t even been officially released, and it’s already being panned by critics who just don’t get it. Moments after the iPad announcement, Fake Steve Jobs (Dan Lyons) called it “underwhelming.” Many see it as just a big iPod Touch or an “iPhone on steroids.” Others compare it to Tablet PCs, which have been largely unsuccessful. Some wonder if the iPad will be just a newer Newton, one of Apple’s biggest flops. There are those who are disappointed by the lack of a camera. Or the apparent inability to support Flash content. Or the big bezel around the 4:3 ratio display. Or the onscreen keyboard. Or a host of other nitpicking criticisms that, in my mind, miss the whole point of iPad.

And that point is best summed up by Jonathan Ive in the opening lines of the promotional video: “When something exceeds your ability to understand how it works, it sorta becomes magical. And that’s exactly what the iPad is.”

Yes, the whole point of the iPad is to be magical. Sure, one can already do much of what the iPad can do on a laptop or an iPhone or an iPod Touch. And many of the initial criticisms of the iPad have come from comparisons to other things that can do what the iPad can do.

But I don’t want an iPad because of what it can do. I want an iPad because of how it will do it. And from what I’ve seen, it does indeed look like magic. Understated elegance. Intuitive interface. Brilliant display. Screaming fast. Amazing price. Serious magic.

And iWant that magic.

I don’t want the iPad to replace my MacBook. Nor do I want it to replace my iPhone or iPod. And I don’t expect it to. Yes, I will probably use the iPad to read my email, keep my calendar, show off my photos, listen to my tunes, watch some videos, and surf the web. But I don’t want an iPad just to do those things. I want an iPad because I want to do those things (and more) in a new way, a fun way, even a magical way.

And iWant what could be the iPad’s killer app: iBooks and the iBooks Store. I’ve been holding off on getting a Kindle. I was really tempted to buy a Nook. But I’ll put down my money for an iPad, so I can read books in full color, on a bright, backlit screen. I know there are those who say it will be hard on the eyes, that monochrome e-ink displays are better. I don’t think so. I’ve spent some time with a friend’s Kindle, and I didn’t find it particularly easy on the eyes. If anything, I found it harder to adjust to an e-ink display after spending most of the day looking at a computer screen. Maybe my eyes are different. Or maybe I just don’t buy the argument that a black-and-white display is somehow better than one in full, glorious color. Go figure.

And even if my eyes do tire after an hour or two of reading iBooks on an iPad, at least I can do something else with it besides read books. A whole lot more than I could do with a Kindle, or a Nook. And for not a lot more money.

It would be nice if Apple gave an educational discount on the iPad. Apple typically does give a small price break to educators and students. It wouldn’t surprise me if they didn’t give one on the iPad, at least not at first. But I would be very surprised if Apple didn’t eventually have some kind of promotion to make the iPad even more affordable for the education market. Perhaps in their next “back to school” promotion, in time to get iPads in the hands of college students everywhere. Who knows? Maybe the iPad will even make reading textbooks fun again. OK, maybe reading textbooks was never fun. But I’ll take anything I can get that would help my students get more out of reading them.

So let the naysayers and critics write all the negative reviews they want. I’ve heard this kind of reaction to Apple products before. Some people have been calling the Mac a “toy” since the day it came out in 1984. Some people predicted the iPod would never catch on, and that the iTunes store would never be successful. Some people even thought the iPhone would be a flop. And some people today think the iPad will be a failure.

Some people never learn. If there’s one thing Apple can do, and do well, it’s create products that people want. And I firmly believe that people are going to want the iPad. Lots of people.

I know iWant one.

Adding Flowplayer to Podcast Producer 2

Today I had another breakthrough in my implementation of Podcast Producer 2, a core part of Snow Leopard Server. As noted in my previous posts, PP2 is “still a work in progress,” but it is also a vast improvement in many ways over my previous video transcoding system based on ffmpeg and Drupal. I’ve been consistently impressed with the quality of the videos produced by PP2, although the file sizes are a bit larger than what I squeezed out of ffmpeg. But one thing that hasn’t impressed me is the “plain vanilla” look and minimal functionality of videos presented using the Quicktime plugin.

I realize there might be valid reasons for Apple sticking with the Quicktime plugin rather than using a more modern-looking javascript player. But for the life of me, I can’t think of any reasons that would excuse Apple from not providing its Snow Leopard Server customers with the option to make videos look as good as on Apple’s site. Almost everywhere you look on Apple’s website, you see snazzy-looking Quicktime presented in cross-platform stable players, typically built in javascript. Even the new Quicktime player that is included with Snow Leopard client gives you a javascript option when exporting a video for the web. So why didn’t Apple provide a javascript player option with Podcast Producer 2? At the very least, Apple could have provided some configuration hooks to make it easier to do something other than present videos using the Quicktime plugin.

But where there’s a will…there’s got to be a way. And my “breakthrough” today was in finally finding that way. It isn’t using one of the various javascript players you can find on Apple’s site. Those aren’t at all well-documented, and trying to piece together something workable from the clues found in page sources is not my idea of a fun afternoon. No, the player I’m using to present the Quicktime videos produced by Podcast Producer 2 is Flowplayer, a really great little Flash-based player.

With my previous ffmpeg/Drupal system, I had been using a Flash-based player to present the videos: the venerable JW Player (now a product of Long Tail Video). But for a variety of reasons, I couldn’t get this player to work right with the m4v Quicktime files produced by the PP2 system. And the look of JW Player is getting a bit dated, although not nearly as dated as the look of the Quicktime plugin. Flowplayer, on the other hand, is modern-looking, clean and well-documented. The key to getting Flowplayer to work with PP2/Wiki server was finding just where to put the code…something that I mentioned at the end of my last post.

So today, after editing some code in the wiki.js and compressed_wiki.js files (both located in usr->share->collaboration->javascript), I now have Flowplayer injected instead of the Quicktime plugin whenever a user clicks on a thumbnail. The main edit was to the objectHTML variable (quoted in my previous post). In essence, instead of referencing the Quicktime plugin, I referenced the SWF player file included in Flowplayer, and passed to it the same parameters that had been going to the plugin. To keep things in line with the way the Quicktime plugin had been injected, I used the OBJECT method of inserting Flowplayer. To keep Firefox happy, I echoed this change using the EMBED method found in the embed.innerHTML variable in the code right below the objectHTML variable. I also tweaked the height adjustment, adding 24 pixels to video files and 8 pixels to audio files (using extendHeight?24:8) to accommodate the slightly higher control bar of Flowplayer. And to get the Flowplayer javascript file loaded, I added a call to this file in the head of the default.xsl file in the Wiki theme folder (and in the enclosed compressed folder). And that’s pretty much it.

Now videos on my site look so much better, with a decent looking control bar that I can customize to my heart’s content. Time indicators? Check. Slick color instead of boring monochrome? Check. Volume slider you actually notice? Check. Seek bar with time points? Check. Big bold play and replay buttons? Check. Options galore for tweaking things just right? Check.

It did take some effort to get my head around the code I needed to adjust in Apple’s javascript files. And yes, my changes will most likely be overwritten by a software update, so I’m being careful to backup my edits. But now that I understand where to make the changes, and how, I think I will continue to use Flowplayer instead of relying on the stock Quicktime plugin to present PP2-produced videos.

At least until Apple does the right thing and finally brings to their Server product a decent javascript player…like the ones that have been used for a long time on Apple’s own web sites.

Getting Podcast Producer 2 to Play Nice With Windows

In my last post, I wrote about my experiences with Podcast Producer 2: the good, the bad and the downright ugly. Well, I had a bit of a breakthrough today in getting Podcast Producer 2 to “play nice with Windows,” so I’m posting my “new and improved” workaround.

As I described earlier, the main problem is the way PP2 posts videos to user blogs maintained by Wiki Server (which is a core part of Snow Leopard server). The primary culprits are the width and height tags that are included in the IMG tag that is written to the blog entry. If the video files were of a small resolution, PP2 would typically write out height tags that were empty, which breaks Internet Explorer on Windows, since IE assumes an empty height tag means a height of zero. But even if the video files were at a larger resolution, PP2 would write out width tags that were narrower than the actual width of the video file, presumably to make the thumbnail smaller than the video. That breaks any browser on Windows, since the Quicktime plugin for Windows doesn’t seem to be able to scale videos to fit within the dimensions defined by smaller-than-actual width and height tags. It works fine on a Mac, since it appears that the Quicktime plugin for Mac can shrink videos to fit into whatever dimensions are defined in a web browser.

My workaround was to manually edit these entries, removing the width and height tags. This would make the thumbnails full size, the same size as the associated video files denoted in the ALT attribute of the IMG file (a rather non-standard use of the ALT attribute, but that’s another issue). This workaround was a lot of work: manually editing the HTML of each and every video file produced by my server had become a daily chore. In the last month, I had edited over 1,000 blog entries. But at least the videos would play on Windows.

I had originally thought I should be able to fix this by changing the code found in the “_podcast.html” file found in the WikiTemplates folder in Library->Application Support->Apple->WikiServer. After all, this file looks like the exact template used by PP2 when it posts to WikiServer. But even though I removed the width and height attributes from this template file, it had no effect on the blog entries posted by PP2. I have since found that these templates are not used by PP2; they are used by WikiServer itself. That is, when you go to a user blog, click the plus sign to manually add a blog entry, and select the option to add podcast content, the resulting code is drawn from the _podcast.html file in the WikiTemplates folder. So PP2 must be getting the code from somewhere else.

Today I found out where: in a line of code in /usr/lib/podcastproducer/actions/wikiserver.rb. Near the top of this file is the following line…

MOVIE_ERB_TEMPLATE = "<%= h($properties[\"Description\"]) %> <br> <br> <img src=\"<%= poster_image_url %>\" alt=\"<%= published_url %>\" width=\"<%= width %>\" height=\"<%= height %>\" class=\"aligncenter posterimg\" />"

Bingo. I just took out the width and height tags from this line and restarted the server. Now PP2 doesn’t write out the width and height tags when it posts video podcasts. And I no longer have to manually edit the posts produced by PP2 to enable them to work on Windows. Hallelujah.

While studying this file, I think I discovered what may be the reason why PP2 is mucking up the dimension attributes. Further in this file are these lines of code…

if width > 480
height = PcastQT.info(input_published_path, "height").to_i * 480 / width
width = 480.0
end

So if I understand this correctly, what this does is check if a video is wider than 480, and if so, force it to stay at a width of 480 and adjust the height downward proportionally. That is, if a video has standard “VGA” dimension of 640 wide by 480 high, this bit of code forces it to be 480 wide by 360 high (the original height 480 multiplied by 0.75, or 480/640). And again, this scaling of the thumbnail downward is what seems to be breaking the Quicktime plugin on Windows.

I’m still not sure why videos that are smaller that 480 wide are being posted by PP2 with an empty height attribute, but I have a theory. I notice that in this section of code that the width is explicitly defined by this line of code:

width = PcastQT.info(input_published_path, "width").to_i

But height is not explicitly defined UNLESS the “if width > 480″ is evaluated true. This could be why I’ve discovered that for smaller submitted videos (say at a resolution of 320 by 240) the code being posted by PP2 has an empty height attribute (specifically, height=””). But whether or not this theory is correct, I’m happy that I’ve discovered a fix. By removing the width and height attributes completely from the MOVIE_ERB_TEMPLATE line of code, I’ve effectively addressed both the empty height attribute problem and the scaled-down width attribute problem.

Of course, Apple is likely to rewrite this file with a software update. Here’s hoping they correct this problem, so that I don’t have to hack the same file in the future. But just in case, I’ve documented my fix here for my reference, and potentially for the benefit of others frustrated trying to get Podcast Producer 2 to play nice with Windows.

UPDATE: I think I’ve discovered where the code lives that swaps out the video file for the thumbnail when you click on it. It appears to be in the javascript file wiki.js at /usr/share/collaboration/javascript/wiki.js. Near the bottom of this file is an “expandMedia” function that’s part of the QTMediaExpander class. The “objectHTML” variable appears to contain the code that embeds the Quicktime object…

var objectHTML = '<object classid="clsid:02BF25D5-8C17-4B23-BC80-D3488ABDDC6B" width="'+img.width+'" height="'+(img.height+(extendHeight?16:0))+'" codebase="http://www.apple.com/qtactivex/qtplugin.cab"><param name="SRC" value="/collaboration/fake.qti"><param name="QTSRC" value="'+fullSrc+'?sessionID='+server().sessionID+'"><param name="TYPE" value="video/quicktime"><param name="SCALE" value="aspect"><param name="AUTOPLAY" value="true"><param name="CONTROLLER" value="true"><param name="TARGET" value="myself"><param name="BGCOLOR" value="'+backgroundColor+'"></object>'

I don’t think I should try to hack something here now, not with a PP2 server filled with 1200 videos and counting. But perhaps between semesters or over the summer break I’ll poke around here to see if I can’t get a prettier javascript Quicktime player instead of the plain vanilla Quicktime interface provided by the Quicktime plugin. Many people have requested a player that displays the elapsed time of the video, something I know is possible since Apple has such players on their own website (including here, for example).

Podcast Producer 2: Still a work in progress

I was eager to install Snow Leopard (SL) Server on the Mac OS X server I manage at work, primarily because of Podcast Producer 2 (PP2). This component of SL Server represents a major advance in functionality over the first version of Podcast Producer, which was introduced in Leopard Server. Unfortunately, after creating over 500 podcast episodes with PP2 so far, I’m convinced it’s still a work in progress. I’ve uncovered numerous little bugs that should have been caught in beta. I’ve reported these using Apple’s bug reporter (bugreport.apple.com), and so far I’ve heard back on exactly one of my bug reports with a terse message that it was a “known issue.”

Don’t get me wrong, I still think this is a great program. It’s much easier to configure and tweak than the first Podcast Producer, which was essentially unusable for my purposes. One great feature is the new Podcast Composer application, which makes it a breeze to create new workflows. The quality of the finished video podcasts is significantly better than what I was able to do previously with a combination of Drupal modules and the open source “Swiss Army Knife” of web video applications, ffmpeg. So all things considered, I think Podcast Producer 2 is worth the upgrade to Snow Leopard Server.

But I’ve discovered the hard way that it isn’t perfect, and some of the deficiencies are serious. I’m hopeful that Apple will soon release an update that addresses at least some of the issues I’ve identified. Until then, let me share a few of the annoying bugs I’ve found, and some of the workarounds I’ve discovered. I know from experience that when things go south, a webmaster’s best friend is Google, so perhaps some kindred webmaster will come across this blog entry and appreciate my documentation.

Earlier this month I documented three of these bugs with short videos that I posted to my MobileMe Gallery . If a picture is worth a thousand words, a video must be worth at least a few thousand more, so if you’re interested, I’d encourage you to check out these clips.

One of the biggest problems: PP2 doesn’t create episodes that reliably play back on Windows computers. This probably doesn’t come as a surprise; after all, this is a Mac program. But it’s a Mac Server program, and Mac Servers need to service Windows clients, so I would have hoped that this would have been better tested in beta.

Essentially, if you create a podcast from a video file using PP2, using a workflow that posts the podcast to the submitting user’s blog, the result is a blog entry that looks and works great on a Mac, but not on Windows computers with the latest Quicktime plugin installed. At first I thought this was an issue with Internet Explorer, and to some extent, the issues are greater with IE. But I believe the primary culprit is the Quicktime plugin, since I’m able to reproduce this bug with IE, Firefox and Safari for Windows. Yes, this bug even affects Apple’s own browser.

Thankfully, I’ve discovered a fix. The root of the problem seems to be the way that the podcasts are posted to the user’s blog. Rather than using an EMBED or OBJECT method, PP2 (and the SL Wiki Server that manages the blog service) links to the podcast via an ALT attribute to the IMG tag of the thumbnail, with a ROLE attribute added so that the thumbnail acts as a button for the video file. This is pretty slick coding, except for the fact that it doesn’t quite work right on Windows IF the HEIGHT or WIDTH attributes don’t match the dimensions of the video. And PP2 doesn’t insert the full HEIGHT or WIDTH attributes, presumably because the goal was to provide a thumbnail, not a full-size image. On a Mac, this is not a problem, as Quicktime on a Mac can play back fine within the scaled-down dimensions. But it’s a deal-breaker with the Quicktime plugin for Windows. If you click on one of these thumbnails on a Windows machine, the file loads, but you only hear the audio; no video appears. As best as I can tell, this is because the video doesn’t scale down to the dimensions provided in the IMG tag. Audio doesn’t have to scale so it comes through, but what’s the point of a video podcast if you can’t see the video?

The workaround is to delete the width and height attributes. While the result are full-size thumbnails, at least they work on Windows. Since I’m only deploying the iPod/iPhone resolution files (640 x 480), the thumbnails aren’t that huge. But it is a rather huge task to manually have to delete these width and height attributes. I would like to just delete this in the templates so that I didn’t have to do this every time a podcast is posted. And I can see where the templates are on the server. Unfortunately, editing the templates available in the Wiki Templates folder does not have an effect on the resulting code. Apparently, PP2 (or perhaps Wiki server) doesn’t read the contents of this templates folder when creating the pages. Perhaps there is some way to synchronize changes in the templates with the actual code produced (one would think there would be) but I’ve yet to discover it. If I find out, I’ll be sure to post an update. Until then, I’m manually editing the code of each podcast so that the majority of users who use Windows can actually see the videos.

It also would have been nice if the developers had included (or at least made available as an option) a Javascript player for the Quicktime videos posted to the user blogs by PP2. I find it interesting that nearly everywhere you see a Quicktime video on Apple’s own website, it’s presented in a Javascript player. Note only do such players look a heck of lot more “Web 2.0-like” than the standard OS 9 look of the Quicktime plugin, a more modern player might have alleviated the big problem of cross-platform playback. Indeed, one of my early efforts to develop a workaround for this problem was to present the videos using a Flash-based player (Dash Player by TMT Media). The Quicktime videos produced by PP2 will indeed playback quite nicely in an embedded Flash player (at least one that can handle MP4 files). But because making such a change would require extensively rewriting the code produced by PP2/Wiki Server, I eventually settled on the much easier (although still time-consuming) method of deleting the width and height attributes. I can understand why Apple wouldn’t include a Flash player with SL Server, but they could have at least put in a Javascript player.

Another small annoyance (and an almost humorous faux pas) is the fact that the “Subscribe in iTunes” link that is posted prominently on a podcast-enabled blog page doesn’t actually work. The workaround I’m using for that is to simply delete the button in the Theme files (which are honored by Wiki Server, at least if you’re careful to follow the rules carefully). For those users who want to subscribe to a podcast using iTunes, I send or post a link that does work, using an appropriate RSS feed from the Podcast Library (another nice addition to PP2).

One very serious bug I discovered has to do with overwriting files. I’ve always felt that one of the cardinal sins of programming is to create something that destroys data. But if you’re not careful, PP2/Wiki Server can do just that. It probably won’t happen very often, but given the volume on my server (between 500 and 1000 videos a month), it didn’t take long for me to find this bug. If a user submits a video with the same name as a video submitted earlier in the day, the older video is overwritten by the newer one. Actually, the older video still exists in the Podcast Library, just not in the podcast directory that is referenced in the code posted to the user blog. The workaround here is to manually edit the entry to point to the correct video in the Podcast Library. I’ve also taken some steps to try to enforce some naming conventions on PP2 users to help prevent this, although really, I shouldn’t have to do this. PP2/Wiki Server should be smart enough to not overwrite files, and I would hope Apple would squash this bug quickly, as it is genuinely serious.

Again, all things considered, I’m quite pleased with the advancements made with Podcast Producer 2. To be fair, most of the bugs I’ve found aren’t necessarily with PP2 per se, but rather reflect deficiencies in how PP2 works with Wiki server when writing podcasts to user blogs. My guess is that PP2 and Wiki Server (two very important components of SL Server) had largely separate developer teams working on them in Cupertino (or wherever the developers are located). Even so, one would hope the quality control teams at Apple would have tested this better before releasing it to the world. It would have been nice if “real world” users such as myself could have participated in the beta testing. As it is, I guess I am helping to beta test this product, since in some key areas, Podcast Producer 2 is still a work in progress.

Graffiti Networks Project ate my wiki!

Today I noticed something strange while backing up the database from another website I manage, ComWiki. The database backup took much longer than usual, and I was surprised when the size of the backup started to go over a gigabyte. Either someone had been adding lots of pages to the wiki, or something weird was going on.

So I went to the “All pages” page on the wiki and noticed a bunch of pages with strange titles that appeared to be spam-like URLs. Visiting those pages gave me a big shock, as the content appeared to be some kind of binary code. It sort of reminded me of the old Usenet rar files, line after line of gobbledegook that looked suspiciously like a slice of Warez.

Then I got an even bigger surprise, when I got a message on my screen that Google had detected malware on the site. Oh boy.

After doing some more digging, I found a note from something called the Graffiti Networks Project. Apparently, this was a project started by a couple of students at Brown University to exploit a weakness in MediaWiki, the open source software that runs Wikipedia (and the software I use on ComWiki). Essentially, the project demonstrated how one could use this weakness to establish a peer to peer file sharing network.

Here’s the more technical description from their website:

In response to the lack of user anonymity and long-term data persistence in existing P2P systems, we developed the Graffiti Network distributed file sharing protocol that uses multiple third-party storage sites as a data replication and transfer medium between clients. Our approach is to use publically available web sites to store multiple copies of shared content. We use the term graffiti for our work since we are storing data in a way that non-network participants may regard as unsightly or unwanted vandalism.

Employing the same concept of a central tracker as in the BitTorrent protocol, a Graffiti client will connect to a tracker and receive well-defined instructions on where and how to retrieve segments of shared files from a remote storage site. Upon successfully downloading and decrypting some portion of the shared data, the client will receive further instructions to replicate that same data at different storage site. If the client succeeds in replicating the data, it notifies the tracker of the new replica location to receive the next data segment it needs and then repeats the process. Our approach has several key benefits over other P2P systems where clients transmit data directly with each other:

A newly arriving peer can still download files even if all other peers have long disconnected
A peer does not need to know about the existence of other peers
A tracker does not need multiple peers in order to enforce tit-for-tat policies.

Wow. You would think they would have at least asked me first before they started hacking at ComWiki. But then I guess that would spoil the fun.

Anyway, I’ve taken ComWiki down for now and put up a “parking page” until I can sort out this mess. When I do get ComWiki back up, I’ll probably have to put up a bunch of security measures, like CAPTCHA-style “type the letters you see in the box” routines, in order to keep out spammers…and Brown University students.

I can understand the theory behind this “experiment.” But I don’t appreciate the ethics, or lack of them, in its execution. I get the impression that these students felt that they were simply testing a “proof of concept,” and that no harm was done by storing their “encrypted data payloads” on wiki pages. But just because something CAN be done doesn’t mean it SHOULD be done. In the social sciences, I doubt if this kind of “experiment” would ever be approved by a human subjects research board.

Sure, running an open wiki means one has to expect some vandalism. I’ve come to expect some “edit wars” when running an open wiki, as people try to use the wiki to advance a particular agenda. Yet I’m still a real believer in the value of open wikis. I like the fact that on an open wiki, one can quickly correct a typo or add an important point to an article. No need to register, no need to squint at a CAPTCHA. Just hit edit and do it. Free and open. Anyone can edit. Yes, that means you have to expect edit wars, but that’s part of the wiki culture. And sometimes you can learn a lot from edit wars. If nothing else, you learn something about those who feel so compelled about their views that they take the time to engage in an edit war.

But to set up a P2P system that exploits this openness takes the “edit wars nuisance” to whole new level, one that just seems wrong to me. I don’t really care if people want to use the internet to share music or movies or warez. Indeed, that’s become part of the culture of the internet, and there’s not much I can do about it. Nor does it seem there is much the RIAA and MPAA can do about it. But to exploit a weakness in MediaWiki (and in particular, a default open installation of MediaWiki) just seems to spit in the face of the Wikimedia Foundation, one of the biggest defenders of openness on the internet.

In my opinion, the real shame in all of this is that when I finally do get comwiki.org back up, it will have to be a more closed wiki, which defeats one of the major advantages of a wiki: the fact that “anyone can edit it.” In fact, at one point I did have comwiki.org more closed, so that only registered users could edit articles. But when I did so, I noticed a significant decrease in edits from users. So I opened it back up, thinking that this might encourage a more open, freely-editable wiki experience. It was just such a freely open wiki environment that these students sought to exploit with their P2P experiment. And now it looks like I’ll have to lock it back up. What a pity.

By the way, even though the Graffiti Networks Projects’s web site claims they used their “removal tool” to delete their “encrypted data payloads” as of April 11, three weeks later I am still getting tons of hits to the wiki from bots. In the time it took me to manually delete a bogus wiki page and its edits, another page or two would pop up. So far this month, the traffic on this site is over 12 gigs. And even after completely removing MediaWiki and putting up a temporary parking page, the domain name is still getting hundreds of hits every day.