Re: [Rhythmbox-devel] [PATCH] Podcast support


Hi, I wish I had known before last week that you were working on this as
well.  It looks like you've made great progress, I just have a few
thoughts that I wanted to throw out there.  

As Colin pointed out, there some memory issues associated with adding
information, let alone non-universal information, to the 'RhythmDBEntry'
proper.  It also raises some interesting questions:  

1.  Does the library source care that a media file came into the
database as a podcast?
2.  What services should a podcast source provide?
3.  How should the podcast source provide its services?

So to skip around a bit, I believe that a podcast source should provide
three services.  

It should be able to:

A.  Download supported media files syndicated through RSS / any
reasonable alternative means of syndication.  This includes a mechanism
for subscribing to feeds, updating feeds, monitoring download activity,
and defining download frequency.

B.  Add downloaded media files to the database as entries of type

C.  Allow for the filtering and display of podcast specific information
(summary, description, homepage url, etc.) from within the podcast
source browser itself. Simply referencing the file located in the
database when requesting file information, providing a playlist of

In many ways, I think podcasting does not even belong in a media player
(ohhhh, but it fits so snugly).  So I believe that all of this should be
done without the need to force podcast specific information on any other
source, or database.

I subscribe to a lot of podcasts, so by the end of the week I can have
100s-1,000s of individual podcast entries. By including podcast show and
header information in rhythmdb, I feel that it will make the database
unnecessarily large and cluttered.  

With the current model, all individual podcasts and their associated
header are entered into 'rhythmdb.xml' as type 'podcast' and
'podcast-head' respectively.  For these to be included in the library
source view, the library must also query for podcasts (many of which, if
not yet downloaded, would have non-local locations), or an additional
entry of type 'song' must be entered into the database for each
successfully downloaded podcast.  

For each downloaded podcast there would then be 2n database entries and
then one additional entry for the feed header.  Or, podcasts would not
be available to the library / iPod / any sources without modification of
the sources themselves.  

I just don't think of podcasts as being different enough from other
media referenced in the library that these changes would become

After thinking about this way too much a few weeks ago, I had an idea.  

Have you considered implementing a separate podcast specific database
containing feed and individual podcasts, while referencing library
entries.  By doing this, I was able to get the functionality I needed
while introducing no additional query types or any podcast specific
information introduced into the 'RhythmDBEntry'.  I found treating
podcasts or, specifically podcast feeds , more like playlists, than
internet radio stations quickly solved my, mostly mental, issues.

This is what I've been playing around with as a database for my

<?xml version="1.0"?>
  <feed         name=The Dawn and Drew Show" 
   last_updated="Mon, 29 Aug 2005 14:19:56 +0000">
    <podcast title="DNDS-132"> 
      <pubdate>Mon, 29 Aug 2005 13:13:56 +0000</pubdate>


      <description>I am not very descriptive</description>
    <podcast title="DNDS-131"> 
      <pubdate>Sat, 27 Aug 2005 08:14:47 +0000</pubdate>


      <description>I am not very descriptive</description>

Screenshots here:
and here:

I've been thinking about this for too long and I'd like to get the ideas
out there and see if any of them are worthwhile.  I've only been playing
with the Rhythmbox code off and on for about a month and a half, so
please forgive me if I've made any glaring errors and am making an ass
of myself.  I'll even be the first to flame me if I am.

Ahem.  "Michael Urbanski is a charlatan."

Anyway, good work so far and thanks for your ear,

Mike Urbanski

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]