Rewrite for better Views integration / merge with FFPC ?

I've actually been looking into this. FFPC has some benefits, iTunes has different benefits.

I like it that the FFPC themes each row, but I don't like that it just grabs the information directly from the node. I like the iTunes form_alter so that people can add specific information for each episode (node) in addition to the Views options which set the channel information.

So with respect to FFPC, I think the iTunes module has a lot of potential and flexibility. Not to mention the ability to have multiple and separate podcasts on a site.

The difficulty is that everyone has their own content types that they want to stream. A podcaster might have a content type and a church a different content type, but there's only one iTunes format out there. I don't think mixing and matching is the solution (see ffpc_channels). Especially since Views fields could be used to mix and match.

The iTunes module solves some of the problems, but we still have issues such as how to remove or overwrite something in the podcast.

I spent this weekend trying to figure out a) how I would want this module to work with maximum flexibility and b) how the heck Views plugins work. I came up with a couple of proposals.

1. A new plugin (itunes_plugin_row_rss.inc).

We can use Views Fields to let people overwrite or remove fields. But they'd be responsible for labeling them according the the iTunes spec. Items that could be removed/modified via the Views interface:

1. itunes:author
2. itunes:keywords
3. itunes:author
4. itunes:summary
5. itunes:subtitle

(These items are set already through various iTunes options, but if for some reason someone wanted to just remove an item, they should be able to.)

The procedure for overwriting or removing would be to add a field (for example a cck field named "myauthor"), change the label to one of the above items (example "itunes:author") in that way "myauthor" would then overwrite whatever is coming in for "itunes:author". If they want to remove the itunes:author, then check "Rewrite the output of this field" and, for the text, type "remove". The plugin_row would then remove that item. (Note: this modifies each individual item, not the channel information)

Further, by using node_invoke_nodeapi and creating an "itunes" op, we could allow developers to overwrite/modify/add items before they're sent out. This would be an advanced feature so that anything that comes out of the nodeapi would be assumed to have priority over anything set by the Views Fields or preset in the Node iTunes fields.

This one plugin would solve

Add a field line style
Add choices for the item source
Add choices for the source

In regards to the last two issues, I like the current idea of selections in the iTunes admin page to help less advanced users. But for advanced users, they should have the ability to completely change things.

2. Integrate the file feature of ffpc with iTunes: itunes_plugin_row.rss.inc will REQUIRE that someone add a filetype to their Views Field. In this way, users can use whatever files they want and we can accomodate them. This would solve Restrict the files mimetypes ?

Adds so much new code and complexity, I'm simply going to upload the new module. I can certainly roll a patch against existing files, but for evaluation purposes, here's the module.

I've been testing it and running various things against it and it seems solid. Let me know if there are any issues, problems, or even general thoughts.

I'm interested in looking at what you've got but a patch is much easier for me to review. Not sure if you're aware of how trick CVS into adding files so you can roll patches but take a look at the fakeadd script

Can I simply add the patches together?

Attached: itunes.patch, itunes_plugin_row_rss.inc, itunes-view-podcast-feed.tpl.php, and readme.txt

guix:

- using the fields labels to map to itunes tags seems a bit hacky, there should be another way to do it but how ?

I would consider this an advanced feature to address Add a field line style. By using the Views Fields, someone can overwrite anything, add anything, or remove anything. This way, everything is kept inside the Views interface.

The majority of people wouldn't need this function and with my plugin the only Field they'd be required to add is the filefield. Actually, I could rewrite it so they wouldn't even need to add that (I took this feature from ffpc, but since iTunes has an admin interface that specifies where the file will come from, the plugin could be rewritten to use that). This would probably be a better approach. If I rewrote it to use only the iTunes file specified by the admin page, then the plugin would ignore any files coming in through the Views interface. <-- I like this.

- for the global settings of the itunes feed : they should be set in the View, which I think you didn't modify so that's OK

Nope, didn't touch anything for the Views options (which sets the channel info) and didn't touch anything on the iTunes admin page.

- for the individual itunes tags for each item : why allowing 2 different methods to set the item itunes tags ? For me it adds unnecessary complexity. Now we are mapping the items tags in the admin settings and we can change it for each content type.

Sure it adds complexity but it addresses two different set of people: Advanced users and module developers.

Admittedly, we could do without the node_invoke_nodeapi for 'itunes' ops, I just noticed it in the ffpc module (which was taken from a different module that invoked 'rss item' ops) and thought I'd toss it in for flexibility. I'm fine with removing that feature.

But I do like the idea of allowing Views Fields to overwrite/modify/add data.

If the editor changes the data mapped to the itunes tag, the itunes tags are updated in the itunes feed. If we moved the settings from admin settings to views, in the view you're always going to choose node data for the items tags. So if your editor updates the node, the view will update too and also the itunes tags it contains.

I don't think we should move anything from the iTunes admin page. I think the majority of users would use that to map their xml items. But by using the Views Fields, it would allow advanced users to do all sorts of stuff to all the nodes returned.

One example: say someone has a podcast and they need to change the author tag or the subtitle tag. Instead of going back and editing all the nodes individually, they could just overwrite it in Views Fields. Sure it's a narrow example, but it demonstrates the flexibility of the Views Fields.

In addition, if they want to publish their feed somewhere else and add a tag that's non-iTunes, they could also do that through a Field.

JaredAM, in terms of getting changes reviewed zip files totally suck. They're even worse than just posting the whole files. I can't just look at the changes and see what you're doing, I've got to download it, extract it, move them into a CVS checkout so I can get the diff. I goes from something I can do while checking email to something that I need to block out time to do.

Two issues.

First issue: I just discovered that if we don't select any Views Fields (by using the iTunes admin interface to select which file to use) then Views will not return rows to process and therefore won't use the rows plugin. Views needs either a field or a filter in order to return rows (and thus use the rows plugin).

I suggest removing the file selection field from the iTunes admin interface and requiring users to add the file through the Views Field (this is how ffpc does things and it's not very technical).

This also has the added benefit of allow users to publish two different podcasts using the same node. For example, someone might have a node that has both a video and audio version of their episode. They could create one feed for the audio (using Fields to select the audio file) and then create a second feed for the video (using Fields to select the video).

Second issue: On line 180 of my itunes_plugin_row_rss.inc

    // Use merge to allow nodeapi to overwrite data
    $extra = array_merge($extra, $node_extra_overwrite);

If node_invoke_api returns nothing, then my $extra array gets wiped out. This is bad. So either comment out that line or use this new file. (Of course, this problem goes away if we decide not to allow an itunes op as mentioned by guix)

JaredAM, as I'd mentioned in your other issue, please use the correct status values when there's a patch attached. See http://drupal.org/node/156119 for an expanded description of what each status means.

Also, if you need into on how to roll a patch take a look at: http://drupal.org/patch/create Hopefully you're using CVS to get the latest versions—if not I'd recommend it because it makes rolling patches a lot easier. I'd already linked to a scrip that helps work around CVS's problem adding new files to patches. I'll try to make some time to look at this tomorrow it seems like you and guix are having a productive discussion in the mean time.

Drew, I'm getting it!

Note to self: if you don't know how to use linux tools, cvs can suck. I finally gave up trying to use some linux tools to create patches and downloaded TortoiseCVS. Very nice.

Okay, here's the last patch with all my changes and new files and everything. Let me know what you think!

Great! That makes it a ton easier for me to look at it. Here's a quick review.

So stuff that jumps out at me as I'm giving it the quick skimming...
- template_preprocess_itunes_view_podcast_feed() seems like it's a copy paste from someplace in views. If that's the case put in comment mentioning where you got the code and what changes you had to make so if it turns out there's a bug we can go look and see if it was fixed in views already. If it's not copy/pasted then it needs more comments explaining what's going on.
- README.txt should be wrapped at 80 characters.
- itunes_plugin_row_rss has the same copy/pates commenting issue as
template_preprocess_itunes_view_podcast_feed().
- Eeek! seeing getid3_load(TRUE) in the middle of itunes_plugin_row_rss::render() makes me very nervous. Can't we just depend filefield_meta.module and rely on that to get the metadata loaded? I really don't want to be responsible for that. At the very very very least we need to add a dependency on the getid3 module but I'd love to do anything possible to avoid that.
- + // Make sure Views Fields hasn't set the itunes:keywords has me a bit puzzled... is Views Fields a module?
- The commenting style:

+    /* 
+      These elements are set at the node and probably shouldn't
+      be overridden by Views Fields but could allow it
+    */

isn't really used elsewhere in the module can we keep it as just // ?
- Seems like we could roll some of this:

+    if (!isset($extra['itunes:summary'])){
+      $extra['itunes:summary'] = $item->itunes['summary'];
+    }
+    
+    if (!isset($extra['itunes:subtitle'])){
+      $extra['itunes:subtitle'] = $item->itunes['subtitle'];
+    }
+    
+    $extra['itunes:block'] = $item->itunes['block'];
+    $extra['itunes:explicit'] = $item->itunes['explicit'];

up into a loop for clarity:

foreach (array('summary', subtitle', 'block', 'explicit') as $field) {
  if (!isset($extra['itunes:'. $field])){
    $extra['itunes:' . $field] = $item->itunes[$field];
  }
}

I'm not totally sold on the approach but I don't see any fatal problems yet.

so a little more thought on this and since it's a pretty big change that would break existing views, i think we'll need to do this in a 2.x branch.

- template_preprocess_itunes_view_podcast_feed() seems like it's a copy paste from someplace in views. If that's the case put in comment mentioning where you got the code and what changes you had to make so if it turns out there's a bug we can go look and see if it was fixed in views already. If it's not copy/pasted then it needs more comments explaining what's going on.

It's actually borrowed from ffpc and but it's pretty much the same as the function template_preprocess_views_view_rss in views/theme/theme.inc

I wasn't sure whether we'd want to do anything special so I added it. We can certainly use the default process depending on whether we need to modify anything like the source of the non-itunes description tag. Views takes the description tag from the node body field and if someone created a content type for their podcast, they may or may not use that body field.

You'll note that I wasn't sure what to put in that tag either so in the code you'll see

  $description = "what should go here? The itunes:summary?";
  $vars['description'] = check_plain(decode_entities(strip_tags($description)));

- itunes_plugin_row_rss has the same copy/pates commenting issue

While ffpc was the inspiration for this particular module, this module has been (and probably will be after we finish discussing it) modified quite a bit from the original.

- Eeek! seeing getid3_load(TRUE) in the middle of itunes_plugin_row_rss::render() makes me very nervous. Can't we just depend filefield_meta.module and rely on that to get the metadata loaded? I really don't want to be responsible for that. At the very very very least we need to add a dependency on the getid3 module but I'd love to do anything possible to avoid that.

I don't have a problem with using the metadata info but it does need to be reformated from seconds to HH:MM:SS. We could remove the getid3 code and it would simplify the module.

- + // Make sure Views Fields hasn't set the itunes:keywords has me a bit puzzled... is Views Fields a module?

Basically, I'm getting all the information set in the Views Fields (the "fields" section in the Views UI). If someone sets a field and labels it "itunes:keywords" then they want to overwrite what was set in iTunes admin as keywords.

The reason I like the ability to overwrite stuff is that I'm designing a site for a church and they have staff bio pages, but no user profiles. I would like the ability to link the itunes:author with the staff bio page via a nodereference. It's fairly easy to do in Views, but would require extra effort to do it through the iTunes admin page (not to mention I might want the info formatted a certain way). Same issue with specifying special fields for itunes:summary, itunes:subtitle, or other non-itunes tags that might be needed for other podcast aggregators.

I like it that the iTunes module adds the subtitle and summary fields at the create content page (makes everything easy), but I also like the idea of tying a cck field to the itunes:summary or itunes:subtitle in views. If it's tied in Views then I could skip those iTunes fields when I create a new content. If I'm designing a site for a church, I could simplify the node/add form by making a template to hide the iTunes fields that are taken care of in Views.

I also like the idea of a nodeapi "itunes" op for the same reason: I could create a module for formatting certain values in the itunes feed (but I'm okay with not adding this feature).

I'll admit that overwriting or modifying stuff is an advanced feature, but it's one that I know I'll use and others might need it as well.

I do like the your idea of a foreach loop instead of checking each field!

I'll be happy to roll another patch (now that I know how to properly do it) once we figure out where we're going!

Yeah I'm wondering it it might make more sense to look at providing the iTunes data as fields for Views then add those fields to the view and look at the page handler's settings for handling the mapping. Think about the way that the table handlers settings work. You can put the fields into the order you'd like, put multiple fields one cell, control sort order. We could easily say use this value for the copyright, this value for author, this field for enclosure, etc. As long as the default view has it structured correctly I think users will be able to figure it out.

If it's Node Reference you want for itunes:author it's really easy to add like we did for User Reference here : #481072: Add choices for the source

Yeah, but for the itunes:author a user reference is more straight forward than a node reference. So I'm not sure how mapping it in the admin interface would really be the way to go.

* Case 3
We mix, and it is what we are doing now, but I'm already forseeing confusion between the View override and the Admin settings (I'm changing it on the Admin settings page but "he" does nothing !!!)

I like case 3.

Well, I think that's where the README comes in. Out of the box, for the average user, I'd envision them installing iTunes, configuring the admin page, adding a file to the Views Field and calling it finished. Then they can go their happy way, add a new node, fill in the iTunes fields and they've got a quality iTunes feed. Simple and straightforward with as few configuration steps as possible.

But for those doing complex websites (like the church design I'm doing), we should accommodate people who want to use the power of Views Fields.

Last but not least, I'm really worrying about avoiding duplicate efforts between FFPC and iTunes, but one thing to consider is that the lastest commit in FFPC was December 30, 2008. Does somebody know mfer's plans ?

I do think there's quite a bit of overlap but I think FFPC is limited because there's no way to configure it. Author comes from the id3 tag (which may or may not be set), subtitle comes from the first 255 characters of node body (which may or may not be used in a custom content type), pubDate is the node creation date (not episode date), and itunes:owner & email comes from the site settings. You have to hack the module to change those values.

FFPC provides a quick podcast, but it's not very pretty. I think the iTunes module provides very high quality feed.

Yeah I'm wondering it it might make more sense to look at providing the iTunes data as fields for Views then add those fields to the view and look at the page handler's settings for handling the mapping.

My concern would be that for beginners, Views is a Very Scary Thing. So by having an iTunes admin it takes a lot of fright out of the process. Plus by having iTunes fields at node/add they could specify exactly what they want in the feed. The itunes:summary might be a shortened (or different) version of what they use for node:body.

I don't know about this scenario. I'm thinking that "beginner" might first focus on creating their content types with the podcast as an after thought. I had given consideration to this, but wouldn't we just be recreating the audio module?

I see the iTunes module as complementing existing content types rather than creating it's own and as it is, the module works good for that. It adds itself to my content type without getting in my way. I could have 2 or 3 content types that I want to feed and the module would make that work.

I'd prefer to avoid creating a node type as well. I'd rather focus on providing good defaults for the configuration.

I've been working on and testing the additional functionality (because even if we don't roll it into this module, I'll still need it for my projects). I did have a couple of questions and I also thought I'd summarize the new features on the table.

Existing Features:

1. Admin page so that users can select which content types they want to podcast. They can also select the filefield, vocabulary, and author.
2. iTunes adds fields to their node/add content types for easy podcasting.
3. Default View based on settings on Admin page.

I like the existing features which will help beginners easily podcast.

New Features:

1. Allow users to have multiple podcasts (for example an audio and a video podcast) by adding a Field to select the media they want to podcast.
2. Allow users to add/overwrite/modify xml items to fit their needs. If they have a custom content type that they want to map into a podcast feed (mix and match cck fields to itunes:fields), they can do so through the Fields section of Views.
3. Allow module developers to add/overwrite/modify xml items to fit their needs.

Questions:

1. Why is there a page defined in the default View? Is this needed?
2. Currently, the default view will set the filter based on what is selected on the Admin page. It will combine all the content types into one feed. I'm not sure this is the best way to go. If people have different content types, then they may want to have separate podcasts for each type. Maybe having the user set the filter might be the best way to go? That way they can choose to combine all content types in one feed, or set up separate feeds for each content type.
3. Default style options:
   owner_name => site name?
   owner_email => site email?
4. Should this module have it's own rss template or just use views_view_rss? The only place I can think of that this might make a difference is in the description tag. The description tag isn't used by itunes, but it is used by aggregators. Views will set the style (channel) description as the site mission and the row (item) description is ignored. I would think these should be the same as the itunes:summary fields.

Does anyone have any further thoughts?

I've spent some time testing the new functionality and rolled another patch.

* Removed itunes-view-podcast-feed.tpl.php in favor of views default views-view-rss.tpl.php
* itunes.views.inc now references views-view-rss as the theme
* itunes.module removed function template_preprocess_itunes_view_podcast_feed
* use filefield_meta to get the duration and convert to MM:SS format

Looking over the patch it seems a lot stronger but I'm not convinced that the whole mapping fields by label name is the best way to do this.

I'm also not sold on completely removing the hook_nodeapi 'rss item' operation. Then we're not outputting any enclosures for the default feeds which is one thing I like about the current approach. If we're building the entire feed the nodeapi bits won't be output so there's not harm in leaving them is there?

Hey drewish,

I'm open to other solutions on how to mix and match fields. I just think this might be the most flexible way without having a long admin page.

Regarding rss item: the problem with the way the module is now is that any time any module polls the rss items, the iTunes info gets sucked in. If it's a blog feed, it doesn't need the iTunes stuff. Also, when creating a podcast, the taxonomy module will stuff items into the feed which isn't needed since iTunes has it's own keywords (channel & item). I do think this issues could be fixed, but I'd have to look into it.

It might be possible to have the nodeapi function and the plugin_row coexist more peacefully...

Hey guys,

I've been looking for a module which makes podcasting in Drupal easy. I've tried FFCP, iTunes, Views_RSS but none really satisfied with the results. My setup is quite simple but nevertheless quite custom. I'm making a church website and we want to have Sunday sermon podcast. We store mp3 files on Amazon S3 storage service and in content create form I just specify an URL of the sermon. For now none of modules lets me specify custom CCK field for use in <enclosure url="{URL}" /> tag.

I found this issue and it inspired me to write a Views row plugin for iTunes module which does just that:

1. Let's you map node fields (core fields and CCK fields) to iTunes feed tags via regular Views Row style options. Create a view (or choose existing one), choose Style "iTunes RSS Feed", choose Row Style "iTunes Podcast Episode" and click on Options icon. Just start mapping.

2. Patch adds only one file to iTunes module (itunes_plugin_row_rss.inc) and adds row information to (itunes.views.inc). It doesn't break existing setting, only adds advanced mapping options. There are no template files since they are not needed. All the mapped node fields are parsed according to predefined iTunes tags. If you map Node:Title to iTunes <title></title> tag, the ouput will be just that: <title>{NODE_TITLE}</title>.

3. If you use remote file storage, you will have to make three custom CCK fields for enclosure tag attributes: URL, length and mimetype, then map them to appropriate attributes of the enclosure tag. If you are using FileField then FileField Meta module is your friend and with use of Relationship in Views you can have these values (length, mime type) as fields. URL of the file is available through regular CCK content field.

In other words, this is an advanced way to customize your podcast feed to whatever you like, given you know how Views works. For beginners it's a good way to get to know Views better since mapping in Views options is fun.

The patch is made against 1.x-dev version.

I'm attaching both a patch for those familiar with patching and developing and a zip file for those who just want podcasts to work or those who want to play around.

Maijs,

How does your plugin differ from mine?

JaredAM,

My version of the row plugin does not depend on field labels and does not interact with other plugins. It provides a row plugin option panel with ability to map fields to iTunes tag, that's it. You can have all you want in fields - title, file URL, audio duration, custom text, terms... Just map it DIY way. Look at the screenshot and you will get the idea. It's not my idea. Field mapping is actually an idea that comes from Views_RSS module. My version of the plugin is iTunes and Views_RSS combined together.

Cheers

Just looking at the screen shot it looks like it's along the lines of what I'd been thinking. I'll try to make some time to review the patch.

drewish,

As we all know, Views is a powerfull module which makes it easy to output almost any data from the nodes.

Therefore I propose to get rid of alteration of node create/edit form which provides summary, subtitle, explicit and block form elements. Instead, I suggest the following:

1. In iTunes administration page, allow user to select only content type to be podcast. No Filefield, no user options.
2. Upon selection of content type, CCK fields are created (summary as text, subtitle as text, explicit as option widget and block as checkbox).

Why so you may ask?

Bringing iTunes specific information in itunes_item table makes it harder to import content from outer sources and then make it podcastable. One has to put data also in itunes_item data. With CCK fields, import is more straightforward and less buggy.

By avoiding admin pages as much as possible, iTunes module may become pure Views plugin which only does what's expected - outputing the data in iTunes compatible format.

Of course, by ditching admin page we must take care of beginners and those unfamiliar with Views. Tutorial and documentation of how to make a basic podcast should also be provided.

I'm not prepared to drop support for the custom fields yet. I think they still have advantages over doing every thing in CCK. I'm not too concerned about beginners because we can provide a default view that will work out of the box and they can use that as a starting point. I'd like to just focus on enhancing the views plugin at this point.

drewish,

Can you elaborate in what way custom fields have advantages over CCK fields?

Cheers

The immediate ones that come to mind are:
- speed by avoiding CCK's overhead
- avoiding the dependency for sites that don't want to use CCK
- the ability to perform more accurate validation than CCK would allow
- the difficulties of creating fields during the installation process:

Take the itunes:category for example. How would you propose representing that in CCK? Adding a new custom field?

drewish,

I mostly agree with your points, altough creating fields during installation is no issue. CCK allows fields to be pre-added upon installation. As for itunes:category tag value, CCK indeed is not needed in channel information, iTunes Views style plugin now takes care of that information pretty good. Podcast channel info must be entered manually anyway. What I meant is not removing custom fields in Views Style plugin options rather than custom fields on node create/edit page and transform those fields to CCK.

I guess both ways can coexist in iTunes module. It's just that for me custom fields is an avoidable approach if it can be done with CCK. It just adds more flexibility to advanced users. With row plugin I posted in #24 I get the result from existing CCK fields without setting anything in Site configuration > iTunes options. (itunes table is still there in DB but I can swallow that, gee).

Cheers

i'd be fine with making the feed field's source selectable but i believe that creating the per node fields in a non-cck manner is the best approach for now.

drewish,

Is that correct that you don't plan to apply the patch #24?

As I said before, both ways can be achieved by using different row styles: with Node feed is populated with data from non-CCK fields, with iTunes Podcast Episode feed is populated with data from CCK fields.

Are all of these included in some kind of alternate install package or a single patch of some sort? I'm having trouble with the combo of file field (to include a PDF that goes with the audio), audio, and itunes module to set up a podcast for a friend. Right now the itunes feed is including the 1pixelout player embed code in the itunes feed as part of the description. I'm hoping these patches would give me the ability to eliminate that info from the itunes feed.

Any ideas?

@craigkendall, the patch in #24 will let you have yout podcast the way you like. Either include pdf or mp3 in your episodes. You have to make extra custom cck fields for URL, duration, media type and file size (if you don't use FileField Meta module installed) or just use FileField Meta provided fields.

#20 says:

Should this module have it's own rss template or just use views_view_rss? The only place I can think of that this might make a difference is in the description tag. The description tag isn't used by itunes, but it is used by aggregators.

But according to the podcast specs:

Pay very close attention to the title, author, description, and keywords tags at the level of your podcast feed, because these are the fields that iTunes indexes for search

Seems like description is important! I would really like a way to have this filled out. In the RSS example at the spec above, it has the same text in channel/description as in channel/itunes:summary.

Thanks.

thanks @maijs I just saw this post... how do I subscribe to know when these are updated?

@craigkendall, whether follow this issue or watch for Reports > Available Updates in your Drupal installation (Update module needs to be enabled for this to work).

maijs I'm having trouble getting your patch in #24 working. Are you using filefields or the audio module to upload you podcast? Also, how is the getID3() module integrating with your patch?

Live Example http://www.ivawbeta.org/podcast/rss.xml

animelion, what you mean by "trouble getting the patch working"? Does it fail to patch or you want to know the setup workflow?

I do not upload any files in my setup, I host the files on Amazon S3. I have a CCK field "URL" where I put the url of a .mp3 file. Then I have CCK fields for length and mimetype (text and option widget) for other enclosure tag attributes. If you are using filefield meta module, you have to add a relationship in views in order to get meta data in views fields. After you've set up a file relationship, you can setup meta data fields. Then in style display options map your views fields to podcast tags and you're done. See the screenshot in #26.

There's a corresponding conversation on merging going on on the FFPC side: #350971: Merge with or defer to iTunes module?

I tested both types of patches -- #1 and #24 -- and if we use #24, it's really difficult to get other fields.
But in #1 and the developed patches, we only have to CHANGE the default settings and the module can do the rest.
I couldn't even manages to get links correctly and file type was completely forgotten.
But it's really easy to set a field from a drop down list - that's all.
We could create a good itunes feed using Views RSS module as well, if we use something like #24 - but it's a very good approach.

I also tried ffpc and it's worst in customizing.