Yikes, not sure we have time to re-implement the podcast plugin.  We need to do it right, where it does stuff like remember where you were listening, that will take some work.

Let me take a stab at it, maybe the first implementation is very simple.

Thanks for thinking of me for this one.  I'm a regular podcast listner, so please keep me in the design discussions.

4 hours seems waaaaaaay short for this. I guess that 4 hours is just for refactor time.

4 hours is Matt's design estimate, actually.  Re-factoring would be MUCH longer.  Implementing something like remembering playback position is possibly a large effort.

A new podcast player app would be great.

An important requirement is to always keep podcasts away from the Squeezebox Server music library (hold them separately).  i.e. when playing files that are podcasts, don't add them to the music library (don't store scanner results in the DB) - don't want to polute music library with dodgy inconsistent metadata from podcasts.

A good start would be to get a list of podcasts/episodes in OPML format, and using an OPML browser to navigate them.  Play items from the list, and don't add them to the music library.


As an alternative idea (potentially more functional and quicker to implement), how about using iTunes integration (if the iTunes API supports it)?

User would use iTunes functionality for subscribing to playlists, download episodes, and manage them.

Squeezebox server could retrieve the list of podcasts/episodes from iTunes.  Maybe an "Import OPML" option, or "Import from iTunes".  When playback is paused/stopped in any way, SqueezeboxServer would update the playback position stored within iTunes, and set the "Not New" indicator.

Andy (and anyone else who will get work as a result of Matt's work on this) - Make a bugz item that captures the work you will need to do and is dependent on this item. That way you can enter and track your time and we can see the serial dependency of the tasks. It may be impossible to make an accurate estimate of the dependent work until the basic design is done. Start by defining the functional reqs. Each person should be able to make a stab at their work based on that.

I'm thinking we won't be able to fit this in for 7.4.  But, need to wait until the design work is done before we can estimate anything.

Matt - You are likely to be right about deferring this to a later release. Lets get the functional reqs defined (must-have and nice-to-have), and if it does not look *really* quick, push it either to a P2 for 7.4 or to a later release. At this point in a product cycle, your work on new functionality should be long done.

Please read carefully:

This feature is ONLY for the most basic set of functionality we need to deliver for 7.4.  This is NOT a full-fledged, great podcast player that everybody is going to be super-excited about.

The basic problem is that we ALREADY have (admittedly very rudimentary) podcast-playback support in 7.3.

Today, you go to SN, visit the "favorites" area, and paste the URL of a podcast's rss feed.  Then, you can play the podcast episodes in that feed.  But that's pretty much all you can do.

The problem is that we are tweaking favorites a little bit in 7.4.  As a result, podcasts won't have a home unless we do this basic app.

We can iterate this fall and release a super-kick-ass fully-fledged podcast player app, with tons of input from Caleb, etc. etc.

This is really just "saving" some existing functionality, repackaging it as an "app" in a way that we can iterate upon for 7.4.

That's why I'm only devoting 4 work hours to this design.  Ok?

:-)

Matt - Yes, do the minimum. This is not the time to add new cool functionality. That time will come, but lets get to market first.

using bug 13144 to track the final changes for app settings

*** This bug has been marked as a duplicate of bug 13144 ***