Universal Media Companion, (a unified media manager), who wants to help code this?

@emigrating, euphoric, and mediacoder, you guys should now have access to the private internal forum for this project:
http://forum.xbmc.org/forumdisplay.php?fid=107

I'd like to request access to the forum. I'm not a coder/programmer, but i have a bit of graphics experience, and i have an eye for what does/doesn't look nice.

....I also tend to have plenty of ideas, mostly unfeasible ones, however...

May I also request access? I have a Java & web development background, although these days I'm more of functional analyst type - requirements gathering, technical design etc. I'd like to help out any way I can.

We discussed this in some depth on the meedios forums and have made some of our importers compatible with the XBMC .nfo files. The only disagreement is simply the naming of the exported file.

The XML structure is great but why use the .nfo extension? This clashes with scene nfo files and makes it really confusing.

http://www.meedios.com/forum/viewtopic.php?t=4637

If this could be changed to something like .xml or more generic, then all the apps could have an easy way of importing and exporting between each other. Something that would be a first step to cross app compatibility and a unified media manager.

Gamester17 Wrote:Question: Will it be coded in .NET? Which programming language, and which .NET framework version/platform?

http://forum.xbmc.org/tags.php?tag=media+manager

Good for reference and for hunting volunteers

I write .NET as well as Java code. I don't understand why you want to go the .NET and Mono route (Mono has many incompatibilities with .NET and more with every release. Why not go the x-platform route with Java to start with (which is what I did)?

If .NET I think C# is the way to go but again, I do not understand why you would want to take on the Mono burden. With Java you are pretty much ensured compatibility.

I am tentatively interested.

zag2me Wrote:We discussed this in some depth on the meedios forums and have made some of our importers compatible with the XBMC .nfo files. The only disagreement is simply the naming of the exported file.

The XML structure is great but why use the .nfo extension? This clashes with scene nfo files and makes it really confusing.

http://www.meedios.com/forum/viewtopic.php?t=4637

If this could be changed to something like .xml or more generic, then all the apps could have an easy way of importing and exporting between each other. Something that would be a first step to cross app compatibility and a unified media manager.

This sounds realistic. There is a (small) conflict in file naming. Maybe something like...


...could be a more consistent and less conflicting method? The only issue with this would be the naming of the subtitle files. I think the default for a lot of applications is. "mediaName.eng.(srt|sub|idx)". I'm not sure what this would mean for XBMC regarding changes in the code.

info.xml would be perfect

Gamester17 Wrote:It would IMHO be great if you could use AJAX, JavaScript, and/or PHP instead of ASP.NET for the web interface, ...I didn't suggest it because I didn't think it was as flexible and easy to make/maintain as ASP.NET and still look good(?)



...if AJAX and/or PHP was used for the main interface then you would in theory even be able to run run it on XBMC's built-in WebServer, (once we replace GoAhead with AppWeb, which is planned), that way you in theory could if you wanted to run this media manager locally on your dedicated HTPC that is also running XBMC and directly manage XBMC's database via any web browser, ...hell, you could even bundle it with XBMC if the web interface was just as capable as a standalone desktop interface app.

....

Actually if you make the Media Manager XBMC compatible but still keep it as a cross platform tool you will have the option of putting it directly on your Media Center. If install and use more then one Media Center in your home you can just chose as a user to have the Media Manager running on your main Media Storage Server and have all the clients update from that central location.

In essence when you install the Media Manager on your XBMC it will install as a server and then your Media Center can just connect to Local Host when retriving data from the main metadata repository.

Wouldnt this solve both problem ?
Having a central metadata repository that is avalible both for the normal (XBMC plugin local server) and the advanced user (Central meta data repository).

Ofc there are alwayes issues, and the one i see with this is that when upgrading from Single user instance Media Manager to a Multi user instance, your might end up maintaining 2 databases.
The user that wants to go advanced might not just have the skill to export the old database and put it on his central server. The user will just install another instance of the manager leaving him/her with 2 metadata repositories.

EDIT:
Can i get access to the forum aswell. My programming skills are kinda rusty as i havent made much use of it the last couple of years but i do know C/C++, C#, Asp.NET, Jave and a little Phyton.

Is there a decision about the programming technology yet?
I'm also interested in the features you are planning (as soon as you get that far in the project), so that "us" future users can give their opinions/requests.
I hope you'll let us "outsiders" know about the progress you're making, I'm already waiting for this.

Don't get me wrong, I'm not trying to pressure anyone (not that I could anyways ), I'm just very interested in this.

Hi everyone.

While I won't have much time to get heavily involved in the coding side, I have quite a bit of experience in requirements/design and project management... and HTPCs :-)

I've just read through this whole thread, and the idea of a universal media manager is a very exciting one as it could save a lot of work in programming the scrapers, and more importantly all the work in coding the logic to decide what to do with the metadata once it's been scraped.

There is an issue that's been raised in this discussion, that I think needs important consideration... and that is:

A) How will the media-manager interface with the media... will it be editing the (XBMC) database?... will it edit tags within files?.... or will it put the info into .nfo / .xml / .whatever files?

Something to consider here is that although tags seem like the most sensible way to add metadata to media... not all (many) types support it (well).

I guess my feeling is that to begin with metadata could be stored within the XBMC database.... although the goal would be to always have this data stored within the files as tags when that became possible.


B) A lot of people will like the opportunity to run multiple frontends (XBMCs) from a single database ... and also using "profiles" the ability to grant or deny access to certain media stored within a central database.

Also, some people may like to connect an XBMC to a new database temporarily.... or to be able to use the "media manager" software to tranfer (copy/move) media from one database to another.

What this says to me, is that a core feature that should be planned for XBMC, and hence for this "media manager", is the ability for XBMC to make use of databases located on different hosts.


The mythtv style frontend/backend setup is a very powerful and useful one... and IMHO why mythtv has survived much longer than it probably should have.

I think we need to steer XBMC in this direction, as it will allow most people to continue on as normal (using a combined frontend/backend) .... but allow others with multiple frontends, servers, networks, and users, the ability to have a very powerful setup.

If this is the case, then I think it's important to have "media manager" able to work with remote databases very early on.


----


Another couple of features I would love to see, are:

1) Ability to "auto-pilot" scrape removable media, and have it appear in the XBMC database as such. Eg.

- Connect external HDD
- Auto-pilot scrape (threaded and in background)
- Start XBMC and connect to the database the media was scraped to
- See media under a menu of 'Removeable Media Device Name"


2) A "quick-check" screen for during or after auto-pilot scraping.

Once some media is automatically scraped with metadata... ask the user to review what has happened.

Include the ability to show the user titles which had the least "confidence" first.


3) Musicbrainz support.

Musicbrainz is an excellent way to tag music, and offers the ability to post data back to the system (including ratings).


4) Ratings support for music (and possibly movies)

Allow newly scraped music to be automatically rated by an online service (musicbrainz... or lastfm... or?). I have a very large music library, but unfortunately ratings on become useful when everything is rated. I would love to see tha ability to pre-rate music as it is imported... as I think rating are a lot easier to deal with when you have base to work from.

It's much easier to look at a song thats rated 3.5 / 5 and say ... "no that should be 4/5" ... rather than looking at a large group of songs rated 0/5, and trying to work out what they should be.

The only issue I see here is that ratings in ID3 tags are not standardised.



------

Sorry to go on, and on. Like Gamester17, I'm excited by a project like this. I whole-heatedly believe that a project like this could have great benefit for all media platforms, as the most difficult aspect of this type of software is getting the user interface right (as the guys who have been developing MediaCompanion and MIP, etc. can certainly testify to)... and the user interface logic (auto-pilot decisions, etc.) are the thing that will be shared by all.

It's definitely going to require some strict programming and project management to keep everything modular enough so that the user interface can develop on it's own, while other write scrapers and importers.... and others write the code to output to various formats (XBMC and other databases, tags, or files like .nfo .xml).

If Gamester17, or one of the other officionados would like to copy this post into the Unified Manager forum and give me access -> that would be welcome.

I am glad to help discuss the structure the program will take, and at a high level the approach we should take to code it. My discussion would likely stay language independant, as although I'm a software 'designer', my skills in specific languages are weak. I do think it's good to keep much of the design work language independant though... as it means more people can understand and critique the decisions.

Although if you already have enough people for grerat discussion, then that's fine too.


Thanks for reading this far. :-) :-)