Can I create another sort option: "By IMDB score"?
I would like to have all movies listed by their IMDB score in decremental order. Is that something I can configure myself? In an extension it would also be cool to sort them according to IMDB's top-250 list. But I bet that figure isn't covered by the scrapers today.
I’m not really sure - if it’s not an option in Plex already, it probably isn’t supported in the code. As we’ve said before, we realise the library is inadequate in many ways, and want to implement a better solution in future releases. Because this will involve replacing the current library system, we don’t see any point in spending development time adding any new features to it.
I don’t see anything in the DB or the scraper docs to suggest we scrape this. Even if we did there’s no sort option for this.
Not sure how you would handle movies that aren’t in the top 250.
Sort them alphabetically and have the top 250 float to the top of the list?
Have a playlist with only ranked movies in it?
Grab rankings from amazon or rotten tomatoes and use those?
I should have a look at the sql docs to see just how far we could extend the library system.
Jam,
Am I right in thinking the new library system will be built in SQL?
Is there another DB system that we get free with OS X that’s worth looking into?
I guess this thread should be moved to feature requests.
Either the value is left out, or set to -1 or anything.
I imagine having it as a genre or similar.
For my personal use I would prefer the IMDB-top 250 score. I'm trying to have all movies that reaches the first 50 positions on that list, and these films are really best of bread so to say. :-)
The tricky thing with this list is that it's changing and films are actually dropping of the list. So It's not just a matter of looking up existing films in the library without a top-250 notation, but also take care of films that HAS a top-250 mark but thats not in the top250 list anymore.
Definitely something we're not doing when scraping. This is turning out to be multiple requests in one.
Scrapers are something the Plex team hasn't tackled yet. Depending on where we go with the new library system it may become necessary.
You should add these to the tracker. I don't know how soon the devs will get to them but we don't want to lose track of them.
I assume we'll be using SQL databases for parts of the system. The plans are still in the early stages of development, so I can't really give more specific answers yet. The only reason we've mentioned that a new library is in the works is so people understand why we don't have any interest in extending the current system (given that it's one of the main things causing issues & misunderstandings with new users).
I'm not sure what you mean about using another DB system. If you're referring to OS X's Core Data framework, that simply maps on to either binary, XML or SQLite files, so wouldn't really give any advantage over using the standard SQLite packages. We have other reasons for wanting to stay away from Core Data for this one too. Using SQL was never the problem with the current library - it's the way it was designed & implemented.
Another example of the library's weak points :) once the initial scan has been performed, it's unaware of any updates to the online data sources. The library was never designed to deal with things like that.
Uh-oh, far wrong.
The advantage's tremendous: rapid development, robustness of the code, easiness of maintenance and extensibility. More or less the same reasons why you (supposedly) use C++ instead of writing directly in machine code apply here (hi-level language = CoreData, machine code = SQL).
You can write the same functionality in CD in about 10-30 per cent of the time you need with low-level approach like C++ and SQL. Moreover, when you need to maintain and/or extend the code, the difference comes even more considerable.
On the other hand...
... I haven't played with CD in Leopard much, but in Tiger it was, triple alas, buggy as hell (to the point that you could save data through a CD stack, then read them back and get something pretty much different! Cost me months and months :( ).
Unless Apple has this licked meantime, I would indeed recommend to keep away... although the API is great and indeed *could* bring *tremendous* advantage (like, say, Objective C over C++ does), alas, the bugs render the CoreData (at least Tiger level) pretty much unusable :(
I have written it somewhere already... I wonder whether using SQL might be an overkill here? I don't really know, but my estimation is that most people would have hundreds, some thousands of movies; hardly anyone would have tens of thousands. For such small data I would keep off SQL: plain properly list structure based on NSDictionaries would *very probably* give considerably better results for much less implementation effort.
Am not sure though -- I haven't really analyzed the stuff, it's indeed just a quick estimate!
I wasn't really talking about from the developer's standpoint, more about how it'd perform for the end user. Since Core Data runs on top of SQLite, the performance would be pretty much the same. It's touching that you want to reduce our workload though ;)
For simple tree browsing, yes, but for rich access to a large amount of metadata & a flexible querying system, I (and hopefully the other devs) feel that SQL would be a better choice. Besides, who's to say we don't plan on being able to handle tens of thousands of of items :) PMS is currently using SQLite databases and seems to be running fairly well.
Also, we need to stay away from OS X specific frameworks for anything library-related as much as possible, so using Obj-C isn't an option.
Why, on earth?!? Seems to me very strange to throw away the one most important advantage of Mac OS X...
Myself, I would stick with the best* API (which is unquestionably Cocoa) even for the Media Server -- using things like Cygnus/GNUStep for the needed portability there.
* measured as the result quality / developer effort ratio. Note also that my concern for your workload is utterly selfish ;) -- thing is, the better (in this sense) toolchain you use, the more features and more stability we, Plex users, get ;)
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.
