Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[msbob]

Didn't you mention that all your content is dvr-ms?

Anyway feel free to take a stab at a patch if you are so inclined.

[mikem2te]

Hmm... extender issues?

With 0.3b on my Vista PC I use an XBox 360 on one TV, and and my other TV is HP MediaSmart TV with the extender built in.  Both work great and I can watch a movie on one, while my daughter accesses it and watches a different movie on the other.

Don't get me wrong, I have an Xbox 360 and it is awesome as an extender when watching/recording TV. But I keep on coming across codec issues, sometimes no sound, sometimes no picture. I know I can recode movies or use the OML transcoding feature but that only works with SD material.

My Blurays and HDDVD (Yes, I bought in to the loosing format) - not a chance. The OML transcoder does not work quick enough with 1080p unless you have 16 5GHz cores, and converting them to MPEG/MKV just takes up too much disk space.

So for an easier life I decided on the standalone Media Center approach and pre ordered 3 copies of Windows 7 when they were selling it on offer. Now each Media Center can play any format I throw at it without worrying about transcoding etc. Only problem is I had to buy more TV tuners.

Now if Microsoft could only sort out Blurays then I would go back to extenders like a shot.

[BermudaLamb]

I here you... but none of this has anything to do with how the data is stored.

[mikem2te]

I here you... but none of this has anything to do with how the data is stored.

I think it has everything to do with how the data is stored. Being able to access the data on more than one PC is a big feature we need to support, the datastorage method has to be able to support multi user, oml.dat does not cut it.

[BermudaLamb]

Why?  Just because?  Like I said earlier, I'm the only in my household that manages the movie information, does the ripping and encoding.  I do it all from one PC.  I can't imagine that the "typical" user is going to be any different.  Yeah, it may be a cool feature to have.  But why bother. 

The development cycles should be spent improving the overall user experience through the media center and expanding the import and metadata capabilities.  They should not be spent adding an additional layer of complexity that really doesn't give the everyday user any real benefit.

[msbob]

Why?  Just because?

Actually the "because" for me is that I require it. I happen to have multiple MC machines.

At this point I'm really beginning to question the point of this thread. I originally thought it was because you wanted to take a stab at abstracting the storage layer so you can run OML without SQL. Mike and I listed our concerns as well as where it would fall as a priority. I then expected you to begin working on a patch to illustrate such. Am I missing something or is there some key information you require?

[mikem2te]

Why?  Just because?  Like I said earlier, I'm the only in my household that manages the movie information, does the ripping and encoding.  I do it all from one PC.  I can't imagine that the "typical" user is going to be any different.  Yeah, it may be a cool feature to have.  But why bother. 

The development cycles should be spent improving the overall user experience through the media center and expanding the import and metadata capabilities.  They should not be spent adding an additional layer of complexity that really doesn't give the everyday user any real benefit.

If you were to read the forums, the ability to run OML across a network has been discussed many many times. It is not as you seem to think only myself and MSBob want or use. It is far from being 'Just because', it is a killer feature and as far as I can tell has been on the unofficial OML roadmap since the start, it certainly has been a goal since I started working on OML about a year ago.

And let's not think it was done to be 'cool'. The serialization method using OML.DAT was a pain in the ass. For all the talk that has been put into SQL, there as been just as much talk saying people have lost thier data, either from OML.DAT corruption or incompatability when changes were made to the data schema.
 
So replacing OML.DAT as a data store was not only for 'coolness' or just for the sake of using SQL, OML.DAT is simply not up to the task, not for a robust product like we aim to acheive.

EDIT : Remembering back a good few months there were loads of talk on these forums about the ATOM / ION platform for use as second / third media center machines. I few guys bought them and were impressed. Multiple media center installations are not a niche requirement.

[BermudaLamb]

I guess you've hit the nail on the head with your last comment.  I've tried to go back through the source and get a version of the code that recreates the 0.3b release and things are missing.  The checked in code up to that release doesn't work with the OML.DAT file that the release uses.

The need to go to SQL Server seems tirvial, while the work to support it seems exorbitant.  Having multiple MC Machines doesn't mean that you can't still have a central repository of movies.  I have three MC machines in my house, but the movie repository is still central with nearly 800 movies in it.

My original understanding when I started looking at this project was that it would be a movie repository for the masses that was open source and provided flexibility and better opportunites for growth than the commercially available products out there.  It should be simple to use, and keep in mind that goal is to display the Movie Media Library in a manner that makes watching movies easy enough for my spouse and children to use.

Basically, what is needed at this point to get this venture off the ground is the code that created the 0.3b release.  Then working from there to redefine the data access layer (DAL) in such a manner that the back end storage is not inegrally tied to one particular source.  I would be happy to work on this if I could somehow reconstruct the code base for the 0.3b release.

If nothing else is done, can we at least split the 0.3b source code release off, and get it updated with some of the non data storage issues and features that have been requested.  While the serialization of the OML.DAT may have been a pain, it could be that an alternative data store may be XML.  At least it is a little more forgiving from a growth perspective.

Finally, how about embracing the KISS methodology here?

[mikem2te]

Basically, what is needed at this point to get this venture off the ground is the code that created the 0.3b release.  Then working from there to redefine the data access layer (DAL) in such a manner that the back end storage is not inegrally tied to one particular source.  I would be happy to work on this if I could somehow reconstruct the code base for the 0.3b release.

Firstly if that is what you want to do the 0.3b code set is tagged in the svn. Additionally I believe it was revision 1300.

Secondly I completely disagree. Are you suggesting we should throw all the work done since release 0.3b? Are you actually aware of what development has occured between release 1300 and 1933. I can assure you a small proportion of that is incorporating SQL. You are forgetting all the other things that have gone on such as-


Library UI more consistant with Windnows Media Center.

Heirarchical movie / folder structure.

TV show / episode support.

TVDB Plugins.

Improved plugin infrastructure to stop pluging referencingn OMLEngine code.

Drag and drop support for importing movies into the editor.

Fixed up file watcher which can lookup meta data automatically.

Use of multi threading to improve responsivness of meta data lookup and retreival of box art.



If you were to actaully look at the code IMHO the functions for access the data are more tightly definend than 0.3b so if the DAL were to be redefined it would be better to work from the current revision.


I am more than willing to consider an alternative data store (XML files) if we have resource to do this, problem being  at the moment there are only two semi active devs working on this. At this stage there other things to consider.

[msbob]

Basically, what is needed at this point to get this venture off the ground is the code that created the 0.3b release.  Then working from there to redefine the data access layer (DAL) in such a manner that the back end storage is not inegrally tied to one particular source.  I would be happy to work on this if I could somehow reconstruct the code base for the 0.3b release.

The below tag should get you started. Let us know once you are at the point where you can provide a patch for the team to take a look at.

http://code.google.com/p/open-media-library/source/detail?r=1320

Log message
Official beta 0.3 of OML
Affected files    expand all   collapse all
 Add /tags/open-media-library-0.3b diff
 
 
 
Comment by DJShultz, Mar 16, 2009
This is a copy of revision 1300 (the official revision number) tagged as 0.3b in case we need to make any specific bug fixes to that release (for like 0.31 or whatever) while we work on the the roadmap for 0.4b
 

[innie808]

After reading this thread i need reassurance that OML will continue to support extenders? You'd be crazy to stop extender streaming due to the number of XBOX360 owners out there.

[mikem2te]

No need to worry, extender support is not going away.

[innie808]

Great, thanks for that mike. Looking forward to some SQL simplicity and stability in future versions.