Print

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

[MrHaugen]

I'll have to ask this again. There have been many months since I last brought up the subject.

Are there any plans of improving the experience for browsing and looking at metadata for series and movies? MC is in my opinion quite a bit behind the competing solutions here. I've made posts upon posts with possible suggestions of how it can be done. It will take a while till I'll waste hours on detailed suggestions, screenshots etc, but I'll mention briefly some of the things I think is necessary in a modern theater view.


- Metadata and Covers for Series level. Watch metadata and art for the whole show.
- Metadata and Covers for Season level. Watch metadata and art for the whole shows Season.
You'll probably need sort of database for relations between items. Could not the Notes function be used for this? Or you could have extra Library fields, and only show the first files info. This could very well be great for Music as well. For info vies on artists. Biography, Artist Art, Artist rating etc.

- Title browsing with bigger meta data and art (Left screen with art, right half with meta data, and a bottom row for visual cover art browsing)
Easy to use, and nice looking interface for browsing smaller collections of movies, series. In combination with my last suggestion, it would be effective as a nail gun.

- Improve the TV Themes to handle Movie/Series backdrops for drop dead gorgeous visualizations.
It just bows your mind the first time you see this. It impresses, and visuals do sell. Maybe Themes could look for Backdrop images in the movie/series folders?


- A switch for replacing the Metadata window with a Option/sort/filter window for easy access to important Theater View tools.
Example: Filter large collection based on ratings, watched/not watched etc etc. This could work with music images and other things as well. Just shrink the columns, or squeeze the lists to the left to make space. It would just let you do much more from theater view, without having to go out in standard view to make all sorts of changes. You could do without the 100 normal views. You could pick things on the fly. You could use this for the initial setup of MC! Without the user ever having to go out in normal mode. Think of your HTPC's, and other vendors possibilities.

- Movies and Series Metadata Scraping
It takes a long time to tag your media. A way of retrieving this automatically would be great. Here's some alternatives.

TheTVdb.com
This looks like a complete database with good info and art. I do not think it will be a problem for J River to use the database. Lot's of other big Media Center apps use this database, even though most of them are free products. This is taken from their API-Dev faq:

"If you will be using the API information in a commercial product or website, you must email scott@thetvdb.com and wait for authorization before using the API. However, you MAY use the API for development and testing before a public release."

TheMovieDB.org
This open DB have a similar policy to TheTVdb. Here is how they describe their API key usage:

Our policy for issuing API keys is simple. If you're developing a free, open source or personal (non profit) application we'll dish out a key with absolutely no problems. However, if you are a commercial entity looking at using our data please contact me personally to talk further. Obviously part of our job is to make sure we stick around right?



Sorry for being so persistent, but this is a way to important field for me to ever give up

[BryanC]

I agree wholeheartedly. Media scraping is too great of a feature to leave out of MC15.

What I envision is a 3D view of TV shows with subcategories for seasons and user-defined metadata.

Movies also need more subcategories below the current "Name," "Year," or "Recent."

[fitbrit]

I agree wholeheartedly. Media scraping is too great of a feature to leave out of MC15.

What I envision is a 3D view of TV shows with subcategories for seasons and user-defined metadata.

Movies also need more subcategories below the current "Name," "Year," or "Recent."

It takes forever to manually tag movie and TV data. Scraping would be wonderful.

[MrHaugen]

Totally agree. Automatic Scraping would be great. I've added it to my list

I've planed on using Autotagger for this, but it is hardly fully automatic. Still need to do some manual work.

[rick.ca]

I'm no lawyer, but I have great difficulty in understanding how JRiver could take data provided by third party websites and offer it (in effect) to users of it's commercial software without being liable to that third party. It's even harder to understand when some of those third parties are in the business of licensing their data for similar purposes. There are some sources where this may not be of concern, but they don't have the consistency or coverage necessary to satisfy those of us who want good data.

On the other hand, most of the sites in question offer their data to the public for free, with the implied understanding it's for personal use only. In other words, if a third party invites me to view data on their website, they have no basis for objecting to me capturing that data and adding to my personal database. Scraping a page just means downloading it—exactly as I would if I were reading it in my browser.

So even if the result looks the same, I think all JRiver can safely do is facilitate plugins that use scraping scripts provided by users. While I don't understand what's involved, I gather from the comments of third party plugin developers there might be some room for improvement in that area.

[BryanC]

I'm no lawyer, but I have great difficulty in understanding how JRiver could take data provided by third party websites and offer it (in effect) to users of it's commercial software without being liable to that third party.

Check out the front page of http://thetvdb.com/.

[rick.ca]

I'm familiar with TheTVDb—it's one source for my series data. See their API registration terms. I'm sure they would grant JRiver registration, but it's not clear what they would ask for in return. In any case, the fact sites like this exist in no way implies sites like IMDb and AllMovie are willing to let their data be ripped-off for profit by a commercial enterprise.

[BryanC]

I'm personally satisfied with the current wikipedia tagging. They just need to be automatic, and preferably the searches would be based on filenames. For example, "(film)" wikipedia entries should automatically be chosen for the lookups.

[MrHaugen]

TheTVdb.com
This looks like a very ok database with quite a bit of good info and art. I do not think it will be a problem for J River to use the database. Lot's of other big Media Center apps use this database, even though most of them are free products. This is taken from their API-Dev faq:

"If you will be using the API information in a commercial product or website, you must email scott at thetvdb dt com and wait for authorization before using the API. However, you MAY use the API for development and testing before a public release."

TheMovieDB.org
This open DB have a similar policy to TheTVdb. Here is how they describe their API key usage:

Our policy for issuing API keys is simple. If you're developing a free, open source or personal (non profit) application we'll dish out a key with absolutely no problems. However, if you are a commercial entity looking at using our data please contact me personally to talk further. Obviously part of our job is to make sure we stick around right?


Pretty please consider this (or good alternatives) for automatic meta data and art lookup/scraping. It would help MC tremendously imo. Every week we see additions and progress regarding HD sound, DLNA and so on. It's all good, I just think that automatic series and movie lookups/scraping is something that much more users would benefit from.

[rick.ca]

TheMovieDb and TheTVDb data are already provided by the AutoMeta plugin. I suppose the same thing being provided in the program would be more seamless, but I would be concerned doing so would discourage the development of alternative meta data plugins. That makes it less likely those wanting better quality and coverage beyond mainstream North American video will ever get what they need.

JRiver's efforts would be better spent developing an easy-to-use scripting engine that would allow third parties (i.e., users with an aptitude for such things) to contribute and maintain scrapers for a variety of different sources. JRiver could obtain registrations for TheMovieDb and TheTVDb and provide scripts for those to serve as "seeds" for this new system.

This would not only provide a flexible method for scraping data from any site for any media, it would make it possible to get data for any particular media type from a combination of different sources. The program's management of such a system would include tools for specifying which scripts to run, in what order, field overwrite rules, and smartlists for defining which records should be updated and when.

This approach would relieve JRiver of the significant burden of maintaining scrapers for a variety of constantly changing sites. Look at what's happening now to established IMDb scrapers. Those need regular updates at the best of times. With the IMDb redesign  now rolling out, it appears they will need complete re-writes. A scripting system recognizes scrapers are never perfect and require regular maintenance—and offers the means for rapid updates by the user community. The approach also distances JRiver from the scrapers (and the scraping). Because the user is choosing, installing and configuring a third party script, it's clear they're exercising their right to do as they please with publicly available information—for their personal use.

[gappie]

im with rick here.
and also, i dont like anything auto, and that is the reason why i found mc in the first place. i still think the auto order thing for keywords broke more then it healed. who says alphabetic makes more sense then for instance people order on an image, or musician order on a cd. so please not more auto things on my files..

 
gab

[rick.ca]

i dont like anything auto

I understand your point, but let's be clear about the terminology and the context in which it's used. When "automatic" implies the program will decide for me how something work and what information I get, it's usually a bad thing. On the other hand, when "automatic" refers to information being updated according to my configuration choices without me having to lift a finger, it's usually a good thing.

The latter is how I envision a meta data import system working. It would require some configuration decisions be made and effort to set up, but would then be fully automatic. And one of the major advantages to such a system is it would allow combinations of scripts to be used cooperatively. With the current plugin system, different plugins run separately, and it would be difficult or impossible to configure them to work together (e.g., if data for a particular field is not available at source 1, then add the data from source 2).

[struct]

Even before they write a scripting back bone for scraping (or do more scraping themselves), I hope that they make a few improvements on how that data can be displayed.  For there are now a few ways of getting the data (pvd, yanfoe, wiki, autometa) but without a (good) way of seeing the data there is no point in having it.  The MC view schema is still audio-centric (not withstanding your great screenshot on the previous thread rick).   

There have been some great improvements in the last year, I just hope they keep coming (as I am sure there will be).

Craig

[famu97]

I agree with you on this. I've seen your similar posts to request better movie & TV DVD tagging and a better interface.  I can't understand why the Music part of MC is great and the best on the planet but the DVD/Movie/TV Series interface & playback on Theater View is so crappy.  I'd love to have the option of using MC to playback my blu-ray collection as well. I've seen their reply to why they don't support blu-ray and they said it was too expensive to join the BR group and would increase the cost of the software.  Well its easy enough to make blu-ray playback an add-on that is not included with the regular MC software.  So regular folk won't have to pay a premium for a feature they don't use. I'd gladly pay more for the blu-ray add-on/plug-in if they offered it. I'd like to not have to pay for both PowerDVD Ultra for blu-ray & DVD playback & buy upgrades & use MC for music.  I want one all encompassing media software for playback, & organization/cataloging of music & DVD's.  I think MC should buy this software company called DVDProfiler. that would fill the hole of DVD catalogging expertly.

The DVD play-back and Theater View needs major improvement.   every time I rebuild my htpc, I have to take weeks to setup my digitized DVD library on my pc within MC so that my thumbnails show up.  My DVD's are ripped bit-for-bit vob files. 

[rick.ca]

I hope that they make a few improvements on how that data can be displayed.

...the DVD/Movie/TV Series interface & playback on Theater View is so crappy.

These comments make me wonder if you're referring to the same Theatre View I use. I maintain extensive meta data for movies and series, and it's all displayed very nicely in Theatre View. Perhaps you haven't taken the time to explore things like the Info Panel configuration. I find it a brilliant combination of power, flexibility and ease-of-use. But it's for textual data. There's room for improvement for the handling of images (e.g., banners, screenshots, actor photos, etc.). But I have to wonder how many users would actually go the trouble to collect and manage the image data. There are even greater challenges there in finding sources for consistent quality and coverage.

I think MC should buy this software company called DVDProfiler. that would fill the hole of DVD catalogging expertly.

Remember many of us have no interest in shiny discs. DVDProfiler may do a reasonable job of cataloging those, but it's far from the best solution for collecting and managing information about the movies themselves.

[raldo]

The latter is how I envision a meta data import system working. It would require some configuration decisions be made and effort to set up, but would then be fully automatic.
[...]

I have authored some plugins and one of the main issues when doing this is that the plugin API is missing some major features.

I don't know if this is by design (rather than lack of time) but I suspect it it must be since the changes are so simple. I would say this severly hampers plugin development. A couple of examples:
o There is no event triggered in the API when a new file is added to the system (Auto Import)
o There is no link between the UI (views) and the plugin.

The former reduces the possibility to automate the process since there must be polling and "things are happening behind the scenes" with no intuitive user knowledge of what's going on.

The latter is obvious, I guess.

[rick.ca]

I have authored some plugins and one of the main issues when doing this is that the plugin API is missing some major features...

I'm not sure how your comment relate to mine. I'm imagining a JRiver-developed script engine completely apart from the existing plugin API. Scripts would do the scraping, and the engine would add the data to the library and take care of all the management (what records to update, when, etc.). The same engine could be used to import sidecar files of various kinds. So this thing might be configured to do something like, "Read data from sidecar file and if one doesn't exist scrape source 1 and if that doesn't include a description get one from source 2 and then if there's no cover get one from source 3." It could even make PVD obsolete.

[raldo]

I'm not sure how your comment relate to mine. I'm imagining a JRiver-developed script engine completely apart from the existing plugin API. Scripts would do the scraping, and the engine would add the data to the library and take care of all the management (what records to update, when, etc.). The same engine could be used to import sidecar files of various kinds. So this thing might be configured to do something like, "Read data from sidecar file and if one doesn't exist scrape source 1 and if that doesn't include a description get one from source 2 and then if there's no cover get one from source 3." It could even make PVD obsolete.

It relates in the sense that JRiver seems to prioritize these kinds of things down. Perhaps because it's a gray area or because they want to control how "user friendly" plugins are (so they can steer/contrrol this type of functionality). 

So, if they'd really want to facilitate these "things", improving the plugin API would be a really easy to do as, at least, a first step.

There is already a scripting engine (check out the plugin forums) which easily could have been expanded to do what you outlined. The challenge with such an engine is, of course, is that it is restricted in the same manner as I wrote above.

[rick.ca]

There is already a scripting engine (check out the plugin forums) which easily could have been expanded to do what you outlined. The challenge with such an engine is, of course, is that it is restricted in the same manner as I wrote above.

I'm not familiar with this, but if it runs like a plugin and it's purpose is to facilitate scripts that control MC, then I don't think it has much to do with what I'm suggesting. In the system I'm imagining, the only function of the script is to get the data. The main program would have full control over the management of the scripts and the processing of the data obtained by them. (The function and nature of the program, engine and scripts would be similar to the corresponding components in PVD.)

I'm not against improving the plugin API, but I don't think it has anything to do with what I'm suggesting. On the contrary, most of its value is in the common JRiver-developed interface for managing and controlling import scripts—by and from within MC. That eliminates problems with plugins not remaining compatible with the program, and certainly makes for greater reliability and performance. Scripts would simply have to comply with the engine their written for. Hopefully, that would be something non-programmers would be able to work with. Perhaps not to be able to write scripts from scratch, but certainly to modify, update and configure according to their personal needs.

I don't think something like this is likely to be implemented soon. And it would take time for a good selection of scripts to develop. So I'm all for improvements to the API—especially if that's what you need to keep PvdImport in perfect running order in the meantime.

[MrHaugen]

I do agree that a good way to "automate" the scraping in MC would discourage some to make new plugins. But why should we/you make the plugins if we have a good enough product built in? Most of this open databases is good enough for all of us. If there is certain titles that is missing, then help uploading the info your self.

The big problem of having plugins is many.
- New users have to browse the forums for pages upon pages to find what they want
- That is IF they know that there probably is a plugin for it. Most people don't know, or don't think they exists
- There is not a good centralized place for our plugins and skins. The web page we have to day is at best heavily outdated. We need a good page with user driven uploads and updates of the 3'rd party tools.
- Many people don't even bother to install plugins. Some people are lazy. Some are afraid of the extra work involved
 

So, would there be advantages of having a good scraping system built in to MC? YES. I'm 100% sure of it. Of course we need a theater view that is actually able to show this info and art. The biggest problem is the viewing of backdrops, series art, season art, artist art in a logical way, together with meta data for this things. But I believe that one thing follows the other here. Do we get either one of this things, J River and the customers will see the need for the other.

I understand your point, but let's be clear about the terminology and the context in which it's used. When "automatic" implies the program will decide for me how something work and what information I get, it's usually a bad thing. On the other hand, when "automatic" refers to information being updated according to my configuration choices without me having to lift a finger, it's usually a good thing.

Bingo. That is what I mean. You can't have something done totally automatic. You'll have to set some criteria, exceptions and boundaries for it to be effective. A default setup that works for most users would be good, but as all things MC, we need some customization options.

[gappie]

im with rick here.
and also, i dont like anything auto, and that is the reason why i found mc in the first place. i still think the auto order thing for keywords broke more then it healed. who says alphabetic makes more sense then for instance people order on an image, or musician order on a cd. so please not more auto things on my files..

i understand what you mean with automatic rick..
i would like to be a bit clearer on this one, and how mc treats this now wrongly. when you have added information via a plugin to for instance the actors.. kill bill will start its list with uma thurman. only clicking on the actors in the tag window will change this order and places uma thurman somewhere at the end making the list in the info panel much less usefull. one needs an external database to keep track of these changes to repair them. and i think im less interested in a build in scrap thing that thinks alphabetic is the only order that should be used. and this is for every list field (i still remember when it was introduced, it made a lot of people tags i had with fotos less usefull.. so something automatic that someone can not set)

 
gab

[rick.ca]

But why should we/you make the plugins if we have a good enough product built in? Most of this open databases is good enough for all of us...

Because they're not good enough for all of us. Or even many of us. And it would not be good for the reputation of MC to offer a single pair of amateur sites for user-contributed data as the sole source for video meta data. As soon as something like this were offered, a large number of thinking users are going to ask, "Where's the IMDb plugin?" or "Why are you offering these crappy sites and not ____?" If it's good enough for you, fine. But if the system I describe includes it anyway, what is your objection?

The big problem of having plugins is many...

Unlikely things you imagine do not constitute real obstacles. Users would not have to browse forums to find scripts. They would not be large in number, and a simple list of links to current versions would be easy to maintain. You're arguing that because JRiver is disorganized and users are lazy that it would be best to offer a severely limited and dumbed-down solution. I disagree. It's contrary to the very reason that most users prefer MC over lesser alternatives. It's powerful, and allows choice.

Of course we need a theater view that is actually able to show this info and art. The biggest problem is the viewing of backdrops, series art, season art, artist art in a logical way, together with meta data for this things.

Theatre View already has an excellent facility for displaying whatever textual data you may want to import. True, it's ability to display images is very limited. But you're advocating restricting imports to sources that have a very limited selection, and only a portion of that has the full range of image types you're referring to. That means anyone who has any variety in their collection is going to be unhappy with the uneven results—especially if they're attempting to use views that are dependent on these images (e.g., a view that uses a banner isn't going to look very good if there's no banner).

Of course, with some effort, users can make do by filling in holes manually and using different views for all the older, foreign, non-mainstream titles for which they'll never find suitable images. But this contradicts your assumption that users are too lazy to even seek out and install the additional scripts that might help with this task.

[rick.ca]

...one needs an external database to keep track of these changes to repair them...

This is yet another reason why I appreciate using PVD/PvdImport for video data. They respect that credits need to stay in credits order. It's kept in order when I import, and then because all my data is complete, there's never any reason to edit it. If I do accidentally edit a list field in MC, I can fix it instantly be re-importing the record.

But I agree with you completely. This is an example of MC making an unnecessary and incorrect assumption about something—that results in an annoying issue for users.

[MrHaugen]

Answering rick.ca:

After a more thorough look, I do see that there are things missing in those databases, but I think most users would do just fine with the data that's there. "All" was a poor choice of word though. I do understand there are some movie maniacs that need more meta data. All I'm saying is that if there was a decent scraping of sources like this integrated in MC, I think that the number of users scraping in MC (with or without plugins) for movies and series would increase by several hundreds, if not thousands, of percentage. Does anyone have a counter on how many times those plugins have been downloaded? If you drop updates from previous downloaders from that number I'm willing to bet that the number is not touching 3 digits.

If such functionality was built it, there is NOTHING that says that you could not use, make, and update plugins to suite the more advanced needs. I would probably do well with the most essential meta data and the different art images from those databases. If a built in solution would be so automatic that you could not use alternatives, or not turn it of, I would highly object to implementing it my self though!

The things I mention regarding plugins ARE obstacles. I've managed to get about 10-15 people to start using MC over the last years, and I think that there is only 1-2 of those that is remotely interested in touching that subject. If we want to relay on Plugins, we should have this much more out in the open. The ultimate solution would be to do something with the plugin manager it self. Of course the web page with plugins, skins and so on could be improved, but unless there are a more intuitive and less scary ways of installing and using Plugins, many users will be turned of.
Why not add categories and lists of available plugins for download? Let users see screenshots and good description of the plugins (the better plugins and the most common at least). Make the plugins auto install and provide the user easy instructions of how to use the basics of the plugin.

Do you really think that most users of MC know what plugins exist? Do you think they know where to find them? Do you think that mast MC users today use Plugins? I have a very hard time believing that. Most users are not MC nutcases like us, and does not frequent this forums every day.

As for the displaying of meta data and art in theater view, I think you got me a bit wrong. I agree that the viewing of text is excellent in most cases. You can display what EVER you want. Except for Series and Season meta data. There is just no relation DB options in MC to handle single text or graphics for multiple items like episodes or tracks with music. This goes for art as well. Series and season covers, artist art, movie box set art, banners, backdrops etc etc.
We're missing all of this informative and nice meta data and great eye candy, that I'm sure could be downloaded just as easily as other meta data with scraping. The two DB's mentioned above might not be the perfect candidates for all of this, but I'm sure it takes many users a long way of giving them a great view for their Series and Movies.

[rick.ca]

Do you really think that most users of MC know what plugins exist? Do you think they know where to find them? Do you think that mast MC users today use Plugins? I have a very hard time believing that. Most users are not MC nutcases like us, and does not frequent this forums every day.

I wish you would read what I post. As I've said several times, this system would be completely apart from, and have nothing to do with the existing plugin system. It would, from a user perspective, be part of the main program. Many of the reasons I'm suggesting that are exactly the same as those you cite. Finding, installing and configuring plugins is too complicated a solution for most users. It's limiting for advanced users as well. We have to wait for scarce user-developers to create the necessary plugins, and then hope they have the interest and resources to maintain them. This would be extremely difficult for a scraping plugin because it would have to keep up which changes on both sides—MC and the target site. I'm sure AutoMeta is viable only because it's using stable API's on the target side. Those aren't available in most cases, and the data can only be obtained by scraping.

Scripts, on the other hand, are easy to create, maintain, install and use. The system could even download them and keep them up-to-date, but I'm not recommending that. An important part of the idea is the scripts belong to the user, and it's the user who's doing the scraping. Also, many users would want the ability to modify or tweak scripts created by others to suit their own needs.

Using this system could be as simple as specifying that [Media Subtype]=[Movie] are updated with a TheMovieDb script and [Media Subtype]=[TV Show] are updated with a TheTVDb script. Set it and forget it. But it could be configured to use an alternate script for movies that don't exist at TheMovieDb. To replace inconsistent user-provided movie descriptions with professional ones from AllMovie. And assuming there will be a way to use them, to get fan art from an alternate site if TheTVDb has none. Again, all this would be fully automatic. Set it and forget it.

Except for Series and Season meta data. There is just no relation DB options in MC to handle single text or graphics for multiple items like episodes or tracks with music.

It was quite a while ago, but I believe JRiver did indicate this would be addressed. In the meantime, the simple workaround of using dummy files to represent series and seasons works well in the existing framework. Views can be configured to display series, then seasons, then episodes, with different cover art associated with each level. That, of course, takes a little effort to set up and is not as slick as "built-in" special handling might be. But it's easy enough to do to suggest a user not doing it is really not that interested.

The two DB's mentioned above might not be the perfect candidates for all of this, but I'm sure it takes many users a long way of giving them a great view for their Series and Movies.

That's the whole point. What you're suggesting would take most users about 2/3 of the way. And about half of that would be annoyingly inconsistent and—in many cases—the data is just plain crappy. The biggest issue is with the user-provided descriptions and reviews. Perhaps I'm fussy, but I really don't want to import bad grammar and idiotic opinions into my living room. More importantly, your suggestion offers no solution to this—other than the status quo of using other third party plugins. So if that's "good enough," why not just use AutoMeta?

The implications of this go way beyond getting meta data for files on your HDD. Owned media is rapidly becoming less relevant. If MC does not evolve from a "media manager" to more of an "information manager," it's going to die. I believe a robust, generalize tool for associating library records with online data (whether by importing, or simply linking) is essential if MC is going to remain relevant.

[MrHaugen]

Scripts sounds like a good solution, though I do not fully understand what it does from that brief description. I guess MC have to be prepared to launch this scripts in some way right? As a scheduled thing?

Using dummy files for Series works. But it takes a lot of time. Do you think that those that are afraid of touching a plugin would go this way? To create new dummy files for each series or season? I would say no, in most cases. Would the users take advantage of it if it was possible as a part of a default scraping method, and shown as default in a series view? Absolutely. Most of the users with movies and series would I think.

What I suggest is a several things. ONE of those things is to find an open database that have good/ok metadata and art, and implement the tools to use them so normal users can have default scraping methods in MC. The people that do not touch plugins today might very well be happy with the metadata and art they get. Things are more accessible for them, and things will look way better than the 0 info they have after the normal import. Even though it's not of perfect quality, or consistent. Those who use metadata today will probably not be satisfied. This are, in most of the cases, the neat freaks who have to have their collection perfect. This users would probably still use options like Metadata. For this group, nothing have really changed. Only thing that is different is that more people would have a decent looking and informative collection of movies and series. I would even go as far as saying that those users that try the built in scraping methods, and is not satisfied, they will search for better ways, and end up as users of plugins like metadata.

[MrHaugen]

I would love to get some sort of statement from J River. Is any of this, or similar solutions, on the long term plans?

[rick.ca]

I think they're going to implement the Metadata Import Scripting Engine at the same time as the Auto Tag on Import feature. The two will go so well together.

Imagine—just by naming a video file correctly (in the file system)—MC will automatically import, tag and download metadata. The metadata download will rarely fail because the script is able to correctly identity the record at the source using the tags.

[BryanC]

I can't wait...hopefully it comes sooner than later!