[__JH]

Hello,

I’m a 3rd year computer science student and I’ve been a user of XBMC for several years. I find that whilst XBMC is a very flexible application, it fails to provide a good experience for an increasingly common use case, one shared media library between many XBMC instances.

I’ve introduced a lot of friends to XBMC and one of the things that they love the most is the library feature, the way all of your media is presented is amazing – all the artwork, episode synopsises, actor information and even trailers really comes together to create that awesome home theatre experience that we have all come to love from XBMC. The major problem is all the maintenance involved in keeping all of your media perfectly organised in the library. The problem is preparing the files so they can accurately parsed by the media scanners - renaming all the files, moving them in the correct directories, changing incorrect data, creating thumbnails and other artwork. I want to improve the media library experience by reducing the steps involved in crafting a perfect library. Although there are quite a few supplemental tools that can handle these tasks, the best ones are either a closed source (therenamer) or only available for one platform (Ember Media Manager).

The best overall solution I’ve seen is Plex, they have a media server that provides centralised library management plus a native and web based media manager for customising your library. Whilst it is good, I believe we can build a better solution to work with XBMC.

I want to start a project that can focus the community effort on to an open-source application that everyone can enjoy, whether or not they are using XBMC.


Proposal

I would like to start work on a Server for XBMC, similar to the project proposed in the wiki. It’s unrealistic to build a complete Media Server in only a few months, so I’d like to focus on a few core features mainly involving media management. I propose to build a media management framework that can be scaffolding for a fully blown XBMC Server. I intend to build the server using Python and a Web interface to interact with the server, access the media library etc

The project will consist of three parts:

Backend server written in Python, with MVC Architecture

• CherryPy for the HTTP server and to create a REST service.
  
• Jinja2 for templates
  
• The library data shared using JSON
  
• Store Library information in an SQLite Database, use SQLalchemy as an interface.
  

Libraries for File operations, Media Scanning, Scraping

• There are a lot of good libraries available, so this would mainly be improving and integrating what is already available for the most common tasks and then writing clean reusable libraries for other functions.
  

Front-End Web Interface

• Responsive design suitable for mobiles, tablets and 10ft interface for TV’s etc.
  

For this project I’d first like to focus on making the library information available to XBMC by using NFO files, but with the view to creating a solution for keeping multiple XBMC instances in sync (uPnP maybe).

Benefits

Short-Term Benefits

• Reduce the friction and steps needed to maintain the media library.
  
• Make it easier to keep your media library in sync across multiple XBMC instances.
  
• Web-based interface means the library can be managed from any web browser, but the RESTful API means native applications can be written to interact with the server.
  

Long-Term Benefits

I want to build something I can continue to hack on long after GSoC is finished; this project is to lay the groundwork for bigger and better projects. I imagine a day when applications like CouchPotato and Sickbeard can be one click installs in a XBMC backend, tightly integrated with the rest of your media library.

Making XBMC an attractive project for developers and designers to contribute to. By creating a simple framework that’s easy to use and provides good abstractions for common tasks, we can decrease the development time for apps that work with the backend and decrease the amount of fragmentation that’s currently within supplementary tool community. As someone who uses a fair amount of open source software, I wish there were more designers contributing to open source. The MVC architecture on the backend will make it easy for designers to contribute design elements and themes that can be used by other developers without having any knowledge of the underlying system. A project where designers and developers can play with the latest HTML5 features without worrying about older browsers sounds very attractive to me as I’m sure it will to others, I hope to bring in lots of talent from around the web.

Having a backend will reduce the feature creep in XBMC. By moving some of the functionality in to a separate application the amount of code in XBMC can be reduced, less complexity and bloat.

Smaller applications that focus on solving a few key problems always end up providing a better user experience in my opinion. The needs of XBMC users are vast and ever changing, a suite of extensible programs that focus on solving specific problems is what XBMC needs to continue to be essential HTPC software.


What does it touch in XBMC?

This will not touch any of the XBMC code, initially it just create NFO files to scanned by XBMC, but it will eventually be extended to allow library data to be kept in sync across many XBMC instances.

Goals

In short, the goal of this project is to centralise the media library management functionality of XBMC and to provide a framework for building a XBMC server.

[jmarshall]

Thanks for your proposal.- we're getting a whole bunch of great ones coming in!

One thing to think about is how XBMC will interact with this beyond nfo files in the future - not necessarily part of the GSoC project.

One thing we'd want, for example, is a seamless experience between XBMC as single client and XBMC with multiple clients (and potentially multiple servers), and ideally also access for other clients (UPnP for example).

The web facilities, for example, should be consistent across these models - you may wish to consider using the JSON API that XBMC provides for example as a basis for your web API.

Remember to slot in some decent info about your programming experience as well as info that might be relevant such as proposed database schema's, API info etc. What you have above is great, it'd be useful to have a few more details that would show that you have good ideas as to exactly how you plan to implement things in 3 months - the design stuff is what we're interested in, as the actual coding is usually the easy bit.

Cheers,
Jonathan

[Montellese]

Sounds very interesting and you seem to have a decent idea on how you want to design/build the whole thing.

There are two things that I'd like to mention:
1. What do you need a REST service/API for when you plan to implement a JSON-RPC API (which is what XBMC already uses)? IMO maintaining two API's (unless they are meant for completely different purposes) will be a real PITA.
2. You should consider also supporting MySQL because those people who would benefit from a server application the most are those people that currently store their XBMC library data in a MySQL database on a centrelized server.

[pecinko]

2. You should consider also supporting MySQL because those people who would benefit from a server application the most are those people that currently store their XBMC library data in a MySQL database on a centrelized server.

Hm... What I like in this proposal is that it brings the same benefits but without a need for MySQL.

[Montellese]

Sure but a lot of people have already made the move to MySQL. But then again, it's not a fully supported feature (which is why those mysql-related settings are still in advancedsettings.xml and not in the GUI). I'm just throwing it out there.

[__JH]

Thanks for your proposal.- we're getting a whole bunch of great ones coming in!

One thing to think about is how XBMC will interact with this beyond nfo files in the future - not necessarily part of the GSoC project.

One thing we'd want, for example, is a seamless experience between XBMC as single client and XBMC with multiple clients (and potentially multiple servers), and ideally also access for other clients (UPnP for example).

The web facilities, for example, should be consistent across these models - you may wish to consider using the JSON API that XBMC provides for example as a basis for your web API.

Remember to slot in some decent info about your programming experience as well as info that might be relevant such as proposed database schema's, API info etc. What you have above is great, it'd be useful to have a few more details that would show that you have good ideas as to exactly how you plan to implement things in 3 months - the design stuff is what we're interested in, as the actual coding is usually the easy bit.

Cheers,
Jonathan

Sure I'll add some more information when I get a chance.

Sounds very interesting and you seem to have a decent idea on how you want to design/build the whole thing.

There are two things that I'd like to mention:
1. What do you need a REST service/API for when you plan to implement a JSON-RPC API (which is what XBMC already uses)? IMO maintaining two API's (unless they are meant for completely different purposes) will be a real PITA.
2. You should consider also supporting MySQL because those people who would benefit from a server application the most are those people that currently store their XBMC library data in a MySQL database on a centrelized server.

1. The REST service would be used for the Web Client, I was thinking to use backbone.js to help me structure the frontend code.

2. I chose SQLite over MySQL because it's lightweight and easy to set up, but I'm planning to use SQLAlchemy so it won't be tied too closely with any particular Database.