Print

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

[glynor]

So, I know it is pointless to ask that [Media Sub Type] be user-modifiable, so I won't bother.  I do remember a vague promise from the old "please make it user-adjustable" threads where it was said that if we needed additions, just to ask.

So... I'm asking.  

We have a fairly decent set of Sub Types for Video.  But the list is decidedly lacking for other media types.  Here's what I'd like.  If others have things to add, this might be a good time.  Where I feel an explanation is needed, I've added one, but not for everything when I think it is obvious.

Audio:

1. Music - We have "Audiobook" and "Podcast" but nothing for regular, you know, music.  So, right now I have to have custom Rename, Move, and Copy rules for Music with all sorts of complex logic.  I just want to set a Tag On Import rule to set all new audio to Music, and then I can change it if needed to "remove" it from the music lists.
2. System - Or "Desktop" or something like that for "system sounds".  I use MC to manage all of my audio files on my PC, including the Windows "beeps and boops".
3. Ringtone
4. Interview - I have a few Interviews that would be nice to tag specifically.  Or some sort of "people talking but not a podcast" catch-all Sub Type.
5. Concert - Requested by xplain (and others) below.

Image:

1. Photo - Just like Music under Audio, it is "assumed" that all image files imported are photos.  But if they aren't it is tough to segregate them and filter them without complex logic (or creating your own separate Media Sub Type like field).
2. Illustration - Drawings, sketches, and wacom fun.
3. Artwork - Scans and photos of actual artwork, artwork for graphic design work, etc.
4. Screenshot
5. Figures - I use MC to manage a fairly large set of "figures" (diagrams, graphs, charts, etc) used in publications and my video work.  I'd like to categorize these.  I'm not 100% attached to the "Figures" term, if you can think of something better.  Think stuff you'd export out of Excel and then save as a JPEG, EPS, PSD, or AI document.
6. System - Wallpaper, mostly.  But also all the other graphic elements of a Windows desktop theme.  Same as for "Audio".
7. Stock - Stock Images from a place like Getty, iStockPhoto, or my own library of stock images (and sounds and video too, for that matter).

Video

1. Stock - This is the one I need for Video the MOST.  Same as Images, but video (B-Roll and whatnot).
2. Interview
3. System
4. Seminar - I have a TON of "class" and "lecture" recordings at work, and I need to categorize them.  If it was JUST me that would use it, I probably wouldn't mention it, but I can also imagine a college student who might use this tag for audio or video recordings of lectures.  If you think "Class" or "Lecture" is better, or something like that, I'm not picky about the name, just something along these lines.
5. Documentary - Sometimes these are TV "series" (like NOVA) and I file them under TV.  But quite often they aren't part of any series (like the stuff they do on the National Geographic Channel, or PBS "Specials", and History Channel stuff).  I don't really want them cluttering up my Movies views (which is what I do now), but they also aren't TV Shows really.
6. Comedy - Likewise, is Richard Prior Live, or Robin Williams Live on Broadway, or Eddie Murphy RAW a Movie?  A TV Show?  No, standup comedy is really its own "thing".  This could be handy for Audio too, though most of mine are video.

Documents

1. Book
2. Manual - For washing machines, snow blowers, and that camera you can never find the book to.  Having MC organize PDFs would be sweet.
3. Software - For installers and serial number documents.

EDIT:  I've modified the above list based on suggestions from below.

[xplain]

Yes, and in the Video section, it would also be nice to have Concert-Movie

[MrHaugen]

YES, this would be great. I'm especially lacking Concerts and Comedy/Standup for video. Music video and Concerts are kind of a huge difference...

[rick.ca]

So, I know it is pointless to ask that [Media Sub Type] be user-modifiable, so I won't bother.  I do remember a vague promise from the old "please make it user-adjustable" threads where it was said that if we needed additions, just to ask.

Adding more types is just going to make an annoying problem worse. This field is being used for two somewhat different purposes that are often incompatible. Some of it's uses, and the fact it's locked-down, suggest a primary purpose from the developer's perspective: classifying media in ways essential for functions the program performs based on that distinction. I'm not going to attempt to itemize those, but Podcast and TV Show are examples. In various ways, Podcasts are not handled as Postcasts and TV Shows are not handled as TV Shows unless [Media Sub Type] is set accordingly. The design flaw is in the attempt to also use the field for non-essential classification purposes. I'm sure some of the existing types are of absolutely no use to the program currently. Others might be used in building stock views, but that's where the problem lies. Users want to do the same thing, and naturally want to use the same field to do so. But it's locked-down, so they can't use their own categories. And there's no way there will ever be one set of categories that suits everyone.

The solution is to separate the incompatible uses. One field should be used exclusively for distinctions critical for the proper function of the program. (Classifications used in stock views are not critical.) It will then be obvious changing the value of this field will have some impact on how the program handles the file. As it is now, only an advanced user would have a clue changing the value from "TV Show" to "Adult" (because it's an adult series) would mess-up the handing of such files as series. If the only choices are Podcast, TV Show and null, such confusion cannot arise.

A second field should be used for types only used for classification and organization of media ([Media Classification]?). It would contain stock classifications used in stock views. If considered necessary, those could be protected from deletion dynamically ("this category is currently used in XYZ view") or permanently. It could also include other suggested or illustrative classifications. But the field would otherwise accept whatever values the user wanted to add. Equally important, we would be able to assign a file to any category without concern doing so will break some critical function of the program.

I suggest this second field only because I know JRiver will want to continue to offer and support stock views. I prefer to build my own views, and use a custom field that's unencumbered by someone else's idea of how my media should be organized. The second field is also purely optional. I don't have one, preferring to determine such classifications by folder (e.g., I classify documentaries by putting them in a Documentary folder). I don't expect others to do the same, but it does put the issue in perspective. Why use [Media Sub Type] for classification if it's not suitable for the purpose?

[syndromeofadown]

It would be great if documentary was added as a sub type for Video.
its the only addition i need. All other sub types work great for my collection.

[jgreen]

I notice that there's nothing about Documents/Books here.  Oh why do I even bother?

[rjm]

Rick is spot on.

I gave up in frustration long ago. My standard import procedure (for everything except podcasts) is to clear [Media Sub Type] because the lack of a clean, coherent, and complete design irritates me so much. Adding to the irritation is zero documentation on what each value actually does. The only value I think we understand is Podcast and that was painstakingly reverse engineered.

I use a custom field instead and sleep well at night.

[jmone]

I'm OK with how it works using Media / Media Sub Types but then use relevant secondary fields to break these Media Subtypes into categories in Theaterview (eg see pics).  The main ones I use are in Red.  Works well for me.

[jmone]

I notice that there's nothing about Documents/Books here.  Oh why do I even bother?

I too would like the ability to manage and sync e-books to a Kindle, Andriod etc

[rick.ca]

I gave up in frustration long ago...

Well, you were even more spot on. I was trying too hard to be nice.

I probably shouldn't be reading this much into the situation, but the apparent rationale for the design troubles me. The logic seems to go like this...

• Carnac will determine and set [Media Sub Type].
• All episodes therefore have [Media Sub Type]=[TV Show].
• Theatre View will therefore include special features for any view containing files with [Media Sub Type]=[TV Show].
• If the logic continues:
  Meta data will automatically be retrieved from TVDb for files with [Media Sub Type]=[TV Show].

This seems to make sense. It might even work very nicely for some. JRiver has is all figured out—the user doesn't have to do anything. But if we fail to comply anywhere along that chain of logic, or have other needs or preferences, we're SOL. Instead of being able to configure things so they work exactly the way we want them to, we have to use ugly workarounds or just put up with something that doesn't work. I think it's a case of the design trying to be too smart for it own good.

I, too, prefer to avoid the irritation and do things my own way. But it's getting to the point where it's becoming unavoidable. To continue with the same illustration...If I want my series views to include backgrounds, those views must include files with [Media Sub Type]=[TV Show]. But that also breaks my existing views by arbitrarily using series instead of episode cover art. How's this for ugly?...I use an auto-import tag rule to override Carnac and set [Media Sub Type]=[Other] for episodes. That allows me to continue to use episode cover art (screenshots) in my series category views. I use dummy files for series information. Carnac won't do it, but I tag those with [Media Sub Type]=[TV Show]. As a result, I still get the backgrounds. It's not a great example—it probably applies only to me, and the situation (the handing of series in Theatre View) is fluid. But it illustrates the reason for my concern. I just don't believe there's any justification for these things being so rigid and fragile.

I suggested in my previous post separate fields should be used for the two conflicting purposes. But perhaps using a field for determining program behaviour is a bad idea in the first place. Normally, this sort of thing is done with explicit option settings. In that case, there's no doubt about what the choice is, and what the results will be (i.e., no "reverse engineering" required). Such options may best be based on some file attribute, but that can be done (as it is everywhere else in the program) with an expression. In other words, there should be an option where the user specifies an expression defining files the views for which will use series art, others to define where particular background sources are used, etc. The default for such options might be [Media Sub Type]=[TV Show]. But [Media Sub Type] would then be an unrestricted field used for categorizing as the user sees fit. If "TV Show" is not used or is not adequate to define an option, the user would simply change the expression accordingly.

[glynor]

I notice that there's nothing about Documents/Books here.  Oh why do I even bother?

Doh!  Honestly, Documents were one of the biggest reasons I'd decided to make this post, and then I forgot to include them when I actually did the post itself.  I absolutely need some for Documents, including "Books".  I'm going to add some to my list above.

Yes, and in the Video section, it would also be nice to have Concert-Movie

Good one, adding it to my list.

I, too, prefer to avoid the irritation and do things my own way. But it's getting to the point where it's becoming unavoidable. To continue with the same illustration...If I want my series views to include backgrounds, those views must include files with [Media Sub Type]=[TV Show]. But that also breaks my existing views by arbitrarily using series instead of episode cover art. How's this for ugly?

I've struggled with this quite a bit in designing my own libraries.  I could, of course, manage it something like you described, but I don't want to "fight the system".

So, this is my attempt to improve the system without getting into "ultimate felixibility".  In other words, I'm trying very hard to avoid having the perfect become the enemy of the good.

I just want something that works now, without rethinking the whole system.

[rick.ca]

So, this is my attempt to improve the system without getting into "ultimate felixibility".

I understand your intent, but the system in this respect is fundamentally flawed, and attempts to improve it will only make it worse. What I've suggested is not part of some quest for "ultimate flexibility," but for the purpose of removing an unnecessary and troublesome restraint.

I just want something that works now, without rethinking the whole system.

Then surely the answer is to use a custom [Media Category] field. Don't "fight the system"—stop using a lock-down system field to categorize media according to your personal needs.

These repeated complaints and requests to add more categories are perpetuating the myth the program is deficient and somehow preventing users from categorizing media according to their preferences and needs. That phenomenon alone is enough to suggest the attempt to use one field for two inherently conflicting purposes should be abandoned. The original justification was probably that it would make things easier to understand and use. Nothing could be further from the truth. It doesn't work, and users are understandably confused.

As it stands now, the technical issue is almost too trivial to warrant discussion—except to dispel confusion about how the program works. My concern is ongoing development continues to use the field in this manner, resulting in an exponential increase in real problems and confusion. The TV Show-related issues I pointed out may be considered obscure and trivial. But imagine a fully automatic system that imports, retrieves meta data and tags media—but only for media categorized exactly as JRiver thinks it should be. For a media manager that offers such power and flexibility, that just doesn't make any sense.

[666JackTheKnife666]

The [Media Sub Type] field has always been a gripe / shove my head through my monitor irritation / feature  for me.
This may be a stupid suggestion but what about MC getting a new "stock" field that is user extendable. [Media Sub Classification] works for me but the name could be anything that is logical.
Yes you could do a custom field for the same thing, but if this field came "stock" it would be safe to use in your tags, in case of some catastrophe with
the software/hardware and you had to rebuild your library and collection.

Am i off my rocker or wouldn't this solve 99% of our problems with [Media Sub Type] ?

[rpalmer68]

The [Media Sub Type] field has always been a gripe / shove my head through my monitor irritation / feature  for me.
This may be a stupid suggestion but what about MC getting a new "stock" field that is user extendable. [Media Sub Classification] works for me but the name could be anything that is logical.
Yes you could do a custom field for the same thing, but if this field came "stock" it would be safe to use in your tags, in case of some catastrophe with
the software/hardware and you had to rebuild your library and collection.

Am i off my rocker or wouldn't this solve 99% of our problems with [Media Sub Type] ?

I created a [Video Classification] field when I first started using MC and use that as my [Media Sub Type]

As has been pointed out Theater View changes its behaviour depending on the [Media Sub Type] field, for example "Play" & "Play All" are there for some tyes and just "Watch" for others, so best to just leave it alone and use a different field in my opinion.

R

[rick.ca]

Am i off my rocker or wouldn't this solve 99% of our problems with [Media Sub Type] ?

It makes no difference. Either [Media Sub Type] or a new (stock or custom) [Media Classification] field will be written to a file tag (for files that support tags) if configured to do so. The only catastrophe that would be help you recover from, however, is the one that destroys your library and library backup, but not your media. Your first line of defence should be library backup.

File tags are also useful if the same media is used in other applications or external devices, but I doubt any of those could or would need to use [Media Sub Type]. Some might be able to use a [Media Classification] field, but it wouldn't matter whether it was a stock or custom field in MC.

[MrHaugen]

I like to only have one Media Sub Type field. I've used to use "Video Type" before, but it's nice to just have one field to base such views on. It's also less confusing for uses I would think. So, I'll have to say that I would like a few more types in Media Sub Type field, even though it might be flawed.

If you get the most commonly used once, there will only be a few people left that have to use custom fields. It's better than the alternatives imo.

[glynor]

I like to only have one Media Sub Type field. I've used to use "Video Type" before, but it's nice to just have one field to base such views on. It's also less confusing for uses I would think. So, I'll have to say that I would like a few more types in Media Sub Type field, even though it might be flawed.

If you get the most commonly used once, there will only be a few people left that have to use custom fields. It's better than the alternatives imo.

This is exactly my thinking.

The system isn't broken.  It just isn't flexible enough for many people.  With some additional values in the list, I'd be able to just use it and not have to worry about maintaining two fields (because [Media Sub Type] is used by many things in MC, like the new metadata lookup system, so you have to fill it correctly too).

Some of us, of course, are never going to be satisfied with what they add.  In that case, yes, create your own field.  I think I can be satisfied though, with just a few additions.

Also, by the way...

If what I'm asking for up top is "too much" for the field (I can't see why, but just in case), I could manage with a subset of those by using [Media Sub Type]=Other and then [Genre]=Documentary (or Concert, or Comedy, or Stock, etc).  In fact, that's what I've done already for some of my files.  But this is ugly, and it ends up that huge swaths of my files are all set to "Other" (which seems to defeat the point of having the category in the first place) and then I have trouble using the Rename, Move, and Copy files tool the way I want (which is for the whole library to be organized by [Media Type]\[Media Sub Type]).

But, like I said, I could make do in some of those places.  However, I really CAN'T make do without additions like Photos, Music, Books, and the others that are really "top tier" needs.  I don't see why it needs to be quite so limited though.  You don't want the list to get out of control... I can see that (it would make tagging a pain if there were 45 values to choose from).  But this seems like a reasonable list that will fill most common needs without adding too much to the value list.

[rick.ca]

The system isn't broken.  It just isn't flexible enough for many people...

The fact that so many are complaining about it suggests it doesn't work. There's no way a fixed set of categories is going satisfy most users—any more than a fixed set of fields would. The program is designed to be flexible. Including a fixed set of values for categorization is completely inconsistent with that design objective.

But what I really don't understand is your objection to a completely open field, the sole purpose of which is to categorize media. Who cares if the existing [Media Sub Type] is restricted to values used for internal purposes? You want to use the field for a different purpose just because the name of it implies it should be suitable? I don't get it.

Imagine if from the beginning [Media Sub Type] were restricted to values used elsewhere in the program. That there was an unrestricted [Media Classification] field—populated with values used in stock views and other useful terms. Would this discussion be taking place? Would people be complaining a locked-down [Media Sub Type] is preventing them from doing what they want to do? Would you be suggesting the redundancy in the nature of two fields was intolerable and they should be consolidated? I think not.

[JustinChase]

avoid having the perfect become the enemy of the good.

I just want something that works now, without rethinking the whole system.

I agree, and would much prefer glynors few additions, and continued internal functionality benefits in a week, than the entire rewrite in a couple of months

[MrHaugen]

But what I really don't understand is your objection to a completely open field, the sole purpose of which is to categorize media. Who cares if the existing [Media Sub Type] is restricted to values used for internal purposes? You want to use the field for a different purpose just because the name of it implies it should be suitable? I don't get it.

I'll give it a go.
- Two fields to do pretty much the same thing. Unnecessary complicated
- Harder to explain to, and use for new users (yes, you WOULD actually need to change Media Sub Type now and then. Carnac is not all knowing)
- The Media Sub Type field today would suite most people with a few more additions like Glynor pointed out
- For those that STILL have special needs, they have the option to add custom fields. But most people don't have to have two fields to focus on

And as an answer to the last question. No. I do not think people would complain about locked down field. But I'll be that there would be lots of posts explaining what both fields does. When you have to change one of them or both. I do not think it would be much better to be frank.

[rick.ca]

Two fields to do pretty much the same thing. Unnecessary complicated

As I've explained, this erroneous assumption is what's causing all the confusion and complaints. I've also explained why and how the status quo is unnecessarily complicated and confusing.

Harder to explain to, and use for new users (yes, you WOULD actually need to change Media Sub Type now and then. Carnac is not all knowing)

So burying values set (possibly incorrectly) by Carnac among even more values just used for classification is going to help? Surely it would be much clearer, easier to explain and troubleshoot if such values were restricted to one field of their own (or eliminated altogether and included in Options where they belong). It would then be clear those values are the ones affecting behaviour and outcomes elsewhere it the program, and may be set by Carnac. Conversely, it would be clear values in the other field are used only for categorization and can be set to any value desired—without concern of messing up some other program function. Users would have the choice of continuing to use specific [Media Sub Type] values, repeating them in the other field (just for the sake of completeness) or leaving it alone and categorizing it differently in the other field.

The Media Sub Type field today would suite most people with a few more additions like Glynor pointed out

You and others keep saying that—without justification and in the face of regular posts about the issue. Many have suggested "if just a few values were added, I'd be happy," yet none of them agree on what those additions should be. It's complete waste of time, considering there's no justification for restricting values for categorization in the first place.

For those that STILL have special needs, they have the option to add custom fields. But most people don't have to have two fields to focus on

Yes, there are no obstacles to deploying the other field I'm referring to as a custom field. That's not a justification for adding more arbitrary values to [Media Sub Type]. On the contrary, it underlines the absurdity of doing something that's unlikely to be a complete solution for anyone and will perpetuate confusion about how the program works.

But I'll be that there would be lots of posts explaining what both fields does.

I'm sure there would still be questions, but those questions would be a lot easier to answer. As it is now, it seems [Media Sub Type] is the field that should be used to sub-categorize media—particularly video—but it doesn't allow the values people want to use. If more values are added, but still don't include the values needed, it will be that much more difficult to explain the only solution is to add a custom field. To someone who just needs one more value, the suggestion seems absurd. That's why there are so many requests to add values or unlock the field.

But as I tried to explain in my first post, this is not just a trivial preference. The two purposes of this field are fundamentally at odds. To illustrate, let's say you're satisfied with how series are handled and presented in Theatre View—as results for files tagged [Media Sub Type]=[TV Show]. In your mind, however, there are three types of TV series: Sports, Documentaries and Shows. You understandably expect these values to be available in [Media Sub Type]. Oops! You can't do that. To be handled as series, all those files must be tagged with as TV Shows.

Yes, there are other reasonably straightforward ways to get the desired result. But this design has probably done a good job of messing with your head. Your expectation this field is what should be used to categorize things—given it's name and the list of values it offers—is a perfectly reasonable one. But you're probably not even aware of the special function of the TV Show category, and therefore don't understand why you can't use other values or even find the one's you would like to use. By the time you realize it's a dead end, you're too frustrated to see the simple solution of ignoring the field and categorizing exactly as you want by other means (of which there are many).

[glynor]

Many have suggested "if just a few values were added, I'd be happy," yet none of them agree on what those additions should be.

A bunch of us agree on these.

considering there's no justification for restricting values for categorization in the first place.

You assume.
I suspect they have their reasons.

[JustinChase]

...you're too frustrated to see the simple solution of ignoring the field and categorizing exactly as you want by other means (of which there are many).

I'm sorry, but your constant assumption that everything would be much better if everyone could just recreate the wheel EXACTLY they way they want is just mistaken.  It's not the best way to write a program for the masses.  It's probably the best way to write a program for the .01% of geeks that know how to write nested expressions, but that's not who's most likely to use this program.

JRiver needs to balance customization with user-friendliness, and taking away this field to replace it with "whatever I want" isn't going to help new users.

Being more customizable would be welcome, but it's not the ONLY way to improve what currently exists.

[rick.ca]

A bunch of us agree on these.

So what? A bunch of us don't.

You assume.
I suspect they have their reasons.

I assumed nothing with respect to that statement, and I stand by it. The idea of restricting values for categorization in an application like this is absurd. There are reasons for controlling the use of those values that determine how various program functions work. I believe that control should be tightened by restricting this field to only such items. Some values might be used currently in the construction of some stock views (I'm not sure—I don't use them). Those would be better put in a separate, unrestricted field as stock values. Stock views would still be fully supported, and would be much easier to modify to accommodate any particular need.

I'm sorry, but your constant assumption that everything would be much better if everyone could just recreate the wheel EXACTLY they way they want is just mistaken...

Please don't say your sorry and claim I'm making some "constant assumption" only relevant to a lunatic geek. If you want to disagree with me, disagree. The civil way to do that is to consider what I've said and respond. The only reason I'm commenting on this is it's obvious the current state of affairs is causing confusion—and it therefore not user-friendly. I've gone to the trouble to try to identify the problem and to suggest solutions. I don't expect my analysis is complete or my suggestions necessarily optimal, but at least I've made an honest attempt. You have not. All you've said is I don't know what I'm taking about (you're wrong) and there is some better better solution—but you won't tell us what that is.

[JustinChase]

Please don't say your sorry and claim I'm making some "constant assumption" only relevant to a lunatic geek. If you want to disagree with me, disagree. The civil way to do that is to consider what I've said and respond. The only reason I'm commenting on this is it's obvious the current state of affairs is causing confusion—and it therefore not user-friendly. I've gone to the trouble to try to identify the problem and to suggest solutions. I don't expect my analysis is complete or my suggestions necessarily optimal, but at least I've made an honest attempt. You have not. All you've said is I don't know what I'm taking about (you're wrong) and there is some better better solution—but you won't tell us what that is.

I did read, understand, and evaluate what you said, but I disagree.  I thought I was quite civil about it ("lunatic" is your word, not mine).  I already said my peace regarding this topic, several posts earlier.  The current system is not perfect, but I feel that some of the additions suggested by Glynor and others would be a better solution for improvement quickly, vs. removing the system altogether to allow everyone to individually re-create the wheel exactly they they want it; considering most users are unlikely to even consider to possibilities and take the time to create any system.  Not to mention the time it would likely take JRiver to make the changes you suggest.

I used the term "constant assumption" in regards to virtually every 'argument' you present on these forums in which you explain in great detail how the current system is flawed, and allowing total user control is the 'best' way to resolve whatever topic is being discussed.  i.e. you assume constantly that people should be smart enough to figure out a better way all on their own, if they just had more control/less restriction.  I disagree with this "constant assumption" that this is always the best way.  It's a great way for the geeks (like me) that want to learn and tinker and have full control.  I've also constantly stated I feel more control/option is better, but not at the expense of 'user friendliness.'

Red October is a good example of JRiver taking control and making it work.  The old system was an example of giving (mostly) full control, and it was a bit of a nightmare.

Anyway, it wasn't a personal attack on you, it was just a disagreement with your general philosophy regarding how JRiver should spend their limited development time.  I'm sorry I didn't flush it out a bit more, I was sitting in an airport, writing it on my phone.

There is no need for you to respond to this, I'm well aware of how you feel about this

[pcstockton]

it is strange to me that Glynor and Rick.ca are always brawling.  You two are some of the MOST valuable people on this forum.  How are you guys not buddies?!?!?!?

Smoochers,
Patrick

[glynor]

it is strange to me that Glynor and Rick.ca are always brawling.

I wasn't brawling.  I'm just trying to get myself some new sub types.

Generically, I agree with Rick.  I've asked for that field to be opened up to user-created values often in the past.  These conversations have been going on a long time.  For whatever reason, that's not how they've decided to architect the system.  I don't know all the reasons why.  Maybe there is a "deeper reason".  Maybe it is for user friendliness?  Or performance?  Or Jim wants to irritate people with a touch of Jobsian control?  Or, maybe it's just that it would be a "pain in the butt" because of some structural decision that was made long, long ago, and it just hasn't been worth it for them to re-write the system to please a few power users.

I don't know.  I don't really care.  I'm just trying to get myself some new sub types.  

[vairulez]

an Anime sub-type would also be geat

[rick.ca]

Anyway, it wasn't a personal attack on you, it was just a disagreement with your general philosophy regarding how JRiver should spend their limited development time.

Out of all the possible solutions, the easiest and most efficient from a development and support point-of-view would be to remove the values that are serving no purpose. They would then be in a position to advise users this field is primarily for internal purposes and, if needed, a custom field may be used for any additional categorization that may be required.

[Daydream]

Please don't forget about porn. 

In true JRiver spirit to give names to features, and to be less conspicuous to common folks, it'll be called the JesseJane media subtype.

For what is worth I'm inclining to agree with rick, since any less than making the field open it's just something between a stop-gap solution and patchwork. It won't solve the problem for good, and spoon-fed solutions are not something I appreciate the most.

What I'm really worried about is if Media Sub Type is tied into a bigger picture (hence the resistance to change its type).

[struct]

adult is a sub-type already.  this may say more about the average mc user than we like to admit

[MrHaugen]

I don't know.  I don't really care.  I'm just trying to get myself some new sub types.  

Exactly. That's where I am as well. I would like the Media Sub Type to be open like everyone else (except for JRiver perhaps), but I'm tired of the fight. And it's not the MOST important fight to fight, so I give up.

I, and others, could of course just add a Classification field to the equation. I already have this field. But I want to get rid of it! If it's more complicated for me though... I assume it's also somewhat complicated for some other MC newbies, if this was enabled as default.

[JimH]

Time out.

[Matt]

Media Type and Media Sub Type use a fixed list of values that the program understands.

This is important, especially in video.  For example, the program needs to know when a file is a TV show so that it can show the file in views that are useful for television, can get Theater View backdrops specific to television, can automatically get television series artwork, etc.  If we allowed users to use any text they might like for these files instead of just "TV Show", it would be difficult or impossible for the program to have the handling that's required for a good user experience.

The original request was to add a few more choices to Media Sub Type, which is reasonable in my opinion.

There will be some contingent of users that want complete flexibility.  For these users, consider using Keywords, Genre, or custom fields.  Media Center is unparalleled in its support for flexible custom fields and views for the users that want more control.  Media Sub Type is not the field for this flexibility.