[Gamester17]

@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

[ethan_9219]

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...

[davemf]

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.

[zag]

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.

[rernst]

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.

[Bram77]

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...

Code:

mediaName.avi
mediaName.info.xml
mediaName.fanart.1.jpg
mediaName.fanart.2.jpg
mediaName.folder.1.jpg
mediaName.folder.2.jpg
mediaName.subtitle.eng.srt
mediaName.subtitle.nl.sub
mediaName.subtitle.nl.idx
mediaName.cover.front.tbn
mediaName.cover.inlay.tbn

...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.

[zag]

info.xml would be perfect

[DuraCELL]

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.

[Tariella]

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.

[davewantsmoore]

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. :-) :-)

[Gamester17]

@davewantsmoore, you should now have access to the private forum. I can tell you that all the things you listed are already been discussed internally there, however the focus right now are rightfully on the GUI interface, the database schema, and getting the right metadata information, all on paper only in early planning stage with the whole concept and architecture being thoroughly documented before any actual coding will take place.

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.

As this "Unified Media Manager" will be a standalone application, (just like Media Info Plus, Media Companion, My Movies 2, and the other existing metadata management applications out there), the idea is for it to have its own SQL databases where it will store all metadata that it downloads or the user enters manually. The idea is also that these SQL databases can be exported to individual XML files that XBMC/MediaPortal/Meedio can then import if they like, and the media files tags will be editable from within the "Unified Media Manager" interface as an option.

So at first it will not be designed to edit XBMC/MediaPortal/Meedio databases directly, though that might come (much) later if the application becomes popular and the developers will still think that it is a good idea at that point.

[rernst]

I am not sure this is correct. All media managers can spit out XML that you can an XSLT transform to and get whatever other format you want. Something that bothers me a lot (MR) is the inability to edit all of XBMC's aspects and the necessity to have XBMC rescan nfos which is at times a pain to accomplish.

A unified media manager practically exists or the existing software tools are close. What *does not* exist is the direct interface.

I am sure we can all plug in XML export in a matter of days and that does not appear to be the point. IMHO.

Again, also let me re-emphasize, writing a cross-platform Media Manager in Windows-only platform (Mono will *not* run all your .NET code) seems ill-guided and a serious design flaw to start with.

[krhjedi]

Can I get access to the forum? I have a huge interest in metadata organization methods and the accompanying interface design.

I have XSL/XSLT knowledge, as well as ASP.net

This is the media manager I've been waiting for!

Also:

Cross-posting what I said from another thread (http://forum.xbmc.org/showpost.php?p=336549&postcount=9)

've been thinking about this for awhile, and the only thing I can compare the two pieces of software (XBMC and the proposed app) is like iTunes and Frontrow, right braxs69?

Now granted, XBMC is leaps and bounds ahead of Frontrow, but think of the two pieces of software and how the relate to each other. We'll refer to the proposed app as XBMP for now (I remember using it back in the day on the original xbox!)

XBMP = iTunes
XBMC = FrontRow

XBMC is your Media center interface (clean, nice looking, showy, graphic heavy), this is what you want to see on your tv or when your relaxing.

XBMP would be what you use when your working inside Windows (or insert OS name here), playing games, doing homework, or just surfing the web ala iTunes.

Yes, it would be a completely new application, maybe borrowing the elements of different players (mp3, video, etc) that XBMC uses.

The relationship between the two really is the metadata. Allow XBMP to edit the internal XBMC databases for the libraries OR allow it to create nfos and edit them for each media item. My one gripe with XBMC is currently that tagging things is somewhat difficult.

After tagging my 100gb plus music library in iTunes, I have to say, they've made it incredibly easy.

Is this generally how everyone feels about this new project in layman's terms?

[Gamester17]

@rernst, they have not yet decided on a programming-language, (not for the back-end core nor for the front-end GUI), as they decided to list all requirements and such, putting all concepts and theories down on paper before even starting looking at the actual coding of the app, but yes cross-platform support is one of those requirements, ...you should know this, you are one of the people who have access to the internal forum after all:
http://forum.xbmc.org/forumdisplay.php?fid=107

@krhjedi, you should also have access now ...this "Unified Media Manager" will not be a media player.

[Swifty]

Not sure if this sits here or in feature requests but the following scenario seems to go hand in hand with whats proposed with the Unified manager..

If the new Unified media manager is going to have the ability to update the XBMC library db files directly, could this also be tied into an option within XBMC to look for the library DB file at another location (ie. network share)

It would be great to have the unified media manager scraping all info, then updating the DB files at a central network location.
Then all instances of XBMC can look at the network share so that watched info, library updates etc.. are all in sync between multiple machines.