Print

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

[Matt]

We've been talking with the folks at http://thetvdb.com/, and they've given us permission to use their data.

This could provide nice metadata for television shows, along with really sharp fanart that can be used for backgrounds.  For example, here's a Curb Your Enthusiasm background:
http://thetvdb.com/banners/fanart/original/76203-2.jpg

How interesting would this addition be?  Any advice if we turn down this road?

Thanks.

[fitbrit]

My advice, is please please please do this!
It would make my life so much simpler if MC could gather data from such a database.
I think there should be an interface we could use to set up some options. E.g. we can map which fields in tvdb correspond to fields in MC - I believe the PVDImport plug-in does something like this, iirc.
I hope one day we could do the same for movies and IMDB.

I am VERY excited by this development and I hope it comes to fruition!

[rpalmer68]

This would be great, I'd certainly use it.

As mentioned we'd need field mappings and I'd like the ability to be able to select all the episodes in a series and have them all tagged automatically with their overviews.

Richard

[glynor]

FYI: I'm getting a 403 permissions error on that link you posted, Matt.

I just looked briefly at some of their data.  Looks pretty good so far.  It is nice that they have multi-language entries.  I suppose many sites would, but theirs looks more "up front", at least for modern shows.  I hadn't really considered that before, but that's pretty important for MC!

For advice?  The lookup needs to be able to be much more automated than the Wikipedia movie lookup is currently.  However, you'll need to be able to deal with some special cases.  For example, for LOST Season 6, they have Episode 1 listed as two separate pieces.  I have it recorded as one solid 2 hour long show, since that's how it aired originally (same goes for the finale and many other similar episodes of other series).  The system will need to be able to handle this in some fashion.  I don't think requiring a certain naming and/or tagging convention is too much to ask the user to do though.

The other thing to consider, though, is related to the language support.  For example, for Quantum Leap the only other language available is Italian.  Doogie Howser has only English, and The Wire has only English and German.  You don't want a Russian or Afrikaans user to get no data at all for these series.  I suppose it should "prefer" their native language, but fall back to English if there is no matching data.

[fitbrit]

Good call on the double-episode thing, glynor. iTunes downloads often are at odds with the series naming conventions used by many TV sites because double episodes are counted as one, or vice versa - I forget which.
And yes, multiple selections, or entire sections of one's library should be able to do a batch retrieval of data. As for naming convention to aid import - I'm all for that if necessary. At least we have an awesome tool to make that part easy.
I think you guys will have earned my upgrade money to at least version 17 if this goes through. (But please give it to us in 16! )

[darichman]

Yes yes yes yes yes!! XBMC, Plex and some of the other popular HT interfaces make use of TheTVDb and TheMovieDb. This allows you to have a beautiful interface with very little input from development staff, as all the content submission happens elsewhere

The resource intensive part is you guys creating the interface to display the art and to store the information. As you probably know, TheTVDb uses series art (as posters, backgrounds and banners), season art, episode art (screens) and character/actor art. Information/metadata is also stored at these various levels. MC currently has no way to store this information.

Fortunately, we now have a new relational system which could make use of this, both in terms of art and in terms of making useful views for information etc.

[raldo]

A smart file parsing system for both video and series would be greatly appreciated.

Look at the way it's done in PVD, simply some regular expressions that work every time.

Someone above suggested a more automated approach. I think this is essential too, but it's a difficult challenge to get it right. Some user interaction may be needed.

If you look at the way it is (usually) done with PVD: mc imports, PvdImport queries pvd, if a file is found, import metadata. The user does the movie selection in PVD after pvd has parsed the filenames. Once metadata has changed, PvdImport retrieves the data from the PVD database.

The PVD "manual" part is quite painless because of the smart filename parsing.

You can set PVD for automatic import but chances are that the movie may be wrong.

[darichman]

Reg. expressions work well, and can be customised if you use a non-standard naming scheme.

If there is an automatic lookup (whether it uses fields or filenames) I think it's also important to be able to manually point MC to the right page if it guesses wrong, and to store this info somewhere (PVD does this very well). I have IMDb, TheTVDb, AMG, TheMovieDb links stored in fields for all of my video files, both in MC and PVD

[rick.ca]

There's no doubt such a feature would be much appreciated by many users. I think it will require a departure from the usual MC requirement that a file exist before information can be recorded in the database. Whether they record or download episodes, I'm sure many (most?) users do what I do—watch and delete. That doesn't mean we're not interested in the data on episodes already viewed or those not yet broadcast (there's usually some data a week or two in advance). Even if not of historical interest, that information provides important context (they are, after all, series).

The best approach would be to handle the data as a separate database which records all the available data for the requested series. That's how the data is provided anyway. Updates are available, but if anything other than the most recent data is required, then it's going to come most efficiently as one file for the entire series. Rather than offering the illusion of being able to pick and choose which seasons and episodes to download, it would be more straightforward to maintain the all the data for a series. Then offer tools for hiding the parts that aren't needed. For many users, that might include all seasons except the current one, but even they might appreciate being able to look back a previous seasons at any time. Some may also want to hide future episodes—so the data appears to be added when the episode is obtained.

This separate database can then be updated on a daily basis—independent of the addition of files. When files are added, the import routine will simply match them to what should be pre-existing records in the series database. Also recorded in that database would be the dates files are added, viewed and deleted—and that information would remain as an historical record after the file is deleted. The matching will require compliance with a file-naming scheme. That should be flexible enough there's a choice to use a folder structure appropriate for collecting (e.g., \Series\Season\Episode) or watching and deleting (where using one "current episodes" folder is more convenient). Simply matching based on a filename pattern of Series S00 E00 (and common variations) in all cases would do the trick.

The "double-episode thing" would only be a minor issue in this environment. Whether named with an "E01,"  "E02" or "E01-02," it would always be properly matched to one of the applicable records. From there, the user can decide how to handle the orphaned episode. I prefer to leave them in place—so it's clear it's a case of a double and not a missing episode.

And, yes, field mapping is critical. As simple as it may seem (TheTVDb fields are not very numerous) people are going to want to handle the data in different ways. By all means, provide sensible defaults—but within a completely flexible field mapping configuration.

This going to rekindle the debate over turning Theatre View into XBMC, so I'm not going to bother commenting on the "really sharp fan art" just yet.

[MrHaugen]

I LOVE this! And I've been fighting for this for quite a few years now ;-) Such a relief that you start thinking of this. Sure, we have the plugins. But there is just way to few people using this!

As Glynor sais, you need to handle some special cases, and this needs to be pretty automatic to be a winner. Most common is double first, or last episodes I think. If you have an automatic file name reader, an episode with two "e"s with two increasing numbers, it should be treated like double episodes. In addition to that, we have Special episodes, often found at the start of the season and at the end. This is often without episode numbers. So if this is found (no episode numbers), you might have to set them all as "Special" under episode.
 
I think that there can be a set of algorithms to pick up the important things like Series Name, Season and Episode. With that, you have all the info you need. Just look for the first text before the eX and sX or XXX (series/episode numbers) for Series Name, and possibly remove dots between words/names. Name, Season and episode comes mostly, and almost only in this ways. With either e for episode and s for series, and then some numbers. Or 3-4 numbers after each other indicating one or two number for season and the two last numbers for episode. That is why I think we don't actually NEED to force the users to use a certain naming rule. It can be picked up automatically 98% of the times.

After the scraping is done, we need ways to show this info properly. Today we will face the problem with info regarding series and seasons. Especially Series info/review, season info/review and images for both. We have no fields for this, and no default good way of showing it, and we have currently no images for Series and Seasons. This is what Relations field and "Artist Images" should be used for! There is just no other logical way imo! This was like made for this. Banners should be considered as an alternative thumbnail style when art is available. Series View with one column with banners on the left side, and Series info on the right side would just be amazing.

You also need to consider another quite important thing. Watched/Not watched summary. For each Series, and Seasons. This would require a sort of info pane in Theater View, when watching series views only. So we can see how many episodes that have not been watched in both the series level and season level. Also, other important info as series info/review and possibly images needs to be considered here for a full Series viewing experience like your competitors have.

ONE last thing you need to consider. Today I use my own field for sub video type. This is because the limitations of the current Media Sub Type field. In my opinion you really should look at how we can add fields here (don't necessarily need to remove defaults), so we don't need this. This system with automatic scraping needs to have a logical default setup. I agree with the others also though. That you should make it possible to map certain info from the Database, to specific fields in our the database, so we actually CAN use our own fields. As it is today, I would need this feature to set my "Video Sub Type" to the value "Series", or else I would get it in no views except previously imported.


Things like this have been echoed in lots of other threads, all with slightly different goals and outcomes. By me, and several others in Beta team, and the more open MC 16 Beta board. The common ground is that this things can be used for much more than they first was developed for, and a thing common for all of this is that they all have to be worked on some more if we want to get the top notch meta data viewing and organizing experience we dream of. It might be 3 version changes before it's all there, but I'd rather have it in version 16


*Edit*
I do not completely understand why Rick thinks it have to have a separate database for for this. I do agree however, that it could be smart to check if the users have more files for the season or series, and then map it against the TVDB. Downloading full series info files when needed. This could also provide the users with feedback (if wanted), if there is missing episodes?

[rick.ca]

I do not completely understand why Rick thinks it have to have a separate database for for this.

I wish you would be more specific, but maybe you're just trying to say my proposal lacks merit because you don't understand it. In any case, I'll attempt to clarify...

My reference to a "separate database" was not intended to be in a technical sense that would imply the data would be separate from the "library." It was in the notional sense that episode records would have to exist in the absence of media files. My concern is, most of us are so used to MC being a database restricted to physical media files, this feature would be seen only as a way to get meta data for existing files. For the reasons I outlined, that would make the thing next to useless for many of us.

I doubt the episode records would, in fact, be saved in a "separate database." But I'm also deliberately not attempting to describe how this should be done within a proprietary structure I know nothing about. I'm certainly not going to make the mistake of saying something like, "If it were a relational database, the episode data would be saved in a separate table and..." I'm sure Matt understands exactly what I mean, and is quite capable of determining how to best implement the idea in the MC database.

As Glynor sais, you need to handle some special cases, and this needs to be pretty automatic to be a winner.

By letting go of the notion the system must be rigid, closed and fully-automatic 100% of the time, all these sorts of issues go away. While it doesn't always apply, the S00 E00 organization works fine 95% of the time. If we have the ability to add episode records, then we can easily accommodate specials or anything anything we might want to add that does not exist in the TVDb. A pre-season special that doesn't exist (they often do), can be handled by simply adding an "E00" record to the season, and naming the file accordingly. Anything could be added to "S00" or "S99" without concern about conflicts with normal episodes.

That is why I think we don't actually NEED to force the users to use a certain naming rule. It can be picked up automatically 98% of the times.

This misses the point. It's actually very easy to provide pattern recognition that would handle 100% of files named in any sensible manner (i.e., including more than one pattern). Personal Video Database provides user-configurable regex because it must handle a wide variety of different video types and naming conventions. For series alone, most of it's users don't need to modify the two regex provided in it's default configuration. The same thing could simply be hard-coded in MC, and users told the different patterns the program will recognize.

The problem with providing a regex-configurable system is most users will ignore the fact this is intended to offer choice, and assume the program should simply recognize all their files automatically. Some are capable of holding this expectation even if their files have no discernible pattern. This forum would be inundated with questions along the lines of, "I download episodes from anywhere and everywhere, and the files are scattered across my HDD. Why won't MC match them properly? I've looked at the regex in my configuration, but I don't have a clue what they mean." The result is a lot of pain and frustration for very little benefit.

I shouldn't imply any pattern-matching logic employed for series is simple. It's also important they do not match things that are not series. That's another reason I think it best to leave it up to the developers to find a sensible balance in logic—one that will reliably match a variety of episode-naming schemes, while not matching movies and home videos that could have similar patterns. In the end, users would be instructed to use one or more of a number of clearly defined patterns. This will work for most files regardless of source, but files not matching any of the patterns would have to be renamed.

After the scraping is done, we need ways to show this info properly. Today we will face the problem with info regarding series and seasons. Especially Series info/review, season info/review and images for both. We have no fields for this, and no default good way of showing it, and we have currently no images for Series and Seasons.

This is somewhat of an overstatement. The current system is sufficiently flexible to allow for the configuration of views appropriate for series. It would be nice if there were a few more tools available that might be applicable only to series—perhaps some sort of "watched summary" and the accommodation of banners. But the answer is not to create a fixed view type especially for series. I would still want the flexibility of creating different views—one for episodes on hand and not yet viewed, another that would show an entire season of episodes, but highlight those viewed, not viewed and not yet available, and another for a complete historical record of all seasons, etc.

[MrHaugen]

I doubt the episode records would, in fact, be saved in a "separate database." But I'm also deliberately not attempting to describe how this should be done within a proprietary structure I know nothing about.

And I do understand that. I was just afraid that you proposed something that the user would notice as a separate database. If it's all under the hood, and there to give us better data, I have no problem with it of-course.

By letting go of the notion the system must be rigid, closed and fully-automatic 100% of the time, all these sorts of issues go away. While it doesn't always apply, the S00 E00 organization works fine 95% of the time. If we have the ability to add episode records, then we can easily accommodate specials or anything anything we might want to add that does not exist in the TVDb. A pre-season special that doesn't exist (they often do), can be handled by simply adding an "E00" record to the season, and naming the file accordingly. Anything could be added to "S00" or "S99" without concern about conflicts with normal episodes.

Yes, that would be an easy way to go about it. And it would pick up almost all cases. Just remember to search for those cases when there is no S or E between the numbers as well. As I mentioned cases like 105, 316 and so on. Being Season 1 Episode 5 and Season 3 and Episode 16.

This misses the point. It's actually very easy to provide pattern recognition that would handle 100% of files named in any sensible manner (i.e., including more than one pattern). Personal Video Database provides user-configurable regex because it must handle a wide variety of different video types and naming conventions. For series alone, most of it's users don't need to modify the two regex provided in it's default configuration. The same thing could simply be hard-coded in MC, and users told the different patterns the program will recognize.

The problem with providing a regex-configurable system is most users will ignore the fact this is intended to offer choice, and assume the program should simply recognize all their files automatically. Some are capable of holding this expectation even if their files have no discernible pattern. This forum would be inundated with questions along the lines of, "I download episodes from anywhere and everywhere, and the files are scattered across my HDD. Why won't MC match them properly? I've looked at the regex in my configuration, but I don't have a clue what they mean." The result is a lot of pain and frustration for very little benefit.

I shouldn't imply any pattern-matching logic employed for series is simple. It's also important they do not match things that are not series. That's another reason I think it best to leave it up to the developers to find a sensible balance in logic—one that will reliably match a variety of episode-naming schemes, while not matching movies and home videos that could have similar patterns. In the end, users would be instructed to use one or more of a number of clearly defined patterns. This will work for most files regardless of source, but files not matching any of the patterns would have to be renamed.

Why do you say something against things I come up with, when we basically agree with each other right away? Trying to think of what we disagree on here, but I struggle.
You say that it's easy to have pattern recognition pick up 100% of the series cases. I would say, no. There will probably be cases where user interaction is required (as you mention with the users config of regex as one example). Either in the terms of changing names on the files, or by providing a special patters so MC picks it up. With your suggestions above, most of the patterns would be picked up perfectly. This is why I'm saying that in the most cases we don't need the user to do anything. With a good default pattern recognition, most of the users will probably be fine. Do I say that there is no need to inform the users what patterns will be picked up? No. Do I say that we can't have a way to add our own pattern? No. Do I say that the user will never have to change the filename? No. I'm simply saying that this should be good by default, and most users will be perfectly happy.

If there was some way to set the Media Sub Type during import, then there would be no issues as to what MC should use the series patterns or not, to look up info for Series. If we for instance want MC to pick up series info and tag it under import, there have to be some kind of rules imo. Why not make it possible to select the Video Subtype under the Auto Import setting? Most users have one folder for Series don't they? If the users are not smart enough to keep a separate folder or three for series, and rather spread it it all over the HDD, they can blame them self I say. Anyway, there IS possible to deal with this problem, and to rule out all other video types, to get the pattern matching more accurate.

This is somewhat of an overstatement. The current system is sufficiently flexible to allow for the configuration of views appropriate for series. It would be nice if there were a few more tools available that might be applicable only to series—perhaps some sort of "watched summary" and the accommodation of banners. But the answer is not to create a fixed view type especially for series. I would still want the flexibility of creating different views—one for episodes on hand and not yet viewed, another that would show an entire season of episodes, but highlight those viewed, not viewed and not yet available, and another for a complete historical record of all seasons, etc.

Overstatement, is it? Have you looked at other Media Centers like Xbmc and the different projects based on this? Have you seen the info, the summary, the nice banners, backgrounds, the sorting and filtering options etc? I do not say anything about fixed views. I'm perfectly aware that we can have different views with series today. What we can not have today is the info pane when browsing series and seasons, and to get the info that is common for each series or season, in a good manner. This is one of the downsides of Media Center Theater View. I'm implying that it should be possible to mark some view's to have the info pane up at all times, so we can have info regarding the series/tv show and the seasons. As you mention, a summary... This should be configured in Theater View Options, as with other view options imo.  You should be able to set "Enable Info pane on higher levels in this view" or something like that.

Lets say you have 2 views. One with with the normal Series -> Seasons -> Episodes, with thumbnails on the whole side. You then have another View with Series Banners and the info pane with series summary. You browse down, and you get the Season covers/thumbnails and the info pane with Season summary. Drill down into a season, and you get the normal episode Thumbnails.

[rick.ca]

Why do you have to say something something against some things I come up with, when we basically agree with each other right away? I do not understand why I'm missing the point here.

I don't understand why you're missing the point either—but you are. And I disagree with you. But that's okay. Matt asked for advice. I offered a straightforward recommendation based on my experience in supporting PVD users on the same matter for the last two years. Hard-code the pattern recognition, and tell users exactly what file naming schemes will be recognized. Offering a user-configurable pattern recognition system is not necessary and will only create frustration for users and those trying to support them. In short, "force the users to use a certain naming rule."

You're entitled to your own opinion, but please don't ignore mine and claim that we're in agreement.

If there was some way to set the Media Sub Type during import, then there would be no issues as to what MC should use the series patterns or not, to look up info for Series.

How would the Media Sub Type be set during import, when nothing is known about the file? The user should be able to specify which folders are to be scanned for episodes. If they wish to improve reliability, they would restrict it to folders only used for series. As for auto-tagging on import, once a file has been identified as an episode—all the meta data for which has already been recorded. What needs to be tagged?

Overstatement? Have you looked at other Media Centers like xbmc and the different projects based on this? Have you seen the info, the summary, the nice banners, backgrounds etc?

Yes, overstatement. I'm not inclined to swoon at such eye-candy and ignore what can be done in MC. I've already acknowledged there are things that should be added to improve the handling of series. But I already have series records in my episode views (i.e., meta data for series). It wasn't particularly difficult to do, and will be even easier now that fields can be related to series. You say you want a pane for seasons, but I don't know of any meta data source for season information. So, other than perhaps your "watched summary," I can't imagine what would go there.

I don't see any compelling reason to show series information along with episode information. Maybe the only necessary departure  from the current navigation model is the ability to display series information at a "level" above season and episode views. That could be done simply by allowing a large information panel to be displayed when a category item is selected. In other words, select a series in a list and optionally view it's information panel by pressing <right>. (This would be a nice feature for music as well—allowing Artist and Album information to be displayed while navigating through an Artist-Album-Track view.) Then move on to a list of seasons (if more than one) and finally a list of episodes—just like the current model. The final episode view could include features unique to series—like including banners and status (viewed, available, pending) indicators of some sort.

I have no difficulty imagining something that handles series effectively, while fitting nicely with the existing design and navigation system. It would allow all the information to be displayed in a useful manner, and remain flexible enough that a wide variety of different views could be configured using the same model. It may not be XBMC, but we have XBMC for that.

[MrHaugen]

You're entitled to your own opinion, but please don't ignore mine and claim that we're in agreement.

I must have misread you badly then. I don't really care whether it's hard coded or user configurable really. I can tweak settings, or I can rename files that is out of standard. No big deal either way. As it's only for Series it should be no problem. I do however not see the big problem if this is somewhat user configurable (as it will probably include movies etc later on?), as long as it's a good standard setup that gives a good result for new users, without tampering with search codes/patterns. As I say. It does not really matter. What matters more it to map fields and DB tables when scraping data. Especially if you're not using standard fields. And without some work on the Media Sub Type field, there will be some of this.

How would the Media Sub Type be set during import, when nothing is known about the file? The user should be able to specify which folders are to be scanned for episodes. If they wish to improve reliability, they would restrict it to folders only used for series. As for auto-tagging on import, once a file has been identified as an episode—all the meta data for which has already been recorded. What needs to be tagged?

Why would this be so difficult with this? You don't know that you are importing series if you monitor a Series folder with auto import? The simplest example I can think of is to mark the folder for auto import as Series/TV Shows when you first set it up. Just a few simple checkboxes that in the end will help with series, movies and music lookup.  The user should know if he/she have a folder consisting only of series (video content). This suggestion is is much based on the Autotagger? plugin. Which have functionality I think would be best to implement in MC to a certain degree, to help with issues like this one.

Yes, overstatement. I'm not inclined to swoon at such eye-candy and ignore what can be done in MC. I've already acknowledged there are things that should be added to improve the handling of series. But I already have series records in my episode views (i.e., meta data for series). It wasn't particularly difficult to do, and will be even easier now that fields can be related to series. You say you want a pane for seasons, but I don't know of any meta data source for season information. So, other than perhaps your "watched summary," I can't imagine what would go there.

You don't have to get swoon by anything. I do think you know that eye candy actually sells though. Just look at Apple. It sells like hell, even though their features, or lack there of, is questionable at times. I do not really NEED all of this things things my self, but I try to also see what will please most users. If you look at this image http://pictures.xbox-scene.com/4/xbmc/tvshows.jpg you'll see much of what I'm trying to push MC towards. A series view with basic information for each Series and Season. In this picture you have Series Plot/Overview, Genre, First Aired date, Rating, Runtime, number Not Watched and Episode counter. Things like this could also be present for seasons. There is actually information on other things than just episodes. It is not so hard to believe that users would find this effective and good looking. This fields could easily be added with Relation Fields, and coupled with theTVdb. Is all this info in theTVdb? No, probably not. But why not support it? There are people that have tons of meta data for things like series.

I have several shows I have not yet started watching. I'd like to read some about them before I decide what to start watching. If there is something I have been watching, I want to see how many episodes there is left that I have not viewed. I'd like to know the start date of the series. I'd also like to see the date of the last episode, to see if there is time to get more episodes. Other things like producers, actors and so on could also be relevant here. The only thing this view is missing is the banners. But as usual in MC this could be selected like you do today. Thumbnails, listview, banners, details etc. Don't think it would take much programming to have 1 column with banners if there is a info pane present, or a couple of columns if there is no info pane? Or something along those lines..

I don't see any compelling reason to show series information along with episode information.

Me neither. Why would anybody? The correct info have to be shown in different levels of the view. Corresponding to the things you actually review.

Maybe the only necessary departure  from the current navigation model is the ability to display series information at a "level" above season and episode views. That could be done simply by allowing a large information panel to be displayed when a category item is selected. In other words, select a series in a list and optionally view it's information panel by pressing <right>. (This would be a nice feature for music as well—allowing Artist and Album information to be displayed while navigating through an Artist-Album-Track view.) Then move on to a list of seasons (if more than one) and finally a list of episodes—just like the current model. The final episode view could include features unique to series—like including banners and status (viewed, available, pending) indicators of some sort.

Yes, it would be nice for lots of other things than series! Artist bios is one example. I do not think that moving right to get this info is the best way though. What about those that want to use the cover art thumbnails as usual? I think that all other levels of the view should contain either a Info Pane (about half the width  or less of the screen) with such info. Whether it's about the artist, about the album, about the series, season or a movie. If you need the big screen info window, I think this is more a subject of thorough reviewing, and would be perfectly acceptable to be accessed only at the file level. But again, this info pane should of-course be optional, and be able to set at each view, and perhaps level.

I have no difficulty imagining something that handles series effectively, while fitting nicely with the existing design and navigation system. It would allow all the information to be displayed in a useful manner, and remain flexible enough that a wide variety of different views could be configured using the same model. It may not be XBMC, but we have XBMC for that.

I'm suggesting no different. I don't want to mess up navigation or anything else. My suggestions, and yours, would fit perfectly in todays Theater View if done correctly. MC16 is not Xbmc, and thank a lot for that! Actually, the ONLY thing that is good about Xbmc is the eye candy and the way you can review series and movies before you watch them.

[glynor]

I don't understand why you're missing the point either—but you are. And I disagree with you. But that's okay. Matt asked for advice. I offered a straightforward recommendation based on my experience in supporting PVD users on the same matter for the last two years. Hard-code the pattern recognition, and tell users exactly what file naming schemes will be recognized. Offering a user-configurable pattern recognition system is not necessary and will only create frustration for users and those trying to support them. In short, "force the users to use a certain naming rule."

I think that generally, the contents of the [Filename] tag should be irrelevant.

The tags in MC are what matter.  The filename should be able to be Q79F4t6.mp4 but if it is properly tagged in MC as [Series] = Breaking Bad, [Season] = 3, and [Episode] = 6 (or [Name] = 3e06, and some variants, because those are common) it should automatically "know" that it corresponds to this episode.  And then, of course, grab all the other data that TVDB has, like the [Description], [Actors], and [Network] tags.

It would be nice to be able to parse the filenames on ingest ALSO, of course.  But many of these aren't going to be able to match a given naming structure.  For myself, Sage saves them with filenames that I can't control (and which would prove difficult to parse well because they don't have any spaces in them).  The way to have the system inside MC "recognize" the files once they're already in MC is via the tags, not via some strict filename structure.

UPDATE: Generally, I do NOT want the PVD model of data downloading.  If I did, I'd already be using it.  I want something automated, but based around the tools and structure that MC already has an uses to deal with metadata.

Also, like MrHaugen, I think the ability to set Fill Tags from Filename rules on a per-watched Auto-Import folder basis would be key.

[rick.ca]

UPDATE: Generally, I do NOT want the PVD model of data downloading.  If I did, I'd already be using it.  I want something automated, but based around the tools and structure that MC already has an uses to deal with metadata.

Please re-read my original post. I have no idea what you mean by "the PVD model of data downloading." It seems clear, however, what I've suggested is far more automated than what seems implicit in your comments. You seem to be saying the filename doesn't matter because the file is going to be tagged. How is that going to happen automatically?

I've recommended a system in which all the series information for the series specified by the user would be downloaded and recorded in the database, and this information be automatically updated on a regular basis. This is clearly how the TVDb API is intended to be used. [Aside: I believe images are handled separately, so users could request images only for their "active" seasons—because they've excluded other seasons from views anyway.] With that in place, all the meta data for whatever episodes are imported already exists. All that's required is the matching of those files to their pre-existing record. That's easily done if the series, season and episode are embedded in the filename in a recognizable pattern.

For those who insist on an inefficient work flow that has MC trying to import files that cannot possibly be identified in an automated manner, it would be a simple matter to offer a facility for doing so manually. Unmatched files could be tagged (or their file name changed to a recognizable pattern) in the Recently Imported list, and then a Match to Episode Record command invoked. I suppose such a command would be necessary in any case—to handle whatever exceptions there may be. A file name that refers to a series not in the database could result in a detour to the TVDb configuration where the series would be added, or an attempt to do so automatically (e.g., "The Breaking Bad series is not in your database. Would you like to add it?").

I don't know if you're suggesting your Sage files are already tagged (as to identification) by some other means. If that's the case, then matching by filename is irrelevant. I haven't commented on how it would work, but there would obviously need to be some kind of internal matching of existing files whose tags are changed to match TVDb episode records—or for which the TVDb series data is downloaded for the first time. How new files are processed can be controlled by using differently-configured auto-import folders. If you didn't want your Sage files matched by filename, then you would simply configure their source folder accordingly. And...

Also, like MrHaugen, I think the ability to set Fill Tags from Filename rules on a per-watched Auto-Import folder basis would be key.

This would be possible too, but is irrelevant to my proposal which has all episode files tagged with complete meta data instantly on import. Auto-Tagging is a completely separate feature, which I too hope to see implemented in MC16.

[raldo]

Please re-read my original post. I have no idea what you mean by "the PVD model of data downloading." It seems clear, however, what I've suggested is far more automated than what seems implicit in your comments. You seem to be saying the filename doesn't matter because the file is going to be tagged. How is that going to happen automatically?

Exactly. PVD is semi automatic because the user must identify the movie after parsing has been applied. You need some kind of pattern in file names for automatic detection to work. But even then there may be ambiguities. Same name, different year etc.

A suggestion:
(0) MC imports
(i) MC parses filenames. The filename is left as is.
(ii) Patterns are used to determine if a file is a series (sSSeEE, SSxEE etc). Tag series, season, episodes
(iii) Patterns are used to extract movie/series name.
(iv) Patterns are used to extract year ( (YYYY) etc.)
(v) Establish an MC lookup tag which can be used to detect which the degree of success on lookup.
(vi) MC looks up in wikipedia or tvdb. If there is an ambiguity, the lookup tag is filled with some indicator of success.
(vii) MC selects the most likely candidate (wikipedia/tvdb popularity?) and fills filename
(vii) If there is an ambiguity, the user can invoke an "ambiguity resolver dialog" in theaterview/standardview and select the proper candidate for metadata.

[rick.ca]

Why would this be so difficult with [setting Media Sub Type]?

Nothing. But in the context of what I've proposed, it's completely irrelevant. If files are properly identified from their filename and matched to a record that already has all the information, then obviously this (and any field like it) would thereby be set automatically.

If you look at this image you'll see much of what I'm trying to push MC towards.

There's nothing in this which is inconsistent with what I've said. I do wonder, however, if XBMC views are as easily configured as MC's. If this view is achieved only through a skin and is not one of many different presentation available through straightforward configuration settings, then I don't consider it a meaningful benchmark. But, for a "possible new feature," it's premature to be discussing the precise visual aspects of the implementation. I've already stated what I believe should be the general direction—accommodate series within the current navigation and display model.

I do not think that moving right to get this info is the best way though. What about those that want to use the cover art thumbnails as usual?

Obviously, you wouldn't use a thumbnail scheme if you wanted this sort of information. <Right> and <OK>/<Enter> are already established as the means for displaying details in the other schemes. I'm suggesting <Right> could be used for this purpose, leaving <OK>/<Enter> for navigation to the next level.

[rick.ca]

Exactly. PVD is semi automatic because the user must identify the movie after parsing has been applied. You need some kind of pattern in file names for automatic detection to work. But even then there may be ambiguities. Same name, different year etc.

It seems to me you're straying off-topic. This is about implementing TheTVDb as a meta data provider. It's for series only. And the task of matching filenames of episodes only to pre-existing episode records is much simpler than the general case we're familiar with in PVD. So simple, in fact, it doesn't even have to succeed. As long as the filename is properly recognized as an episode, then program can suggest appropriate action if a certain match is not made—as I outlined in that post.

All that's required of the user is to add the series to their configuration, and then use that series title in their filenames. We can count on TheTVDb to refer to series with unique names (i.e., common names are distinguished by adding the inception year to the title of the later one). There can, of course, still be ambiguities in downloaded filenames. I think the best way to handle that is to allow the user to specify in a series configuration alternative names (from filenames) that should be matched to that series. To be completely flexible, it should also be possible to specify that [Series] be set to something different than TheTVDb series title. Yes, confusing—so an example...

Human Target is Human Target 2010 at TheTVDb—to distinguish it from the 1994 version. I've never heard of that version, so I'd rather call it Human Target. Downloaded file names might be Human.Target.2010.S00E00... or Human.Target.S00E00..., so I'd like both to be recognized. This is not about how the pattern recognition works. Those titles are different, and should be recognized so. But these situations can easily be handled if the alternatives can be specified in the configuration...

TheTVDb Series: "Human Target 2010"
Also match: "Human Target,"...
Set [Series] to: "Human Target"

[glynor]

That's easily done if the series, season and episode are embedded in the filename in a recognizable pattern.

For those who insist on an inefficient work flow that has MC trying to import files that cannot possibly be identified in an automated manner, it would be a simple matter to offer a facility for doing so manually. Unmatched files could be tagged (or their file name changed to a recognizable pattern) in the Recently Imported list, and then a Match to Episode Record command invoked.

To briefly explain a little further...

My issue is simply with basing a system around expecting the filenames to be consistent BEFORE they are imported into MC.  This is by-and-large a pipe dream for many people.  A large portion of the power of MC is that you can use MC to fix those inconsistent filenames.  If any system were developed where I needed to manually "tag" my files by modifying the filenames in Windows Explorer before I import the files, then it would not work for me at all.  That would defeat the purpose!  I'd sure rather spend my time tagging inside MC than using and remembering some arcane and pre-defined filename structure.

Now, that said... You'd certainly want to implement some sort of automated filename (and path) extraction system, and be able to use it when "it is available".  However, this would almost certainly need to be user definable, and variable depending on the files' sources.  The parsing system I'd want to use for my SageTV recording directory would be very different than the one I'd want to use for stuff that comes in off of Telestream Episode, DVD Fab, or even uTorrent.  Now, each of these systems dump files into different locations on disk (or I can change it so they would), so if I can define custom user-defined parsing on a per-import-folder basis, then that would solve SOME (but certainly not all) of the complexity.

That brings up another point, though... You asked about my existing Sage recordings' tags.  And, YES, they are already tagged in sidecar files (each file has two sidecar files in different formats that contain all of the metadata).  MC just can't read from them.

I guess all I'm getting at here is the difference between "the Dream" and what might be realistic.  Obviously, having MC auto-parse the filenames and extract the relevant data is "the Dream."  And we should work towards that dream.  But I also want the feature to be actually usable in the real world.  Files in my system come with a WIDE variety of different possible filename structure systems.  I think that if you try to do all of this at ingest time (which, on my system happens typically while I'm not even in the house, much less sitting at a computer), the code would need to be so horrifically complex that it would never work right for most people.  For example, here are a few of the "new" filenames I already have in my system right this very moment:

Fringe - 3E06.mkv
Fringe.S03E03.720p.HDTV.X264-DIMENSION.mkv
The.Walking.Dead.S01E04.720p.HDTV.x264-CTU.mkv
The Office US 702 - Counseling.mkv
True_Blood_Minisode_1_Eric_&_Pam.mp4
treme.1e02.720p.x264.mkv
30Rock-ChainReactionofMentalAnguish-1386680-0.mkv
Invictus-852962-0.ts
InsideWashington-2233754-0.mkv
Austin City Limits-(Esperanza Spalding; Madeleine Peyroux)-2010-02-11-0.ts
Australia-2010-03-03-0.ts

Those are all from different sources.  Some of them, to a parsing engine, would seem to be similar that are not (like Invictus which is a movie, vs Inside Washington which is a news show that doesn't have real defined episode titles or anything other than a date).  Not only that, but even the ones that are tagged with a s01e05 style structure, use a wide variety of different "schemes" to encode this information.  The files all use different delimiters (sometimes spaces and dashes, sometimes periods, sometimes underscores, and I didn't have any now, but some use a combination of the above).  And, many include a bunch of pieces of information that I don't care about at all, and then others use a structure that I just frankly don't like.  A human can look at it and grok the meaning nearly immediately, but a parsing engine is going to have to be immensely complex to parse all of this data.  It would be a Reg Expression of epic proportions!

The only way to solve that problem would be to force the user to adhere to a smaller set of "recognizable patterns" that the program knows how to look for.  And THAT'S the point of failure I see.  I don't want to have to tag the files in Windows Explorer to avoid having to use the (much nicer) tools in MC to tag them properly.  I can't, frankly, without disabling Auto-Import and that isn't an option (because sometimes I just want to watch the stupid show and I don't care if it isn't tagged because I'm going to delete it afterwards).

So, I'm not saying that parsing the filenames is a bad idea at all.  If you read MY first comment on this, I said that (it needs to be able to get data from anywhere it can).  I just don't think that parsing filenames will be enough for most people to be able to effectively utilize the system.  Not even close.

So what I'm saying is that the feature cannot be built upon a system that depends on recognizing a filename pattern, and certainly not on one that requires those filenames to REMAIN consistent once they've been imported into MC (because I'm going to build my disk naming structure the way I'm going to build it, and even you and I would never agree on a pattern, much less the whole MC using community).  It can consider the filenames as one possible source of data at ingest time, and if it happens to work then great, but that can't be the only or even "primary" way to get that information.

[glynor]

I didn't state it explicitly but the reason I'm concerned about the "Reg Ex of epic proportions" is performance.  We can't also require everyone to have an 8-core behemoth of a machine to be able to use MC with acceptable performance.

MC already does a LOT at ingest time.  Parsing filenames can be computationally challenging.

[rick.ca]

So what I'm saying is that the feature cannot be built upon a system that depends on recognizing a filename pattern...

You still haven't considered what I've proposed, and I believe what you're talking about is largely off-topic. Even if you don't think so, what I've proposed is on a much narrower topic. I thought is was obvious, but I just don't see any potential for an online database of television show meta data to help in any way in the identification and tagging of other types of video media. If you would read what I've posted, you'd see that I'm not only not talking about a system that gets data from filenames via pattern recognition, I've explicitly said such a thing is not necessary for the specific purpose of implementing TheTVDb. Yes, there would be an element of pattern recognition—but only to match episode files to episode records that already exist. That's the only possibility for something that's fully automated. If you can't rename your files—tough. There's no reason everyone else has to suffer your circumstances. I've already outlined how such a system would handle files that can't be identified automatically on import, but which would be tagged by the user at that time. If I were in that situation, I wouldn't waste time tagging all the fields of an episode. I'd just change the filename to a recognized pattern, then let the system do the rest automatically.

For example, here are a few of the "new" filenames I already have in my system right this very moment:

All of the episodes in this list would be identified correctly as such by the recognition system I've proposed. If the series exist in TheTVDb and have been set up in MC, their import and complete tagging would be fully automatic. The other files are either not series or are impossible to identify as such, and therefore have nothing to do with this topic. I wouldn't mind discussing how to handle such files in the context of an auto-tagging system (which I would expect to use regex to extract information from file pathnames), but you don't seem interested in that...

I guess all I'm getting at here is the difference between "the Dream" and what might be realistic.  Obviously, having MC auto-parse the filenames and extract the relevant data is "the Dream."

If I had any reason to believe you'd actually considered my suggestion, I'd find this highly insulting. I'm not stupid and I don't make recommendations I consider to be frivolous and unrealistic—especially in subject areas in which I have a lot of experience.

A human can look at it and grok the meaning nearly immediately, but a parsing engine is going to have to be immensely complex to parse all of this data.

Perhaps, but for series alone—as I've stated repeatedly—it's dirt simple. If any of your examples were excluded (at a glance, I don't see any), it would be intentionally so—because their pattern conflicts with something that's not an episode.

I didn't state it explicitly but the reason I'm concerned about the "Reg Ex of epic proportions" is performance.

I don't know where you're getting this from. If it wasn't obvious in the first place, I explicitly stated it several times—the pattern recognition would only be applied to import folders used for series. In your case, you'd not apply it to your Sage folder, and you would apply it to your torrent download folder. If you were concerned about that over-taxing your system (I don't believe that's possible), you could configure your downloader to use two folders—one for series and one for everything else. For uTorrent, this is a natural thing to do. Episodes would normally be downloaded using the RSS downloader, in which you'd specify the series import folder as the one to which the files are be saved. Everything else goes to the default download folder—which you'd specify as your "everything else" import folder.

[glynor]

You still haven't considered what I've proposed, and I believe what you're talking about is largely off-topic.

Look... This isn't personal at all, and I think we mostly agree.  But to answer your "question" as it were...

I certainly have read and considered your suggestion, as best as I understand it.  I just don't completely agree.  I think what you are proposing would be better served as part of an auto-tagging function.  The goal is to get the metadata from the files into the tags, after all.

Any automated scheme that pulls in metadata from the "cloud" should base those decisions on the tags already in MC's database, not on filenames directly.  It is fundamental to the approach at using any digital asset management system... The database is king.  The filenames are often poorly formatted and even when there is data there, it is often unreliable.  You can use that data as one of possibly many potential sources (including sidecar metadata formats, in-file tags, and context about where the files are on the filesystem).  Then, once you have that information, you go out to the cloud.  That way, it could handle ALL files seamlessly, whether the auto-tagging system is able to parse the filename or not.  Once the bare minimum of tag data it needs is there, MC silently fills in the missing tags (series descriptions, episode titles, episode descriptions, network, actors, writers, etc) in the background.

That is all I meant all along.  If you (or anyone else here) already meant that and I misunderstood, then fine.  If you disagree, then that's fine too.

As far as the performance stuff... Well, then I suppose we can see.  I'll say this, the parsing done by every single system that I've ever seen that does it based on complex filenaming rules is an order of magnitude too slow for the number of files I ingest.  Maybe Matt can code a miracle, but I'm skeptical is all.

[glynor]

Look.  I think I can explain myself better and more simply now.  It is really all semantics.

I do think that having an automatic filename parsing function of some kind is essential to making this sort of video metadata system really work, if you want "normal" people to use it (people who otherwise just wouldn't bother tagging their files and search in a big list by whatever Name tag is already there).  I just think that system makes more sense functionally to "live" in the Auto-Import part of MC, and that any connection to theTVDB should be separate from and not tied to the process of importing the files.  That's for lots of reasons.  Partly because I'd want it to run on the data in my library already, to a small degree because I philosophically feel the "database is king" and the filenames don't matter, and also because I think it might be useful for it to run somewhat continuously.  I don't know for sure how that would run in practice, but much of this data is community driven.  There are PLENTY of movies that I've already imported info from Wikipedia on that is "spotty" at first, but then later on the content improves.  If the data isn't able to stay "linked" (optionally, of course), then I don't get the benefit of the "evolving" content in the cloud without knowing enough to manually go retag that file via the manual process.  If it is manual, you don't know that you don't have the cool new artwork or the fixed writer credit or the more accurate description tag unless you stumble upon it randomly (or if you happen to be a bit obsessive about keeping all of your tags perfect, which is nice for some people, but the product needs to appeal to more than just that segment).

Also... Only about 10% of my stuff is from uTorrent and similar sources.  Generally only when I can't record a show via Sage for some weird reason, or if it is a foreign show.  So if the system only works on those types of new content, then... Well, I just don't think targeting that exclusively is a good idea for a bunch of reasons.  It isn't like Sage isn't a popular DVR choice for Windows, but whatever... The bottom line is this:

I would like to see MC read the metadata content from a wide variety of additional sources in an automated fashion, including:
1. The full feature set of Fill Properties from Filename applied on an automated basis (per folder in the Auto-Import setup or something to that effect) at import time.
2. Reading from online sources of information like theTVDB and Wikipedia (and hopefully more) on ingest and (optionally) on a continual basis.  I envision that this would happen fully automatically if any of the other metadata "sources" provided enough tag information to provide a reasonable "lock" on the exact item that you are auto-tagging, but could also be manually requested (similar to the existing Wikipedia system), including item #1 (which would parse file names).
3. The ability to read as many sidecar metadata and in-tag metadata formats as is humanly possible, including these.
4. I think that the online "cloud" database that MC uses for CD info, Album Art, etc should expand to include Video file metadata.  Automatically filled by us (the users) in some fashion if we opt-in (perhaps some sort of opt-in filter would be appropriate so we can filter out home movies, project video, and clips for editing and stuff like that... You know, porn.)  You may not be able to just wholesale "leech" the data from theTVDB, but you can certainly get a lot of great user-fixed and user-generated data yourself.
5. The above database should be able to be applied in some sort of automated or semi-automated fashion based on a fingerprint of the file itself, filename matches, and some level of tag matching (if a lot is already filled via the other sources).

Does that make more sense?    

PS. It would be extra-nice if they could also provide as a #6 some sort of smart filename parsing logic that looks for the most common filename tagging systems out there (the variety of common "[Series] - s[Season]e[Episode] - [Name]" style methods), but I don't know if that's something they'd go for.  If so, and it is great and it works then that would be an insanely awesome feature.  It sounds like a non-trivial programming challenge to me, though.

EDIT AGAIN:  Ha ha.  It ALL sounds like a non-trivial programming challenge to me, though... So what they hell to I know.  I'm dreaming here. 

[rick.ca]

Does that make more sense?

None whatsoever.

But seriously, you posted this just before I was about to post the following (which I haven't changed). I really do think you're way off topic, and unnecessarily obscuring a very straightforward suggestion. Most of what you've been saying and continue to say warrants one or more separate topics. I don't see any relevance to the much narrower topic at hand. Providing the ability to include series meta data independent of files in no way restricts how you might otherwise get meta data for those files. It certainly has nothing to do with other methods that might be employed to get meta data for files that are not series, or are the sort of series simply not found in TheTVDb.

Sorry to be long winded, but when it seems necessary to repeat the same ideas over and over again, I lose whatever limited ability I may have to be brief...

It is fundamental to the approach at using any digital asset management system.

The fact that you would say this suggests we have a fundamentally different point of view. I don't collect TV episodes. I generally download, watch and delete. Whatever is "fundamental to the approach at using any digital asset management system" is probably not applicable to the situation. Considering it's nature, I'm not particularly interested in wasting time manually tagging a file I plan to delete. At the same time, it's critically important I have current information about what I've recently viewed, episodes on hand and what's coming up next. That provides important context to what's available for viewing, allows me to make better decisions about what to watch at any particular time, and to see at a glance if anything is missing.

When I'm watching TV series I am, by definition, wasting time. I really don't want to waste more time tagging files recently downloaded just so I can make an informed decision about how to waste my time. I want just the opposite—to fire up MC in Theatre View and let it tell me the exact current state of my TV series. I'm sure my system of renaming files, scanning them with PVD and importing meta data with PvdImport is far more efficient than what most people do, but it's still not fully automatic. And, of course, it doesn't include any information about episodes I've watched and deleted, or not yet downloaded. It won't tell me if there's an episode that's been released but my downloader's apparently missed.

What I want is, in some respects, similar to what a Tivo and maybe a Sage user gets (although I'm not familiar with either). I imagine that is a melding together of schedule and file information. The result shows episode information in chronological/episode order, and at the same time somehow clearly indicates which ones have been recorded and are available for viewing. Think of the "schedule data" as that provided by TheTVDb—not as files are imported, but as the information becomes available. The files will be matched to this data, indicating which episodes are available for viewing. Once that is done, these records should behave no differently than any other file record in MC. They can be included or excluded from any view, they will be tagged with all the data from TheTVDb, and the system will record maintain the usual dates, play counts and ratings associated with the file.

I think what you are proposing would be better served as part of an auto-tagging function.  The goal is to get the metadata from the files into the tags, after all.

I think this is why you're having trouble understanding what I consider to be a very simple suggestion. Why would you define the "goal" like that? It doesn't really fit the requirements as most users see them. Other than being the thing I ultimately watch, I have no particular interest in the file itself. Although TheTVDb data may not be "reliable," it's certainly no less reliable than the file my downloader finds. If the downloader gets the wrong file, I'm much more likely to delete the "digital liability" than I am to figure out where it belongs. The last thing I would do is change TheTVDb entry to match an incorrect file. MC will analyze the file and provide duration and technical information. Other than that, all the meta data will come from TheTVDb, and that information (for the most part) will be available a week or two before the file is. I want that information in MC—as soon as it's available. From my perspective as a watcher of a series, the only significance of file is whether or not it exists. Information added after the file arrives is of much lesser importance. I'm not going to be that interested in an episode after I've watched and deleted it.

So, no, your goal is inappropriate for series—as I want to relate to them. The goal should be to properly match files to the correct episode already recorded in the database. Other than providing a convenient means for accomplishing the necessary matching, filenames have nothing to do with it. And, obviously, "going out to the cloud" to get information already recorded in the database makes no sense whatsoever. The incoming file has no meta data associated with it at all. If it can be automatically matched via it's filename, then it will have all it's meta data automatically. If TheTVDb data is incorrect, there's no loss. The user can correct it. If the file can't be matched automatically, then the user can match it. If there's no record for it (e.g., it's one of those oddball specials not listed by TheTVDb) then it can be added.

I don't know (because I'm not familiar with the services available), but some might be interested in the feature for providing information about episodes streamed from some online provider. Instead of matching files to the episode records, URL's would be recorded so the episode could be streamed when "played."

[glynor]

I haven't finished reading your reply yet rick, because I just got back here and I realized I'd lost the thread a little there (because beer) and didn't actually finish my story as it was.  Which may have given the opposite impression of what I meant.  I will finish reading in a second here.

What I meant to end with was...

I think ALL of that is great (the 5-6 items I outlined above) and I think that they need to work on accomplishing some or all of them for the MC16 product cycle.  But I also understand that this is a small development team, and what it seems to me that Matt was asking about right here was just how to use theTVDB's data.  So, if we are ONLY talking about the ingestion of data from this new data source, but looking at it in the context of the larger discussion we've been having about Media Sub Types and Theater View and using Video in MC on a daily basis as a set-top-box replacement... I think it makes the most sense to base the lookup of data in theTVDB based on the information already in the database (which can certainly include the [Filename] tag if they can get to it).  And plan to in the future also address the problem of automating the collection of that metadata by doing something vaguely like the list items I suggested above.

All of the above list is important, which includes what you want, I believe.  But I think the topic is too big.  He's asking about theTVDB.  To me, to look up information from theTVDB, MC needs to use the tag data in it's library.  That's the whole point of having MC!  If they can accomplish #1 and #6 from my list above too in the process (or all of it, frankly) then I'll be the first to jump up and down like a crazy person, my friend.  

But until then, I think that the path of least resistance is for it to base the decision on the [Series], [Media Sub Type], [Season], and [Name] tags (and maybe [Episode] if they give us a Fill Episode # from track order command like we have for audio).  If it can also parse the filenames or [Name] tag for common 3e06 type structures and figure it out, then all the better.  But, frankly, if you do bother to go through the process of tagging those few pieces of information first, then it should work for you best.

I will now finish reading what you wrote, because I think you have some very good points.

[glynor]

You did have some very good points.

In some cases, with certain shows, I am absolutely a collector.  I collect the HBO shows, and Fringe, and I did Lost, and lots of other things that I think I might want to enjoy again some day (probably not for years, but that's what the shelf is for).  Since I've actually PAID for most of my content (via premium cable channel subscriptions and DVD purchases - or at least Netflix), keeping the good stuff matters to me.

With TONS of other stuff, just like the Inside Washington show I listed above, or The Daily Show, or some random junk 30 minute comedy or whatever... I'm a watch-and-deleter just like you.  In those cases, I agree with basically everything you just wrote 100% (and have written as much myself many times before).  If I have to manually tag those files in any way, I just won't bother.  I'll just sort them by the [Name] tag or by some date field and find what I want, watch it, and delete it.  (Or I'll just use another product to watch them, which is what happens usually.)  It would be WAY BETTER if the system was able to get information for these (which would require accomplishing #1, #2, #3, and #6 in my above list at a minimum) so that I could browse these shows in my Theater View views and find them via a [Series]/[Season] view or something like that, and have nice descriptions and cover art and beauty.

That's why I think all of that other stuff in the list is so important.  Because we need to be able to feed the online metadata lookup system with good information from as many sources as possible (including some sort of smart filename parsing, I hope) so that we can easily get at least the [Series], [Season], [Episode], [Name], [Description], and hopefully Original Air Date (and maybe a few others) tags from somewhere without having to type them in!!  And that's why I keep bringing the other stuff up.  It is important for the whole thing to work for most people (and most people are watch-and-deleter viewers who couldn't be bothered to tag the files).

The counter point of that, of course, is that a much higher percentage of MC's existing customer base are collectors than with the general public, since it is a tool for doing just that.  While that should be considered, I do NOT think you can only structure the system to appeal to such a small niche, though.  However, the "people who are willing to fix their filenames" and "the obsessive collectors" are both niches in some ways.  For it to really work, for my wife or my mom, I think that in the end, you need to do more than just one or two of these systems.  But, after watching this company operate for years, I feel like all that is all way too big for this specific piece of it.

PS.  You never have to apologize to me, of all people, for being long winded, unless you get absurd.    

[glynor]

I think this is why you're having trouble understanding what I consider to be a very simple suggestion. Why would you define the "goal" like that? It doesn't really fit the requirements as most users see them. Other than being the thing I ultimately watch, I have no particular interest in the file itself.

I just wanted to also specifically respond to this.  I do completely understand where you're coming from here (as I hope I adequately explained above).  You misunderstand the reason I said the "goal is to fill the tags".  The reason the point is the tags is not "because I'm a collector" and because the tags are themselves innately valuable.  They usually aren't in the long term.  For most of my files, those tags will only be used until I watch and then delete the file.  The tags are important because that is the mechanism that MC uses to allow you to browse the files nicely in Theater View.  That is whole model for how you find things in MC.  Filling the "tags" is the whole point of parsing the filenames and going to theTVDB to get information because that is how you are going to be able to browse the information in Theater View via a nice UI.

So the point of all of this quite literally is... To fill the tags so that we can browse that metadata via MC to decide what we want to watch when we are being lazy and sitting on the couch.  That's what I meant.

[glynor]

Oh, and I forgot to add... I don't understand the basic point of your original suggestion of having tag information in your view for shows that you can't watch because you don't have them.

I mean, in a few circumstances, sure.  But generally it doesn't seem very important to me.  Now if MC could offer some integrated way to go and download those files via a legit service, then we'd have a whole different story on our hands.  But talk about a pipe dream!  So, on the acquisition of all of the tag info, I think we agree about the steps necessary.  I just don't get the basic idea of why you'd want that information there all the time for things you can't actually watch (and if you do for some reason, just Google "epguides [Series]" and you'll get the epguides.com listing of all of the air dates and episodes).  You can easily make this a link in MC already (I have done just that, actually).

Nix that.  Maybe some version of this basic idea could be quite useful in some cases.

If you could click a button or something and turn it on and off, where it would show entries for the other episodes in a season, grayed out or dimmed a bit or something, to show you the context of the episodes you do have available... That would be pretty cool.  You would have to be able to turn it on and off pretty quickly though.  Most of the time I'd want it hidden.  But to "pop it on" and see the other episode titles and their descriptions and stuff would be pretty cool.

[rick.ca]

You did it again! If you're going to encourage me to be long-winded, you have appreciate I type very slowly. This time, you've posted two messages while I've been pecking away...

Oh, and I forgot to add... I don't understand the basic point of your original suggestion of having tag information in your view for shows that you can't watch because you don't have them.

It must be the beer... Not all of my needs for information are tied directly to a file on my HDD. I may simply want to see the episode description for next week. That might even be important to me if it confirms it's part 2 of today's part 1—I prefer to watch those back-to-back. Episodes are not always released every week. The next episode record may confirm there's no release this week.

That is whole model for how you find things in MC.  Filling the "tags" is the whole point of parsing the filenames and going to theTVDB to get information because that is how you are going to be able to browse the information in Theater View via a nice UI.

I think we can agree we both have a very good understanding of the "MC model." This is why I originally referred to the data downloaded from TheTVDb as a "separate database." I didn't mean that literally, only that the downloaded episode records would be "separate" from the filename-based records as we perceive them to be in the "MC model." It's only a notional thing. I can only guess how it might be done. I'm quite sure Matt is the only one who would ever understand exactly how it should be done. The only point I'm making is a very simple one, and it's fully intended to address the need for reliable file meta data on a timely basis. Use the TheTVDb API in the manner for which it was designed. Get all the meta data in advance.

That's the wonderful thing about files that are members of series. We can get most of the meta data for them before they even exist. (The same thing is true for any file, but I want to keep this on topic.) And the data itself helps us ensure the files are properly identified and tagged. I don't think this should be incorporated into the matching logic, but if a file is matched to an episode to be released next week, we might deduce there's a problem. This is an occasional issue for us downloaders. There are jerks out there who create bogus torrents for episodes not yet released—obviously to throw-off RSS downloaders (the file has to be deleted and the counter reset, or the legit file will be missed). As it does for other things, the proposed system would provide an opportunity to spot such issues—without having to go looking for them. In other words, the task at hand doesn't have to be seen as getting the correct meta data for the file. If you already have the correct meta data in advance, you can use it to determine whether you're getting the correct file for the meta data.

The following is in response to your previous message (again, unchanged)...

I, of course, don't know what the plans are for MC16. But I do know doing everything necessary to handle all sorts of video with multiple meta data sources is far too much. I did wonder if they might do TMDb along with TheTVDb. I don't know if the same people are behind it, but the two look very similar and other applications use both of them. In any case, the "deal" seems to be the same and the API similar. But TheTVDb would be a good start. If it were implemented as I suggest, I'd probably stop using PVD for series—I'm not as interested in series as I am in movies, and I believe TheTVDb could provide all I need. Considering the volume of episodes compared to other video types, the prospect of completely removing them from my video meta data/tagging routine is very attractive.

I believe what I've suggested serves a wide range of user interests very well. For watchers and deleters, it provides the necessary up-to-date snapshot of the current "flow" of episodes and their availability and view status. In most use cases (the series are properly configured and data is available at TheTVDb), this would be fully automatic and MC would be the first and last stop for any information about series. Instead of having to check my downloader or file manager to see if expected episodes have arrived, and then update PVD, I would be able to see that directly and immediately in MC. This makes a huge difference, mainly because it otherwise requires checking some source to determine exactly what episodes are expected at any particular time.

For collectors, the data provides a complete record of the entire series. Even if only certain seasons are collected, this will be a valuable reference for most collectors. And while a serious collector may be interested in getting more information than what is provided by TheTVDb, configurable field mapping will ensure having this data in no way impedes getting data from other sources. While I expect I would be happy with this data alone, I should be able to fill other fields with data I already have in PVD (downloaded from IMDb and Allmovies). I may as well do that at the beginning at least—since I have the data anyway. Or to look at it another way, this would allow many serious collector a way to automatically handle the current flow of episodes and whatever other media they may add (e.g., DVD's of previous seasons), allowing them to focus their efforts to get more or better data in the areas that are most important to them. In other words, to tag for the enjoyment collectors get from collecting and cataloguing, rather than having to tag a huge pile of files for which there's no information at all—just so they can be managed.

Most people, like you've described for yourself, will fall somewhere in the middle. But I think it's clear just about everyone, to some degree, will have exactly the same interests as both the watcher and deleter and the serious collector. It will do everything for the former, and provide a great start for the latter. It probably doesn't do much for series watchers outside of North America, but they can always use PVD to get their data from anywhere.

BTW, in case you're wondering why PVD's number one proponent is advocating this alternative, I've recently found a better use for PVD. I've modified it's Allmovie script to download album data from Allmusic. I now have a complete database of all my albums with all the Allmusic data (of interest to me). I included artist group members and biographies as well. All this data, of course, is automatically fed to album and artist relational fields in MC using PvdImport. This may have changed my perspective a tad on the larger question of how MC might help us get meta data generally. I'm not expecting JRiver to catch-up with me any time soon.

[darichman]

Personally, I think a lot of the issues raised here could be solved by forcing the user to complete certain fields on import... If a minimum number of fields were filled out it would help both in terms of deciding (1) which files are appropriate for series lookup and (2) the appropriate query to use during lookup and (3) which views the files should appear in.

A brief import wizard might even be the go - "What type of media is this?" ... user selects "TV series" or "Feature Film" or etc etc. This could be our first discriminating point as to how the program deals with the media (which views the file will appear in, which metadata source will be used, naming scheme...). "What is the name of the show?" User types 'The Big Bang Theory'. At this point the program could offer suggestions for field values  (Series, Season, Episode) based on regex or fill properties from filename - either automatically or at user request I guess.

I also think we could benefit from some *gasp* standard fields:

[Media]: TV Series, Feature Film, Stage Production, Anime, Documentary etc

• This field tells MC how it should treat any given type of media (I don't see why it should be limited to video)
• Think Media Subtype, but editable
• This should be a list field. I want to be able to tag an anime movie both as 'Anime' and 'Film' and have it appear in both relevant views within the library
• MC could have some default views set up (standard view and theatre view) for default values
• This field could determine what type of lookup to do: TheTVDb for series for example. It would be nice to see some other lookup options down the track (IMDb or TheMovieDb for film), and to be able to specify which sources to use for which media category.
• If naming conventions are encouraged, there has to be a way for MC to know what type of video it's dealing with, and honestly I think using a field like this is the way to go as there will be no universally consistent way of knowing from the filename or even the directory structure

[Title]: The Big Bang Theory, Braveheart, Swan Lake

• I think we should do away with the [series] field and use a single field to define the name of any given video content
• This could contain the name of any TV show (series or not - think TV specials), films, shorts, documentaries, stage productions
• This could be used as a query for lookup on TheTVDb (or other lookups if added at a later date)
• I think all files for any given show should have the same year (provided we're talking about the same series), as it's done on IMDb. A separate 'episode year' or 'release date' field could be used to show when individual episodes were released.
  
• Given this, MC needs to be clever to separate Title/Year combinations of different movies or shows with the same name (Think 'The Office' as a TV show and 'Peter Pan' as a film, multiple releases
• Maybe MC could store a unique code (or use the IMDb code - covers vast majority of video media) to differentiate cases like this

Then the various associated metadata fields... Personally I'd like to see a field mapping configuration dialog somewhere, even if it's hidden away in the options menu.

[JimH]

When this blows over, would someone try to summarize in a few words what you think you agree on?

Thanks for all the thought you're putting into this discussion.

[rick.ca]

If you could click a button or something and turn it on and off, where it would show entries for the other episodes in a season, grayed out or dimmed a bit or something, to show you the context of the episodes you do have available... That would be pretty cool.  You would have to be able to turn it on and off pretty quickly though.  Most of the time I'd want it hidden.  But to "pop it on" and see the other episode titles and their descriptions and stuff would be pretty cool.

Yes, that's similar to what I have in mind. I haven't commented on the display aspect because something like this is necessary for series no matter where the meta data comes from (although my suggestion does introduce not-yet-released episodes).

The ability to interactively hide/show episodes is an interesting idea. We already have the ability in include or exclude episodes from a view based on attributes—so that would include whether or not they've been seen or if a file exists. But toggling the visibility of viewed episodes would definitely be cool. Otherwise, greying-out viewed and not-available episodes (with different hues to distinguish the two) is exactly what I had in mind—for Theatre View. (I wouldn't expect any of this to be applied to Standard View.)

As I've suggested before, there's an important view parameter that should be included in the feature's configuration of each series. That is the option to suppress unwanted seasons. The obvious option would be to suppress all but the current season, but that may not be enough. I suppose it could just be a list of season numbers and/or ranges (e.g., "1-3, 5").

If the Theatre View display of the current season of a series is to be pretty much as it is now (with the embellishments we've mentioned), then there's another option that would work nicely. I've always found the view that lists the 1-3 episodes I typically have available for viewing a little sparse. Including previously viewed and not-yet-available episodes will solve that problem—but may go too far the other way. Having to always scroll to the end of a 20+ episode season would be a little annoying. So it would be nice to have an option to limit the number of previously viewed and not-yet-viewed episodes. The result might then be a pleasing list of episodes available for viewing, bracketed by a few each of previous and upcoming episodes—all of which would fit on one screen. I think I would find this preferable to toggling the visibility of viewed episodes.

[rick.ca]

Personally, I think a lot of the issues raised here could be solved by forcing the user to complete certain fields on import... If a minimum number of fields were filled out it would help both in terms of deciding (1) which files are appropriate for series lookup and (2) the appropriate query to use during lookup and (3) which views the files should appear in.

I seem to be alone on this, but I really think this is completely beyond the scope of what Matt has asked for our input on. I'd be happy to discuss the handling of different video types, etc., but it's out-of-place here. More importantly, it's obfuscating what I believe is a very simple and effective approach to the implementation of TheTVDb as a meta data provider for TV series.

I wouldn't expect any sane person to read all that's been posted here, so I'll summarize my proposal...

• Use TheTVDb API in the manner is was designed for. Download and record the entire series record for each series requested. These episode records will necessarily be saved in a manner different from the usual MC record which requires the existence of a file.
  
  
• Provide a fully-configurable mapping of TheTVDb fields to MC fields. A default configuration will necessary map some items to standard fields, but all must be configurable. That will allow users to avoid conflicts with data from other sources or their own tagging.
  
  
• In the feature's configuration, users will specify the series they require—by title. It might include a TVDb lookup to verify the title, but the user can almost as easily do this manually using a browser. If a lookup is unsuccessful, it will be necessary to do that anyway. Include an alternate title to be used for [Series], and an additional title to be used in filename matching.
  
  
• TheTVDb update routine should be run automatically daily. This will ensure the meta data for all series are up-to-date and minimize the need to re-download entire series. (Individual episodes can be updated, but that's inefficient and requires the user to guess which ones are in need of updating.)
  
  
• Provide a routine that matches episode files to these episode records by filename. The pattern matching requirements of this task are very much simpler that for the general case. Only series are being matched, and they're only being matched to the records that have been downloaded from TheTVDb. It will not be difficult to provide reliable recognition for all of the patterns commonly used for episode filenames. This is so straightforward it should be hard-coded and users told exactly what patterns are recognized.
  
  
• The matching routine would be available as a file command (i.e., run for selected existing files) and as something that can be attached to the auto-import configuration for a specific folder. This will provide the means to automatically perform the matching for incoming series files only (i.e., users would apply it only to folders containing episode files).
  
  
• Although TheTVDb episode records and actual file records will necessarily be separate initially, they will appear to be merged when matched. (They might actually be merged, but that's a technical consideration.) Whether an episode, file or merged record, they should appear and be handled the same/usual manner in all MC views.

The primary benefits of this design are...

• The library will include information allowing new episodes to be anticipated. This greatly enhances the completeness and accuracy of the "episode collection system" in general.
  
  
• Having records of all known releases of episodes for all series being collected greatly simplifies the matching of files to their meta data. The fact the meta data will always exist in advance of the file eliminates delays and failures in looking-up the information as the file is imported. The result will be views that always show the exact current status of all episodes—viewed, on hand and pending.
  
  
• The library will include a complete history of each series, even if the files have been deleted—or never existed.
  
  
• Other video types/meta data sources could be implemented in a very similar manner—with at least some of the same benefits. TMDb, for example, could be implemented this way so movie records could be downloaded—even if the files do not exist. This allows the creation of a "wish list." When the media is acquired, it's simply matched to the existing record—which then becomes a "normal" movie record. It would still be possible to get meta data only after the media is acquired, but it's silly not to get it in advance if there's any interest in it.

[leezer3]

I broadly agree with rick.ca's ideas.
Having said that though, this is how I'd do it:
* This doesn't actually need to be automatic. TBQH, it'd probably work a lot better in it's own little wizard, much like the current Wikipedia lookup, thus:
1. Select a series. MC determinies what it 'thinks' it is from the current tags. (I would probably use Series for this, but it should really be user configurable in the wizard)
2. TheTVDb search routine is run. Either match directly to their data, or present a list if the precise identity is unclear.
3. This data is stored (You could pretty much just store the XML files if you wanted to keep this separate from the main database)
4. A window is opened, containing a list with metadata filled in. The user can correct this list if necessary by editing the episode/ series numbers.
5. Tags are written back to the files.
* Merging records and similar is probably a bad idea. The metadata needs to be filled in once when the tagging routine is run, then should be user editable.
* Dummy records for episodes not on disk is an interesting idea, but one that IMHO is getting ahead of ourselves. Focus on getting metadata for files that are actually there first
* Somewhat related to the previous, it might be an idea to store the number of episodes per series in a relational field? This would allow easy identification of series which are missing an episode for relatively low overhead.

For reference, I'm a collector. I haven't deleted anything much (Basically utter crud only) for ~9 years now.

-Leezer-

[rick.ca]

I broadly agree with rick.ca's ideas.

So broadly, it seems, the points of agreement are impossible to find.

I'm baffled as to why, but it really does seem I stand alone on this. You'd think I was advocating something wacky and dangerous—like relational fields. The impression others are giving me is they're so completely stuck on the "database of files" paradigm they're incapable of seeing the merits of anything that deviates from it. I'm afraid if that's the case, it can only lead to the slow, agonizing death of MC. Unless it can evolve to better include and manage information about media, it's doomed.

As a case in point, meta data for any particular user's collection of a subset of episodes cannot possibly be as significant and useful as a source which has all the data for the entire series. Why would you want to bother picking and choosing data just for the episodes you happen to have when it's much more efficient, reliable and useful to simply take it all? Doing so in no way interferes with meta data obtained by other means or added manually. Doing so means it's always there ready to be instantly matched to files whenever you do acquire them—if that's all you're interested in. In fact, even if you insist on believing there's something wrong about getting information for files that don't exist, it's still the most efficient way to get the data.

This doesn't actually need to be automatic.

What? If something is fast, efficient, and completely automatic, why would you want it otherwise?

2. TheTVDb search routine is run. Either match directly to their data, or present a list if the precise identity is unclear.

TheTVDb search routine is not always going to work. As a practical matter, it's rather pointless when all you have to do is identify the series correctly when it's added to the configuration. Building a search and add series routine around the event of the first incoming file for that series is absurd. It's much more effective to configure a series so that any episode for that series is properly recognized—automatically. The API works primarily by providing files with complete series data, and then providing regular updates to that data.

Merging records and similar is probably a bad idea. The metadata needs to be filled in once when the tagging routine is run, then should be user editable.

I should have been more explicit. Once a file is matched to an episode record and the two "merged," the record would become a normal file and would not be updated again with TheTVDb. A difficulty I did not consider, however, is the fairly common situation where data is added to TheTVDb for an episode in the days immediately following it's release. So I think you're right, the records should not be merged. Perhaps the best solution is to simply accept that all the fields fed by TheTVDb will be updated if changed at the source, so should not be used for user-entered data that's not okay to overwrite. Users would still be free to use other fields for their own data, and these could be filled by copying and editing the downloaded data.

Dummy records for episodes not on disk is an interesting idea, but one that IMHO is getting ahead of ourselves. Focus on getting metadata for files that are actually there first

This is next to useless from my perspective. Very few episodes survive longer than a few weeks in my HDD. I fail to understand how my proposal can be considered "getting ahead of ourselves" when it's actually a more natural way to implement the service offered, and it eliminates many of the problems associated with getting meta data for files one-at-a-time as they're imported.

Other video types/meta data sources could be implemented in a very similar manner—with at least some of the same benefits. TMDb, for example, could be implemented this way so movie records could be downloaded—even if the files do not exist...

Maybe this is the most important benefit of all. This could be the first step in breaking the chains of the "database of files" paradigm.

[glynor]

I'm baffled as to why, but it really does seem I stand alone on this. You'd think I was advocating something wacky and dangerous—like relational fields.

 

That made me chuckle.

[darichman]

Well... actually I am in agreement with the 'complete database' idea you've proposed, Rick. I like the concept of adding or matching files to an existing entry rather than doing individual lookups per file. I also think there is merit in having the info for episodes I don't actually have - this would show me which episodes I'm missing as well as show a complete record of the show.

It's just up until now (and especially until recent developments with artist relational fields) I didn't see it happening.
How far is J River willing to take this?


And as for

I seem to be alone on this, but I really think this is completely beyond the scope of what Matt has asked for our input on. I'd be happy to discuss the handling of different video types, etc., but it's out-of-place here. More importantly, it's obfuscating what I believe is a very simple and effective approach to the implementation of TheTVDb as a meta data provider for TV series.

I don't think it's beyond the scope at all. Matt's opening post was very broad in it's request for suggestions, and I think something like this is core in ensuring elegant lookup from online sources - Media Center needs to know what to query the site for. You are free, of course, to disagree.

[MrHaugen]

It's amazing to see a few people, so determined to win this suggestion word war. Sounds like very stubborn grumpy old men, if I may say so. And I might very well be the grumpiest one of them

You have some very good points Rick. Almost none of them goes directly against what I have suggested. It's just a little different twist. Only reason I have been opposing some of them is that you lost me somewhere between all those words and sentences. The shorter list made it much clearer though. I'd like to just point out a few things, or suggestions that adds to this. I understand that the suggestions here is more directly tied to this particular service, and how to take advantage of it in MC. But I also know that if this is going to work well, you'll have to do some work in other places as well.

I'll use your list Rick, and add a few thoughts here and there in bold.

• Use TheTVDb API in the manner is was designed for. Download and record the entire series record for each series requested. These episode records will necessarily be saved in a manner different from the usual MC record which requires the existence of a file.
  I agree
  
  
• Provide a fully-configurable mapping of TheTVDb fields to MC fields. A default configuration will necessary map some items to standard fields, but all must be configurable. That will allow users to avoid conflicts with data from other sources or their own tagging.
  I agree
  
  
• In the feature's configuration, users will specify the series they require—by title. It might include a TVDb lookup to verify the title, but the user can almost as easily do this manually using a browser. If a lookup is unsuccessful, it will be necessary to do that anyway. Include an alternate title to be used for [Series], and an additional title to be used in filename matching.
  Not an idea I want to shoot down. It would simplify things for some, but again it would make some users drop the whole thing if they need to add things in options every time they add a new series. Especially if they use Theater View all the time, and have to get their keyboard and mouse to enter options and add the name of the series. Things like this would be best handled totally automatic imo, or with a very easy way of adding the Series from Theater View.
  
  - I do not think it's impossible to remove the ".", "_" and " - " and "s" in front of the numbers of the file names, replace it with single spaces, and use it for lookup. However, there have to be a pattern recognition to pick up where the season and episode numbers is. The pattern here is mostly one of this two: sXXeXX or XXX (X being numbers). The import suggestions you mention below, which me and Glynor also have tired to tell you the need of, would limit the pattern recognition to only Series. It would be very reliable in most of the cases, and should not be a very difficult part of this implementation I hope. The few times this fail, the users could have the option to either rename the files, or add the Series name to lookup options.
  
  - The other way of solving this would be to add new Series from Theater View. This would be very easy with the Filter and Option Panes I've described earlier. You have one pane, which can be activated anywhere, to filter media and another pane to set simple options like this one. Add new Series name for TVDB lookup. Hit enter, and use on screen keyboard to enter name. As I've mentioned earlier, this panes should work with enter press on the appropriate roller button, and the pane with filtering and options would appear. This could be used to remove so much clutter from the rollers as well, and to introduce other, much wanted features to Theater View.
  
  
  
• TheTVDb update routine should be run automatically daily. This will ensure the meta data for all series are up-to-date and minimize the need to re-download entire series. (Individual episodes can be updated, but that's inefficient and requires the user to guess which ones are in need of updating.)
  I agree
  
  
  
• Provide a routine that matches episode files to these episode records by filename. The pattern matching requirements of this task are very much simpler that for the general case. Only series are being matched, and they're only being matched to the records that have been downloaded from TheTVDb. It will not be difficult to provide reliable recognition for all of the patterns commonly used for episode filenames. This is so straightforward it should be hard-coded and users told exactly what patterns are recognized.
  I agree
  
  
• The matching routine would be available as a file command (i.e., run for selected existing files) and as something that can be attached to the auto-import configuration for a specific folder. This will provide the means to automatically perform the matching for incoming series files only (i.e., users would apply it only to folders containing episode files).
  I agree. This is one place where you can easily mark the Auto Import Folder settings to mark the files as Series. To set the Media Sub Time as series for example. And the pattern recognition would be a lot more accurate when treating all videos in this folder as series.
  
  
• Although TheTVDb episode records and actual file records will necessarily be separate initially, they will appear to be merged when matched. (They might actually be merged, but that's a technical consideration.) Whether an episode, file or merged record, they should appear and be handled the same/usual manner in all MC views.
  I agree
  
  

The primary benefits of this design are...

• The library will include information allowing new episodes to be anticipated. This greatly enhances the completeness and accuracy of the "episode collection system" in general.
  I agree
  
  
• Having records of all known releases of episodes for all series being collected greatly simplifies the matching of files to their meta data. The fact the meta data will always exist in advance of the file eliminates delays and failures in looking-up the information as the file is imported. The result will be views that always show the exact current status of all episodes—viewed, on hand and pending.
  I agree
  
  
• The library will include a complete history of each series, even if the files have been deleted—or never existed.
  I agree
  
  
• Other video types/meta data sources could be implemented in a very similar manner—with at least some of the same benefits. TMDb, for example, could be implemented this way so movie records could be downloaded—even if the files do not exist. This allows the creation of a "wish list." When the media is acquired, it's simply matched to the existing record—which then becomes a "normal" movie record. It would still be possible to get meta data only after the media is acquired, but it's silly not to get it in advance if there's any interest in it.
  Looking into Movie lookup would be the next step after this. I totally agree. And a lot of the work done for series, would be available for Movies as well. But dragging all media into this at once might be messy
  
  

Another thing I think we should really consider is a few relation fields to use with this setup. There is a few things that will be common for each series, like Series Overview/Review, Genre. This gets really important if you consider adding more info on a Series and Season level, like I have been suggesting for a long time now.

[rick.ca]

It's amazing to see a few people, so determined to win this suggestion word war.

War? That would imply debate over conflicting ideas. There's only been a few of those. For the most part, the volume of words has to do with people ignoring what's been said, making false assumptions and arguing with themselves. Grumpy? Hell, yes. It's a royal PITA having to repeat the same thing over and over and over again.

Things like this would be best handled totally automatic imo, or with a very easy way of adding the Series from Theater View.

In #3 I stated, "If a lookup is unsuccessful, [a manual lookup using a browser] will be necessary to do that anyway." The "lookup" I'm referring to is TheTVDb search that's required to find the title in the online database. MC has no control over that. And I'm able to advise—because I use it every day—it will regularly fail. When doing the search in a browser, you have some feedback as to why it's failing, and can choose the best way to amend the search. The same can be done via an MC dialog, but it's not easy to create something that's as effective as a browser. I'm happy to leave that one up to the developers, but it seems like a waste of time considering how often a user is going to need to set up a new series.

In the system I'm recommending, there's very likely things other than just a title that need to be specified in the configuration. Frankly, the idea of setting up a new series from Theatre View is absurd. If a new series has not been configured and the data downloaded prior to the first episode being acquired, it follows the user isn't so interested in that series they're going to care if there's no data for it immediately. Besides, how is that an episode for a new series is going to appear in the first place? The user must have requested it be recorded, ripped a DVD or added to the RSS downloader of their torrent client. If they've done any such thing, they can also perform the almost trivial task of adding the series to the configuration. Doing so will ensure all the data is available, and the first episode automatically recognized and tagged when it arrives.

Throughout this topic, I've attempted to save words and avoid useless chatter by not getting into regex and how the pattern recognition system would work. I'm confident the developers have a good understanding of regex (whether or not it's used directly in their code) and would have no difficulty implementing what's required. At the very most, I would expect them to ask us what we think are the patterns that should be recognized, but they probably already know that. So, for the nth time, recognizing the series title from any of the commonly used filename patterns would be a trivial matter. The problem is, as I've restated above, the title extracted may still not be the same as the title used by TheTVDb. This is why I've recommended the configuration include alternate titles to be matched and the exact TVDb title to be used (allowing yet another title to be used for [Series]).

[#6]: This is one place where you can easily mark the Auto Import Folder settings to mark the files as Series. To set the Media Sub Time as series for example. And the pattern recognition would be a lot more accurate when treating all videos in this folder as series.

As I've stated several times already, auto-tagging is a topic in and of itself. Yes, you might find it convenient to have [Media Sub Type] set. But that's true for all file types and many different circumstances. In this particular case, your need is much less because your episode is already going to be tagged automatically. If the source folder doesn't tell you what you need to know (to handle the file in views and smartlists), the meta data surely will. As I've clarified above, my proposal does not require any information in addition to the filename to make a perfect match.

But dragging all media into this at once might be messy.

Why? I now download Allmusic album data for all my albums. Even though that's highly automated, I still waste time looking-up the particular albums I happen to have, and the whole exercise tells me nothing about the albums I don't have. They're not always going to interest me, just like I may not be interested in all seasons of a series. But for many artists, I'm interested in all of their original albums—whether I have them or not. It would be a whole lot simpler and more efficient to simply download all the data, and let MC automatically match the albums I have. And, just like with episodes, MC would automatically match any album I add to my collection to the pre-existing data.

The concept is applicable to any media for which there is an available source of categorized meta data. In addition to TV series and musical artist albums, it might apply to the works of classical composers, photographers, painters, movie directors, or the "Top 100" list of any type of media. None of this has any impact whatsoever unless the information is available and there's a desire to use it. But information like this is increasingly available (as in a flood) and there will be an increasing desire to use it. I believe it critical to the survival of MC to accommodate the data in it's database structure, provide the means for getting it, and manage it well.

Methods to "provide the means for getting it" is yet another (huge) topic. My view is there should be a scripting engine that allows the use of user-created scripts that will get information from any source. JRiver can add open sources like TheTVDb and TMDb, and offer commercial services for a subscription, but that's all. A scripting engine would allow any data a user has access to to be added to their library.

Another thing I think we should really consider is a few relation fields to use with this setup. There is a few things that will be common for each series, like Series Overview/Review, Genre. This gets really important if you consider adding more info on a Series and Season level, like I have been suggesting for a long time now.

You can already relate any field to [Series]. As for [Season]—I've asked but you haven't answered—what kind of information are you talking about? Theoretically, there could be descriptions, reviews and aggregate credits data for seasons, but I'm unaware of any sources that provide consistent data of that sort, so it doesn't seem worth the bother. If you want to handle something like a season overview, you can easily do so by adding a dummy record for "E00." This, of course, will be easier to do with the system I've recommended—as it will allow you to add such records without the need to create a file.

[MrHaugen]

War? That would imply debate over conflicting ideas. There's only been a few of those. For the most part, the volume of words has to do with people ignoring what's been said, making false assumptions and arguing with themselves. Grumpy? Hell, yes. It's a royal PITA having to repeat the same thing over and over and over again.

There are others who get annoyed by repeating them self to. No worries. But it does not exactly help to attack others or sound condescending during the discussions though. If people even get the slightest hint about such things, the discussions forward can be very colored by this. And that's a shame. All of us have made some assumptions, put some ideas in the air, only to see there is other ways to handle a few of them, that might be better. Working together to get results like this, is what matters. I do not care if my initial idea is shot down, if a better one is implemented in the end.

In the system I'm recommending, there's very likely things other than just a title that need to be specified in the configuration. Frankly, the idea of setting up a new series from Theatre View is absurd. If a new series has not been configured and the data downloaded prior to the first episode being acquired, it follows the user isn't so interested in that series they're going to care if there's no data for it immediately. Besides, how is that an episode for a new series is going to appear in the first place? The user must have requested it be recorded, ripped a DVD or added to the RSS downloader of their torrent client. If they've done any such thing, they can also perform the almost trivial task of adding the series to the configuration. Doing so will ensure all the data is available, and the first episode automatically recognized and tagged when it arrives.

You might be right about alternative titles, and you might be right when you say that there will be things that fail in lookup. If that is the case, there needs to be a way to correct this. Add alternative titles, or manually look for alternatives. It does not change the fact that a lot of people like to use their HTPC without keyboard and mouse though. And in that case, they are most often in Theater View. It's FAR from absurd to do normal maintenance tasks or simple option setups from Theater View. Lot's of Media Centers use this today.

Me for instance, use HTPC in theater View, and I like to stay there. Every time I have to tweak something I have to plug in my mouse and keyboard, or to use the Logitech DiNovo and fiddle with it for 3 times as long. I do NOT use my HTPC to import media. This is done with auto import. When I use remote Desktop to my file server and add series to my Series catalog, I want it to turn up in the Theater View within minutes. And it does that today. But, it's untagged. Some kind of auto tag system during import would help massively with several media files. For me, it will not even turn up in my regular Series views without my Custom Video Sub Type tag set to Series. This would also enable the file code pattern recognition to know exactly what files to scan, and to compare to the downloaded series data. Why you have the files in MC, or before that if you which, you can add series names either through standard view options or Theater View, so they are added to MC.

This might be trivial, and a small thing. But why do you have to burn it down just because you do think it's not needed? I do not care about your workflow alone. I do care about how many other people will use this, what they use to control their HTPC with, and how much work it will be to use it on a daily basis.

As I've stated several times already, auto-tagging is a topic in and of itself. Yes, you might find it convenient to have [Media Sub Type] set. But that's true for all file types and many different circumstances. In this particular case, your need is much less because your episode is already going to be tagged automatically. If the source folder doesn't tell you what you need to know (to handle the file in views and smartlists), the meta data surely will. As I've clarified above, my proposal does not require any information in addition to the filename to make a perfect match.

Yes, it's a topic in it self. If there is any chance that the pattern recognition will pick up other media and matching it to theTVDB though, it would be smart to be able to set the Media type under file import. Even more important would it be to set such things when standard fields is not used. Yes, It's highly usable for other media as well, but I not see any downsides of adding it when we first talk about implementing better automatic series lookup.

How can you be 100% certain that other media types will not be matched to TVDB with your current idea. Do you plan for an TVBD option where you specify where the source folder for series is? If not I can not understand who you can be sure to pick only episodes, and no other media like movies. 

The concept is applicable to any media for which there is an available source of categorized meta data. In addition to TV series and musical artist albums, it might apply to the works of classical composers, photographers, painters, movie directors, or the "Top 100" list of any type of media. None of this has any impact whatsoever unless the information is available and there's a desire to use it. But information like this is increasingly available (as in a flood) and there will be an increasing desire to use it. I believe it critical to the survival of MC to accommodate the data in it's database structure, provide the means for getting it, and manage it well.

Methods to "provide the means for getting it" is yet another (huge) topic. My view is there should be a scripting engine that allows the use of user-created scripts that will get information from any source. JRiver can add open sources like TheTVDb and TMDb, and offer commercial services for a subscription, but that's all. A scripting engine would allow any data a user has access to to be added to their library.

I do not disagree here. Far from it. Just saying that its better to do one thing at a time, and do it well. Rather than trying to do it all and fail. Series is a very big field, as this discussion clearly indicates. If it's implemented, there will also be a lot less work to add such support for other media types.

You can already relate any field to [Series]. As for [Season]—I've asked but you haven't answered—what kind of information are you talking about? Theoretically, there could be descriptions, reviews and aggregate credits data for seasons, but I'm unaware of any sources that provide consistent data of that sort, so it doesn't seem worth the bother. If you want to handle something like a season overview, you can easily do so by adding a dummy record for "E00." This, of course, will be easier to do with the system I've recommended—as it will allow you to add such records without the need to create a file.

You asked, and I answered. You just didn't read it.

If you look at this image http://pictures.xbox-scene.com/4/xbmc/tvshows.jpg you'll see much of what I'm trying to push MC towards. A series view with basic information for each Series and Season. In this picture you have Series Plot/Overview, Genre, First Aired date, Rating, Runtime, number Not Watched and Episode counter. Things like this could also be present for seasons. There is actually information on other things than just episodes. It is not so hard to believe that users would find this effective and good looking. This fields could easily be added with Relation Fields, and coupled with theTVdb. Is all this info in theTVdb? No, probably not. But why not support it? There are people that have tons of meta data for things like series.

I'm talking of things like Series/Season Overview or Review, Genre, Actors, Directors etc. Most of this things can be tied directly to the Series as a Relation field. But not Season Overview. Because it changes for each season, and the season is not unique, as there is many other Series that can have the same season number. The Relation methods of tying a field to another field, have to be expanded to match two different fields. In this case a field called [Season Overview]? have to be in relation to Series [Media Sub Type] and Season [Season]. As I also mentioned this can be used for Artist Bios etc etc.

You CAN of-course just add this info for each episode of the series or track of the album or artist, but it's time consuming. And what happens when there is different data in this fields?? It will be messy.
As I mentioned there is probably not all of this info that exists in theTVBD, but the users are using other methods of getting metadata as well, so why should we not support it??

[rick.ca]

It does not change the fact that a lot of people like to use their HTPC without keyboard and mouse though. And in that case, they are most often in Theater View. It's FAR from absurd to do normal maintenance tasks or simple option setups from Theater View. Lot's of Media Centers use this today.

MC is not designed to be used exclusively in Theatre View. For reasons I've stated, it's not practical to facilitate the set-up of new series in Theatre View. Everyone uses Standard View far more frequently than they add a new series, so this shouldn't be a hardship for anyone.

Do you plan for an TVBD option where you specify where the source folder for series is? If not I can not understand who you can be sure to pick only episodes, and no other media like movies.

I recommended the matching command be attached to the auto-import configuration by folder. That would allow the user to restrict it to a folder used only for series, but that wouldn't be essential. One would have to be extremely sloppy with their filenames to allow movies files with names containing series patterns.

Just saying that its better to do one thing at a time, and do it well.

My listing as a benefit the fact the same approach could be used for other types of media in no way implies I'm advocating solutions for everything be implemented all at once.

You asked, and I answered. You just didn't read it.

I asked you what sources there are for things like season summaries—and you did not answer. I don't believe there are any suitable sources, and the feature is therefore of no practical use. What might be useful is a special season panel in Theatre View that would summarize the fields of it's member episodes, but, sadly, no one has suggested it.

[MrHaugen]

MC is not designed to be used exclusively in Theatre View. For reasons I've stated, it's not practical to facilitate the set-up of new series in Theatre View. Everyone uses Standard View far more frequently than they add a new series, so this shouldn't be a hardship for anyone.

But why is it not? Why can't MC be set up with good choices for default views and settings, and enable control of the more common settings from within Theater View? It would open up quite a few new uses. Like a little C and remote - ready to use HTPC, with a few clicks. This would benefit J Rivers MC sales I think. Especially their HTPC's. Other producers of hardware might have been MUCH more interested in including MC as a standard setup with their Windows OEM installations for their hardware, if they can have a good setup for users out of the box, and without to much hazel for the users in huge option pages. What if one day, mid ranged or high profile hardware producers include MC on their HTPC's? That would really make MC users grow. My suggestion is just a small step towards something like that, but it's still something that needs to be considered to make MC more user friendly and easy to set up for the first time.

I recommended the matching command be attached to the auto-import configuration by folder. That would allow the user to restrict it to a folder used only for series, but that wouldn't be essential. One would have to be extremely sloppy with their filenames to allow movies files with names containing series patterns.

Matching command to a folder would definitely work. It's almost the same as I suggested, but Instead of adding the matching to an import folder to auto import, you could have the matching work towards the Series tag, for files not updated. The auto import would have to tag the files correctly as Series on a pr folder setting. It would be a bit more work for J River, but the end result would be a lot more possibilities in other fields as well, if you can use this for all fields. Basically just copy the expressions from other options in MC? I do however, not have any problem with including the matching based on auto import folder if that would simplify programming or getting TVDB to MC.

Without any of this, I'm a bit worried that you can end up with for instance movies with Year in the title, ready for pattern recognition. This can happen, as some drops the s and e in the season and episode numbering, and ends up with either 3 or 4 numbers in a row.

My listing as a benefit the fact the same approach could be used for other types of media in no way implies I'm advocating solutions for everything be implemented all at once.

Exactly. That's what I'm thinking as well. Things we discuss here could be used for a variety of things if implemented well. No need to bring music or movies to the discussion really. They will benefit if such a thing is ever considered there.

I asked you what sources there are for things like season summaries—and you did not answer. I don't believe there are any suitable sources, and the feature is therefore of no practical use. What might be useful is a special season panel in Theatre View that would summarize the fields of it's member episodes, but, sadly, no one has suggested it.

You asked what, and from where it can be found. I answered what fields that could be nice to have as an overview for both Series and Seasons. And I answered that I do not know which services supply such data as Season overview or Review. I just want to bet that it exists. I know there are people who want it if they can. Wikipedia has such info of-course, but is not exactly suited for much more than manual lookups and copy paste. One example: http://en.wikipedia.org/wiki/24_(season_6)

There is however, as I've said plenty of times, NO reason not to include the ability to add such things on info panes if we're ever given the opportunity to have info panes on levels above the media files. As you say it: A summary page/pane (Number of episodes/Seasons, watched/not watched, producers, aired data and so on). This could be customizable just like the info pane and large info pane is on the file level today. Also remember that this discussion should not focus around Season overview. It's irrelevant, really. It's the whole picture here that is important. Overview/summary page for series, seasons, artists and so on. The possibilities it could give the users.

[glynor]

You might be right about alternative titles, and you might be right when you say that there will be things that fail in lookup. If that is the case, there needs to be a way to correct this. Add alternative titles, or manually look for alternatives. It does not change the fact that a lot of people like to use their HTPC without keyboard and mouse though. And in that case, they are most often in Theater View. It's FAR from absurd to do normal maintenance tasks or simple option setups from Theater View. Lot's of Media Centers use this today.

Me for instance, use HTPC in theater View, and I like to stay there. Every time I have to tweak something I have to plug in my mouse and keyboard, or to use the Logitech DiNovo and fiddle with it for 3 times as long. I do NOT use my HTPC to import media. This is done with auto import. When I use remote Desktop to my file server and add series to my Series catalog, I want it to turn up in the Theater View within minutes. And it does that today. But, it's untagged. Some kind of auto tag system during import would help massively with several media files. For me, it will not even turn up in my regular Series views without my Custom Video Sub Type tag set to Series. This would also enable the file code pattern recognition to know exactly what files to scan, and to compare to the downloaded series data. Why you have the files in MC, or before that if you which, you can add series names either through standard view options or Theater View, so they are added to MC.

This might be trivial, and a small thing. But why do you have to burn it down just because you do think it's not needed? I do not care about your workflow alone. I do care about how many other people will use this, what they use to control their HTPC with, and how much work it will be to use it on a daily basis.

Just a quick note... J River has previously stated (repeatedly) that the goal of Theater View is to enable ALL functions of Theater View to be usable with a remote control that ONLY has 5 buttons (though they added a 6th "recommended" button more recently):  Enter/OK, Arrow Keys, and the "Green Button".

[rick.ca]

But why is it not?

This is off-topic.

Without any of this, I'm a bit worried that you can end up with for instance movies with Year in the title, ready for pattern recognition. This can happen, as some drops the s and e in the season and episode numbering, and ends up with either 3 or 4 numbers in a row.

There is no reason to worry. If you're going to do things like name episode 11 of season 20 Series title 2011..., then you're going to have problems, so such practices should be avoided. Otherwise, three-digit numbers that appear immediately after the series title and "0x00" will work fine.

Exactly. That's what I'm thinking as well.

I'm left wondering why you questioned this in the first place.

There is however, as I've said plenty of times, NO reason not to include the ability to add such things on info panes...

There's a good reason why this is not possible, or related fields would not have been implemented in the limited way they have been. To ask the developers to go beyond what they've done just because "I just want to bet that it exists" is unreasonable. Confusing related fields with summary panes is not going to advance the latter idea—no matter how much it may merit consideration.

[Matt]

I originally planned a simple dialog that could do series lookup, a little like 'Lookup Movie From Wikipedia' in v15.  We would create some stock series fields (relational) and populate them with this tool.  It would be nice if it could also run silently when doing television recordings.

My main use for the data is to make Theater View a little more interesting to look at.

Someday it might be expanded to do episodes, or to happen automatically at import based on filenames, or to even create records for episodes you don't have, but these ideas are probably generation-two types of things.

[rick.ca]

I originally planned...

Had you said this at the outset, I wouldn't have wasted my time offering "advice." 

[leezer3]

I originally planned a simple dialog that could do series lookup, a little like 'Lookup Movie From Wikipedia' in v15.  We would create some stock series fields (relational) and populate them with this tool.  It would be nice if it could also run silently when doing television recordings.

My main use for the data is to make Theater View a little more interesting to look at.

Someday it might be expanded to do episodes, or to happen automatically at import based on filenames, or to even create records for episodes you don't have, but these ideas are probably generation-two types of things.

Bingo, my point precisely
I don't know if you've seen the AutoMeta plugin; This is what I use at the moment, and it works generally quite well.
Sometimes a little buggy, but thats the way of the world.

Like I said previously, I agree with the general direction rick.ca is taking, but equally it's running before you can walk.

-Leezer-

[Matt]

Had you said this at the outset, I wouldn't have wasted my time offering "advice." 

I'm sorry.  For what it's worth, I found the conversation useful. 

There are a lot of smart people with good ideas.

[glynor]

• TheTVDb update routine should be run automatically daily. This will ensure the meta data for all series are up-to-date and minimize the need to re-download entire series. (Individual episodes can be updated, but that's inefficient and requires the user to guess which ones are in need of updating.)
  I agree
  
  

I actually don't agree here.  I mean, of course, that would be better than nothing.  But what I'd really like to see is the TVDB update to run continuously in the background, like AutoImport.  So that, if you change the tags on a file that was mislabeled, it would just "automagically" pulled down the other relevant tags for you in the background and within 30 seconds or so of the tag change the new data was just "there".

I originally planned a simple dialog that could do series lookup, a little like 'Lookup Movie From Wikipedia' in v15.  We would create some stock series fields (relational) and populate them with this tool.  It would be nice if it could also run silently when doing television recordings.

I figured.  Unfortunately, I think this will be of somewhat limited usefulness for most content for "many users" for the reasons outlined above.

However, such a feature could be still be workable if some considerations were made.  However, it cannot be just like the current Wikipedia system, where you'd need to submit each individual file separately.  At a minimum, for any manual system to be usable,  you'd need a system where if the files were all tagged similarly to this:

[Series]=The X-Files
[Season]=2
[Episode]=1 through 25

Then you could select them all and submit them all at once, and it would pull in episode titles, descriptions, etc for each individual episode (after showing you a "match dialog" of some kind if you had the series tagged "X-Files" or "XFiles" or "X-Files, the" instead of what it expects).  Ideally, you'd be able to select the entire Series at once, so long as all of the "sub tags" were properly filled enough for MC to figure out what was what.

If you have to submit each individual file, it just won't work.

Oh yeah, and we'll definitely need a "Fill Episode Number from List Order" function.  We'll also need a way to turn off the importing of certain fields in that "Match" dialog.  I often have a lot of my shows with properly filled [Name] tags already.  I wouldn't want MC to blow away the useful info that is there, in many cases.  However, I'd also sometimes like to let MC blow it away, if I know that mine weren't very carefully set, or were filled only with things like "7e04".  I'm just envisioning a system that shows the tags that MC knows how to fill from TVDB, with checkboxes next to each of them, and maybe with a preview of what the results will look like for one of the selected files.

That type of lookup, while still manual and therefore not ideal, would put you a lot closer towards solving some of the issues discussed above.  In the future, as you add more "auto-filling of tags from the filename" types of features (and other things) at import-time, you will eventually get to a point where you can "turn on" a feature that auto-submits new content to the lookup system.

I'm sorry.  For what it's worth, I found the conversation useful.  

There are a lot of smart people with good ideas.

Agreed.  Even if the system doesn't get there right away, the conversation is worthwhile because it stimulates ideas and can even shape the way you implement a more limited feature.  If you have an eye for future development direction, you can avoid making mistakes in a "public" system that later on ends up binding your hands.

My main use for the data is to make Theater View a little more interesting to look at.

Absolutely.  I think that is really everyone's goal in this vein.  Well... Interesting to look at and more useful when trying to decide what to watch (descriptions).