Google Summer Code

[Martin Aumueller]

In my opinion, Amarok's podcast support should be reworked a bit. Except for 
more reliability, which includes most of the stuff you are mentioning below, 
I consider it essential that podcast episodes can be handled with smart 
playlists, just like every other track. To get this working more smoothly, it 
might be easiest to add them to the tags table and have a flag in there that 
this is actually a podcast episode. But the new Meta framework might make 
this unnecessary.

Then, your issue with podcast synchronization could be solved by implementing 
proper sync of smart playlists to media devices. And this is feature which is 
also requested by quite a few people.

In the light of this, I could think of a summer of code project which improves 
Amarok's smart playlist handling. In addition to the two small things 
mentioned above you could think of
- displaying the contents of some smart playlists in the music part of the 
context tab when nothing is playing (instead of your newest & favourite 
albums), enable some kind of expansion by album or track, and create some 
default setting which resembles the current 1.4 state
- perhaps base the statistics view on smart playlists, too
- provide a way of specifying when the contents of a smart playlist should be 
generated - e.g. at creation time, at load time, always kept up to 
date, ... - this would probably be especially helpful for "newest something" 
kind of playlists

Perhaps you can come up with a SoC proposal based on my thoughts.

On Sunday 18 March 2007, John Chilton wrote:
> Hello,
>
>     I was hoping to submit an application for Google's summer of code
> and I wanted to run my ideas by the list. My ideas are related to
> podcasting with Amarok, I talked to eenam on the IRC channel and it
> sounds like it sounds like all of the 1.4.5 features compile on 2.0
> but no one is in charge of getting them working and testing them.  So
> the first part of the project would probably be just be to throughly
> test and debug all of the existing features on Amarok 2.0, unless that
> gets done in April. I would also like to implement the following
> features:
>
> -----------------------
> - Ability to cap the number of simultaneous downloads. They all just
> crawl when downloading 10+ podcasts. Also it would be nice if the
> downloads could be paused, all of them simultaneously and each
> individually
>
> - Ability to hide individual podcasts in a feed. Its nice to be able
> to cap the number of podcasts shown and to hide feeds into folders,
> but it would be a lot easier to manage large collections and more
> aesthetically pleasing if you could just hide individual podcasts in a
> feed also.
>
> - The biggest time saver would be the ability to synchronize a podcast
> collection with a media device. I spend probably an hour every week
> deleting podcasts and marking them as listened to, etc. and I have to
> do it twice, once for the local collection and once for my Ipod. It
> seems that the Ipods handle podcasts differently then normal
> playlists.
>
> - I think with ITunes most people find new podcasts though the ITunes
> interface. Implementing something like this for Amarok builtin browser
> would really help novice users, we can pull data from podcast alley,
> digg's new podcasting section, NPR, or whatever.
>
> - Once every few weeks I actually have to go into the directory the
> podcasts are stored in and delete orphaned files that Amarok doesn't
> have a in its database, but that didn't get deleted. I am not sure how
> this happens, but my guess is that this is what happens when Amarok
> crashes while downloading podcasts. The easy fix might be to have
> Amarok sync its podcasts with its directory structure once a week,
> another more robust fix might be to keep a log of files Amarok is
> downloading with atomic additions and removals, and then delete any
> file left on this list when Amarok starts up.
>
> - A lot of times I will have dozens of podcasts in the queue to
> transfer to my media device and Amarok will crash and so I loose those
> changes. It seems like this queue is only saved when Amarok closes,
> but I think it be saved more frequently than that. Another thing,
> -------------------------
>
>
> Amarok is obviously a better music player than ITunes, I think if
> these changes were made to Amarok it would be unarguably a better
> podcasting client than ITunes also. What do people think, is this
> worthy of a Google summer of code project, does it have a chance, what
> other ideas do people have, what ideas from the above list are
> unimportant or already implemented?
>
> Thanks for your time all.
>
> John Chilton - chilton at cs.umn.edu
> www.jmchilton.net/
> _______________________________________________
> Amarok mailing list
> Amarok at kde.org
> https://mail.kde.org/mailman/listinfo/amarok

r