I'm wanting to know what features people are wanting from a movie archiving program, in particular the information that needs to be stored, the types of importing and exporting people do, visualisations, plugins and other matters of functionality.

Anything that you think is important from a movie player is wanted

I use Ant Movie Catalog (freeware). I haven't bothered to check out any other Movie Catalog programs, but heard good things about Extreme Movie Manager, but you'll have to buy that one (I don't use pirated software, call me crazy )

The things I'd like to have in a Movie Catalog program is

* A script to import information from IMDb and covers from Amazon
* Add specs of the rip
* Add the eMule link
* Director, writer, cast, year, country, runtime

Could probably add more, but can't think of anything now..

Well I was thinking about it and what all managers seem to miss is the ability to differenciate between movies, editions of movies, and cuts of those eidtions. So I think the logical structure would be:
Movie 1-* Edition 1-* Media

Rather than just treating the whole thing as just one thing.

Emm is very nice, but there's always room for improvement..

Sorting by every possible variable is very important to me.
In addition to what edition a film is, it would also be nice to have a field where it says what source the rip has (if it is a rip...). Dvd/vhs/ld/cam/whatever
If the cataloguer could take a few random screenshots as it scanned the film, it would be very nice!
One of the most troublesome things about EMM is that it gets kinda slow and consuming once the DB gets big... prolly because it's coded in VB?
and all the tiresome bugs which never gets fixed... bah.



A player as well, or was that a typo?



You thinking about starting coding it?

already thought of that john, by edition: theatrical, workprint, director's cut, dutch uncut, european version, etc., and under that comes what media its stored as, the media would contain the source of the rip, cut status, etc., then there's inheritance with MPEG4/DVD/etc.

The idea is that like me, you may have 3 cuts of Dawn of the Dead, and you would have one entry for the movie, 3 entries for the edition (director's, argento's, theatrical), then whatever media editions, let say 6 (1 for DVD, one for xvid under that). If you want to see what movies you've got, you can do, you can see what editions of the movies you've got, and then on top of that you can see the copies you've got.



That was my intent too, I actually requested that from EMM, but I think he's forgot about it or doesn't think its important to be honest.



lol, yes, I know what you mean, although i'm using ultra slow java (although its quick after its initially loaded, just slow the first time you use it on a new system), however there's many tricks you need to do when it comes to databases. Using m$ is the opposite to this

If you use a database package you also have the ability to have storage plugins, for example working with an existing database, SQL, flat files or xml, or whatever you see fit.

I'm working on the idea of caching too, the good thing about splitting by movie, edition then media is it doesn't perform the select statements and read in the entire database until its needed, and once its done you can store that in memory. It means your not stressing loading everything if all you want to do is write a new movie to the database.

It adds all the stuff, then it gets to the point where it needs to read in all the info, then it caches the result.

I'm just trying to get the architecture, use cases and requirements right.



lol, not a typo, a brain-o

Just working on the storage file format. Basically the way its been thrown together atm, will allow for whatever storage you want (although you need to write java plugins to interface whatever database you use), the default being xml flat files:



With the movie tags repeating for each movie. Are there any other essential fields you can think off? Baring in mind, actor, writer director are seperate links, because they linke Person with Movie. Shit like producer are omitted now because I don't really think they are overly important, and can be added in about 2 seconds flat by adding another table to the data store and another entity class.

oh and:
would be in there too after country

slowly, slowly, catchy monkey...

I was worried that the ultimate slowness of file reading and writing could have killed the project, but it can read in 2000 movies, add them to an arrayList and probably display (the above details) in about 8 seconds. Factoring in all the other objects, and creating references between them... should be pretty speedy on big archives I hope.

hehe, you know you'll gonna have to implent an importing utility too though.. =)

yeah, you notice the hhah app already has one that *still* works even though the site design for imdb has changed about 12 times?

Most of the time it doesn't even dump crap into all the fields too

Okay, think i've handled the reading in of the database. Next stop, writing to database files

Then its onto data capture, then avi file info, then internet import, then MD4/Ed2k link hashing, and then onto the fun part, features

How about having a 'collection' feature? Would VERY be nice to sort by..

For example seeing a list of all Hammer flicks, or all Serial Killer flicks....

hehe, No idea how it should be implented though, as I know I'm too lazy to manually enter it into all flicks. Don't know where it could be imported from either... Unless the app came with a set of premade collections, and would recognize titles as they were added to the program..

very nice idea, i'll have a think about implementation. I could easily have a class that sits above movie with no modification to the existing datastore layout.

God bless objects

I was thinking of making a php site to go along with it. It was more to do with cut status. So when you click import not only does it get all information, it checks to see if it can find the source of your rip and then imports whether its cut or not, along with other things. Of course that's a huge undertaking and requires management by users of the program as well (for example if they have something thats not in the database)

ooooo. niiiice!! =)

when I said Importing utility, I was actually thinking of importing the EMM db... hehe


And about the file-reading option: I suggested before on the EMM forum that it should recognize words in the filename like cut, uncut, dvd-r, dvd-rip, vhs-rip, screener, etc...

Oh yeah, and the (year) should definatly be in a sepperate field, with the option to display it after the Title.


looking foreward to try out the beta! =)

The easiest way to do this will be to use its export to text file, then load that text file into this program. That will be done for sure, since I got a massive database in emm too

Hopefully it will mean more frontpage updates here too, this is the evolution of the hhah app i made a long time ago for the frontpage.

I actually wanted to start this at xmas, but unfortunately that's when the mpaa fags caused all the hassle



Way ahead of you, another planned feature. As well as when it imports, truncating the crap from before the year afterwards.

ie.
Demon.Poo.2005.INTERNAL.DVDrip.Xvid-Jesus.avi

Truncate and strip .:
Title = Demon Poo
Search for digits:
Year = 2005
If statement and search:
Source = DVDrip
Syntax find ripper:
Ripper = Jesus

Will take a while to get it right, but all that is simple searching and pattern matching. I suggested ways of automatically dropping bits of the filename for emm too (its annoying that after you clean the filename you still have to delete the crap from the topic title... and you have to wait for the list to refresh each time you do it).



OO programming promotes reusable classes, so its always best practise to have all attributes at the atomic level (ie. single bits of information), then if you want to construct a larger display, you use a method to construct it. So if you wanted Title (year) to appear in the list, you'd have a method that adds the Title to the Year fields on the fly, and they are stored seperately.



Long way away most likely, whilst once you get to the stage where your just adding features you can release programs every other tweak, until you get all the basic bits in place, it doesn't do very much.

Anyway, I'll keep people posted if they so wish.

Still wanting ideas, although I can't garantuee that they will be implemented soon since its still very early on, and the ideas like filename truncation are a lot higher up.

Since the underlying bit went very quickly (in days, i have put in a fair number of hours), I actually started playing with a gui! Since I have handled the reading in and out of a setting file, you also get a choice of guis.






Not too shabby for an extremely early alpha

hehe

hi spud,
my 2c:
maybe some attributes of the movie should be seen as a list, e.g. "<genre>" could be "horror/sci-fi", "drama/fantasy/romance", etc.
then you could separate "objective" attributes like <title>, <year>, etc. from "subjective" ones like <rating>, <comment>. this way if two people want to share their data, they could chose to exchange only the "objective" ones and complete them with their own subjective ones.
another objective attribute i can think of is <runtime> (length of the movie), but then again it should be a list because there could be various versions (uncut, cut, even more cut).
then the "mpeg4 counterpart" of a movie could be a different object (there are more versions of one movie).


about the gui, i'd say i like the second from top. btw what do you use to develop? i recently tried http://www.eclipse.org which i found very cool. there's a plug-in too to develop GUIs.

have fun!

Currently its:



Unfortunately I have to compromise on how objects relate to make sure its stored easily, so its a lot more leaning towards a relational database model.

I think i'm getting it close to good practise, since John's suggestion is implemented with no modification to existing data structure.

A collection can contain one or more movies. A movie has one or more Editions. Editions are one of more media, which is stereotyped as DVD, MPEG4 or VCD.

Editions are Director's cut, japanese laserdisc, theatrical (standard), etc., then you have that edition on media, where the cut status is stored. You have the ability to put comments on the movie, say "this movie sucks", edition, say "The director's cut contains xyz scenes extra", and media, say "shit quality divx, highly censored"

When your talking of the datastore attributes for genre, they can be multi-valued. The alternative would be to have lots of <genre> tags, but i don't think that's a good idea. What would happen is that its got a single storage value of:
<genre>
in the movie file, so what you'd end up with for a multi genre film would be:

which the program will parse as:


you then have the option to display this information on the gui how you see fit.

getGenre(); -> predominant genre -> Horror
getSubGenres(); -> secondry genres -> Scifi, Action
getGenreDisplay(); -> "Horror, Scifi, Action"
getGenreList(); -> list of genres:


All the information is stored atomically, and constructed higher up. I can see what you mean by object and subjective... some people seriously think Alien should be ranked as scifi instead of horror.

I hadn't thought of merging and sharing at this stage, but it should be relatively straight forward, to specify the only fields they want to merge.

As for runtime, that isn't objective in the sense in which I'm working on, the theatrical version should be this length, it is uncut if it meets the length, it is cut if it does not. This does not mean it is uncensored or in the truest sense uncut, it does mean it matches that edition of the movie. If there's a longer version, you then create another edition, since its not the theatrical print, but another one. Given the structure above, runtime is stored in two places.

1. Edition, being "that this edition of the movie should be this length"
2. Media, being "this version of the movie is exactly this length"

Cut status is then checked and hinted at by the program (only hinted given the sticky nature of cuts/uncuts), "is the media shorter than it should be?", notify user of possible cut or different edition. "is this media longer than it should be?", notify user of possible different edition of the movie. "is this media the same length as the edition", suggest that this dvd/media is uncut.

So to take Dawn of the Dead, this has:

Editions:
Theatrical
Director's Cut / Canne's Edition
Argento's Cut
German Extended

All of which can have cut or uncut media. Lots of people make the mistake of saying the theatrical version is cut because it doesn't have the extra gore in of the others, however, its actually uncut, because all the cuts were not made by the censor board, but by Romero.

You can force the issue and get the program to record cut even if its not, but its made to support the idea to only to put cut if it has been censored.



You get to choose but that;s standard java.. not fond of it myself, I prefer the native system look (top).

I do use eclipse also, and would recommend it for java programming myself. I've seen the odd plugin for guis, but the one I saw I wasn't fond of.

oh and before I forget, despite the fact it says Database View on that tab, that's just a view.

That sorts the movie column, so you can do it by year, title, id, etc. and under that are sorted editions and media. There'll be another tab for location and stuff like that.

hey john, I just did a test regarding speed.

For the test I force it to do:
a) imports from emm b) writes a file in the above <movie> format c) read that <movie> file back in d) display the list of movies in the movies table, all at once at startup.



It did that in under 4 seconds.

EMM takes 49 seconds just to startup. Although its worth noting, emm spends most of its time importing the actors database.

Lets hope it can stay that fast when more parts of the database are added.

ps. it also closes down when you click the x, not display a closing dialogue that crashes