Renato, 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 'song'. 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 sorts. 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 necessary. 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 podcasts. snip -- <?xml version="1.0"?> <rhythmdb-podcasts> <feed name=The Dawn and Drew Show" url="http://dawnanddrew.podshow.com/wp-rss2.php"; link="http://dawnanddrew.podshow.com"; last_updated="Mon, 29 Aug 2005 14:19:56 +0000"> <podcast title="DNDS-132"> <pubdate>Mon, 29 Aug 2005 13:13:56 +0000</pubdate> <homepage_url>http://dawnanddrew.podshow.com/dnds-132</homepage_url> <enclosure_url>http://mp3.dawnanddrew.podshow.com/DNDS-132.mp3</enclosure_url> <description>I am not very descriptive</description> <summary>I.A.N.V.D</summary> <image>http://dawnanddrew.podshow.com/images/dnd_x100.jpg</image> <location>file:///home/mike/Music/Podcasts/The%20Dawn%20and%20Drew %20Show!/DNDS-132.mp3</location> <podcast/> <podcast title="DNDS-131"> <pubdate>Sat, 27 Aug 2005 08:14:47 +0000</pubdate> <homepage_url>http://dawnanddrew.podshow.com/dnds-131</homepage_url> <enclosure_url>http://mp3.dawnanddrew.podshow.com/DNDS-131.mp3</enclosure_url> <description>I am not very descriptive</description> <summary>I.A.N.V.D</summary> <page>http://dawnanddrew.podshow.com/images/dnd_x100.jpg</image> <location>file:///home/mike/Music/Podcasts/The%20Dawn%20and%20Drew %20Show!/DNDS-131.mp3</location> <podcast/> </feed> -- Screenshots here: http://people.msoe.edu/~urbanskm/img/ss1.png and here: http://people.msoe.edu/~urbanskm/img/ss2.png 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 _______________________________________________ rhythmbox-devel mailing list [email protected] http://mail.gnome.org/mailman/listinfo/rhythmbox-devel
