Patch develops _data functions for youtube, google, and zzz_custom_url.

Google addition gets the single item RSS feed for each video to gather metadata. This includes a very full MRSS section, this includes the likes of duration but sadly doesn't include enclosures so size has to be gathered otherwise (see zzz_custom_url method).

zzz_custom_url gathers data using a new function that calls the HTTP response headers for the file, which includes the mime-type and the size. This maybe worth extending to the allowed media types section, as it is almost more reliable than the file extension at identifying the mime-type. This detection would also work for images and audio if anyone is to develop enclosures or other meta-data for them.

YouTube, also doesn't provide a single item feed or information - that I could find anyway. So it uses the same method as zzz_custom_url. From experience with implementation it seems YouTube actually just puts a standard size in anyway though.

BlipTV was already collecting _data from MRSS, now additional fields are stored to be used in outgoing MRSS.

To make merging easier, and use more consistent, all data passed, also from emaudio, for RSS is an array rather than an object.

Where there is appropriate data from the providers in addition to an RSS2 enclosure the MRSS namespace is added and media:content and media:thumbnail are included. Each will be produced only if they have enough data to validate.

Emthumb is given the opportunity to override this. In the future I'm guessing an EmMetadata (or an extension on the Remote Enclosures) could be allowed to do similar.

CommentFileSizeAuthor
emfield rss and mrss patch v.1 (2008-04-21)28.21 KBekes

Comments

alex ua’s picture

Status: Needs review » Reviewed & tested by the community

This patched fine, and works as describes for me. I'm going to mark this as RTBC, but I'll wait for Aaron to take a look before I commit. We'll likely post a 5.x-1.1 version this week as well, so I want to make sure this makes it in before that commit.

alex ua’s picture

Status: Reviewed & tested by the community » Needs work

Ekes- I just tried to apply this onto the latest dev version of e-mail and it rejected hunk 3. Could you try re-rolling it against the latest dev? Thanks!

alex ua’s picture

Status: Needs work » Fixed

Never Mind! I figured it out- the only hunk that actually failed was related to google regex that was already added in another patch.

Committed! Thanks Ekes!

Anonymous’s picture

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for two weeks with no activity.