GoSoC 2009 UPnP Proposal -first draft

Fri Mar 6 01:00:50 UTC 2009

On 5 Mar 2009, at 21:40, Jeff Balinsky wrote:

> Hello again
>
> This is a draft of a gosoc project proposal that i am posting for  
> feedback.
>
> I have never written anything like this and was semi-unsure when I  
> was writing. So there is frequent use of subjective language that I  
> will later (hopefully) remove.
>
> It also could be more formally written.
>
> all feedback welcome.
>

Thanks for taking the time to write a longer proposal! A few comments  
follow below, and please take them as constructive criticism only....
>
> Summary
>
>
> Many modern home entertainment devices (most notably the Xbox 360  
> and PS3) have the ability to play content of of UPnP shares. In the  
> public domain there are several backends allowing a user to set up a  
> mediaserver on their linux pc (coherence, ushare) and others  
> allowing the browsing of and rendering of those shares(coherence,  
> djmount).
>
> Primarily, I will add the ability to use amarok to share music in  
> the amarok library as an UPnP share creating a UPnP MediaServer  
> DCP . A main goal while doing this will be making configuration as  
> easy as possible.
>
> Secondarily, I will add the ability to use amarok as an UPnP  
> MediaServer ControlPoint which would allow the playing of media off  
> other shares.
>
>
>

This is a pretty good intro, but i think it is a bit light on the  
amarok-specific parts. Maybe add a sentence or two, especially to the  
last point. What *exactly* would you allow amarok to do? I'm not very  
clear. Something like "Allow the user to browse a UPnP share as any  
other collection".

> Details
>
> In my experience on the user end using UPnP and linux (I have used  
> ushare to share movies to my Xbox 360) things are not seamless.  
> There is no graphical way to configure ushare just a .conf. When  
> something in the filesystem changes (say I add a movie) I must  
> manually restart the server. Wifi is also hit or miss. I will aim to  
> address all of these issues.
>
Preface: I have never used ushare nor do i even know what is it/how it  
works. That said, i'm not clear if you are mentioning ushare just to  
show how you plan on making this or that feature in amarok "better"  
than ushare, or if you mean something else. When amarok is acting as a  
UPnP server, it should not require restarting to share new music. I  
think that would be a good goal :)

> As far as amarok is concerned one of the biggest issues with sharing  
> collections will be unsupported files. If I try to share music with  
> ushare between unsupported files and weird meta tags it renders the  
> graphical browsing on my 360 useless. This can be addressed by  
> incorporating the ability to only share a subset of the amarok  
> collection via UPnP. A possible preexisting framework for this would  
> be to use a playlist for the shared media. Another possibility would  
> be to have preset filters for popular devices.
>

I guess i don't really understand what the problem is with ushare....  
Amarok with phonon can play most media formats (with the exception of  
mpc :) so i don't really see how this is a major issue for the playing  
side of things. For sharing, I guess it could make sense to limit what  
formats are shared, although i see this more as a problem with other  
clients than amarok itself.

> Djmount discovers automatically all UPnP AV Media Servers a network  
> and makes the content available in a directory tree. A backend such  
> as this could be used to allow amarok to browse and play media off  
> of other servers. Servers may be able to be browsed right under the  
> local collection in the collection browser
>

I think you need to take a harder look at Amarok 2 :) We have a  
scriptable service framework that allows developers to write new  
services (like ampache, mp3tunes, magnatune) that integrate fully with  
the collection-type treeview. This would be the logical way to  
integrate the  UPnP browser.

> Implementation?
>
> My guess is that I would implement this as two scripts. This is  
> unless this is better implemented in the main options dialog
>
Services can be written in QtScript, with full access to both the Qt  
and Amarok APIs (yay qtscript!). You could also do it in c++ if you  
wanted do, but this would be up to you really. Personally I would  
recommend c++ as this is going to be a somewhat involved project, and  
you may want tighter integration with amarok itself.

> Fuzzy Work Timeline
>
> GoSoC Has two evaluation deadlines midterm in early July and final  
> in late August thus I split this in two parts
>
>
> First Part – Make it work
>
> Functionality – get to the point where amarok can share and play UPnP
>
>
> Second Part
>
> Creme Filling – This is where things get pretty. Make it so a 4th  
> grader can configure with a easy gui. Add fun features(subsets etc,  
> automatic port forwarding if necessary). While I am in there so to  
> speak it may be easy to use the same server to add simple directory  
> based sharing of other *gasp* non audio sharing.
>
This is not really an acceptable timeline. You need to spend some time  
looking at Amarok, thinking about what parts need to be developed for  
this project to be successful, and then try to realistically estimate  
how long each part will take. Breaking the summer down into 1 or 2  
week chunks and assigning a concrete deliverable for each chunk is a  
really good start.

This will also force you to actually flesh out the project idea too,  
which is never a bad thing :) Please do check out the 2 proposals i  
linked in my last email. You will notice that a) they exhibit at least  
a cursory knowledge of Amarok internals and b) they have somewhat  
realistic timelines. (this is more applicable to casey's [first link]  
app than xevix's.... :)

> Qualifications
>
> In the fall of '09 I will be a senior CS major at Hood College (http://cs.hood.edu 
> ). I have been programming for about 5 years through high school and  
> college. I am currently using Qt and C++ and am comfortable with  
> both. The idea of using kdelibs doesn't particularly bother me. I  
> consider myself functionally knowledgeable in networking and data  
> com theory. I want to do more network type programming.
>
Cool, the east-cost-college-students faction could increase by another  
member!

leo

---
Leo Franchi				(650) 704 3680
Tufts University 2010

lfranchi at kde.org
leonardo.franchi at tufts.edu