PDA

View Full Version : Podcast PlugIn {was} Totally confused about iTunes withSlimServer



fuzzyT
2005-08-03, 10:11
kdf wrote:

> Slimserver also includes a podcast browser, which you can point to your
> favourite broadcasts.

I haven't messed around with this but am a bit unclear on how this
works. Please correct what's wrong in the following:

The SS/SB Podcast Plugin:

Allows management of Favorite Podcast (RSS URL) Lists

Browses the podcast URLs and then presents the RSS/XML contained
metadata in the SB UI.

Allows selection of individual podcasts thru the SB UI.

Downloads a local copy of the RSS enclosure (audio file)

Plays this back.

Is this right?

--rt

Once selected

> ITunes podcasts are presented as a special
> playlist in slimserver, directly accessible via the web interface and
through
> 'browse music' in the player interface.

kdf
2005-08-03, 10:24
Quoting ron thigpen <ron (AT) fuzzsonic (DOT) com>:


> Downloads a local copy of the RSS enclosure (audio file)

well, not being a podcast listener, I'm not 100% certain. However, I believe
all are right except the above. The enclosures are certainly cached, but I'm
not sure what the extent of 'local copy' it creates. I haven't noticed any
specific code to store as a local copy for later, or for use as sources for
other devices.

-kdf

fuzzyT
2005-08-03, 11:57
kdf wrote:
> Quoting ron thigpen <ron (AT) fuzzsonic (DOT) com>:
>>Downloads a local copy of the RSS enclosure (audio file)
>
> well, not being a podcast listener, I'm not 100% certain. However, I believe
> all are right except the above. The enclosures are certainly cached, but I'm
> not sure what the extent of 'local copy' it creates. I haven't noticed any
> specific code to store as a local copy for later, or for use as sources for
> other devices.

Interesting. The way I see it, there are basically two modes that SS
might use in support of podcasts:

1) Interactive with Remotely Hosted Content: (Remote Hosted)

Works basically as I described. Keeps only podcast URLs, allows
browsing of content as described by RSS hosted at those URLs, works by
streaming audio data to the player either directly or through a cache on
the server.

2) Review of Locally Cached Content: (Local Copy)

Some s/w (could be SS but maybe/probably something else) provides most
of the standard podcast functionality: browsing available podcasts,
keeping lists of chosen podcasts, scheduled and interactive content
fetching, library maintenance of fetched content, etc. SS content
playback works much like it does for any other media file on the server:
scan directory/filename/tags for metadata, present browse/search UI for
SB and web, do playback.

The Remote Hosted method is good for instant gratification playback of
available content that is live at the moment. Metadata issues are
solved by just using the RSS data. No library issues. Working now. Slick.

The Local Copy method is good in that it works on a model familiar to
portable device podcast listeners: schedule content pickups and the
content, newer and older, becomes available on your device. And for
content that isn't as time sensitive (ex: jazz radio vs. today's
headlines) Local Copy gives more flexibility in when you listen. It
also makes the files available for computer and portable playback and
leverages existing content for non-iTunes users. It may also be kinder
to the hosting parties as well, as most of these are likely using simple
HTTP servers and not streaming servers.

When I first started thinking about this, I was definitely in a Local
Copy mindset. Just an artifact of understanding the plumbing in RSS,
that I'm already using standalone podcast software, and being something
of a content packrat.

Two different operating modes that offer different benefits.

I guess the questions are:

Which design do folks prefer?
How to best support each of these in backend and UI?
If both modes are supported is there a way to unify the UI?

Some users may not know or care if there is a local copy. Others will
want to avoid a scheduled download, listen to half of a program on the
SB, then copy it onto a portable to finish on the go. It would be very
cool if these various modes were supported and well integrated.

For instance, how cool would it be if the Podcast PlugIn cached a copy
of the content and added it to the library, then exposed it in the UI
organized under Podcasts --> StreamName --> ProgramTitle/Date.

And if SS was picking up other Local Copy podcast media and
differentiating them on scan, then a unified display suddenly becomes
very possible.

I'm thinking I'll play with the Podcast PlugIn for a bit and share my
reactions with all this in mind. I'll also look into how well SS is
dealing with Podcast enclosures that I've just been dumping into a
subdirectory of the SS music folder. Some have been showing up, but
I'll want to check their tagging vs. how they show up in the SS UI,
consistency of tagging between podcast providers, etc. Should be
interesting.

Maybe someone else will post more on the PlugIn and the how the iTunes
integration is working for them.

Cheers,

--rt