Print

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

[locust]

Is there any chance we can have Documentary and Educational included in the media sub type..

I don't like listing my documentaries under tv shows. And I have a fair few educational videos that aren't akin to documentaries.. They are more geared towards tutorials, e.g. Juggling, Devil Sticking e.t.c..

Thanks

[beginner44]

I second that request.

It's crazy we cannot add new values for media subtypes ourselves, wherease we can for music genre tag.

Many thanks in advance for considering this request

[JustinChase]

I believe it's "locked down" because some of the media subtypes cause MC to handle the media in special/different ways.  i.e. TV shows pull from TVDB, and Movies pull from TMDb.  I believe the media is presented/handled differently in actual usage also, "Watch" for TV shows, and "Play" for others.

However, adding more, or the ability for us to add more doesn't mean this special handling needs to be removed/eliminated, IMO.

Any new additions can just be handled like "Other" is handled now.

I would also like to see Documentary added.  Education doesn't interest me, but I have no problem with it being added either.

I think Glynor wrote a post awhile back with his suggestions; but it may have been on the Beta board.

RE: Documentaries.  Some are "TV shows" and some are "Movies", so forcing me to choose one is not intuitive, IMO.  Letting Documentaries pull from both TMDb and TVDb would be very helpful.

Hopefully it can be changed, as I agree it would be good.

[glynor]

The ones I want more than anything are Books and Photos, but I'd also like Documentaries and Educational (or something equivalent).

It was on the public board, I think, but I also think it went to 4 pages and eventually got locked.

[rick.ca]

It was on the public board, I think, but I also think it went to 4 pages and eventually got locked.

It's so sad it won't stay that way.

If it's an issue, do this: Add a custom field [Media My Type] for setting whatever media classification value you please. Create an expression field [Media Super Type] = If(IsEmpty([Media Sub Type]), If(IsEmpty([Media My Type]), , [Media My Type]), [Media Sub Type]). Use [Media Super Type] in views and rules wherever you would otherwise use [Media Sub Type]. Be happy with your very own, completely unrestricted media classification system that can't even be messed-up by JRiver some day guessing what values you're using and adding them to [Media Sub Type].

If this goes to 4 pages, please remember I offered a complete solution plus witty commentary in just 4 sentences.

[JustinChase]

Or, write you very own fully functional media player, exactly the way you want.  Why even use what JRiver has provided, everyone can program everything they need.  How silly to ask the company that makes the product to make changes when you can just create your very own software.  We all have time for that.

Great idea!  Every time a request comes up, just ignore it and write your very own solution. 

[glynor]

Fight nice, children.

Rick, your solution is nice, and clever.  And I've thought about implementing essentially the same thing often.  Whenever I'm frustrated by the existing system (which just happened to be this weekend, and then here was this thread).

The main problem for me with that system is not in displaying or using the metadata simply to construct views (which your solution solves beautifully).  It is that it would require me to use a certain tag for some kinds files, and another tag for other kinds of files, when applying the tags and creating the metadata structure.

The task of tagging is something I do far more often than designing views, and with far less enthusiasm, if you know what I mean.  I prefer to build metadata systems that are both simple to use and efficient to apply.  That generally, makes them also simple to understand.

To use that, I'd have to have special views for tagging these [Media Sub Type]=Blank files, and separate schemes to tag the [Media Custom Type] ones (or whatever suggestions you gave for the custom tag names).  I can't do it all in one pane, in one view.  If I'm using the Columns or Tag AW to add tags, I have to show both (or again, make special "column setups" for each special type).  If I'm using Pane tagging, then I need either an extra column (which are at a high premium in big tagging-centric views), or a special view custom designed for that "type of file".

So, to be clear, you could make this work, if you were clever and determined (you are, and frankly, so am I when I put my mind to it).  But one of my rules for setting up my organization scheme is this:  Can I explain it to my wife once or twice and have her be able to understand the system well enough to use it and tag files herself properly.  I try not to design any system that requires me, above all else.  Because if it requires you, then it is only your job.  And that job is often annoying.  Even if she doesn't do it often, and messes it up a little when she does, every little bit helps (and it keeps her involved which helps with future WAF).  Plus, sometimes I tag files when I've had too much wine.*

So, I try to stick to the assigned Media Sub Types as much as is possible.  They're required, so I have to use them.  I don't want to use something else as an adjunct, because then I have two separate tags to worry about when applying tags.

* See what I did there, Rick.   

[glynor]

I should add.  That's essentially what I'm doing now, without the fancy expression for display trick.  I'm basically using [Media Sub Type]=Other as a stand in for your fancier IsEmpty-styled system, and then the [Genre] tag as a separate "categorization" level for these files.

So, for example, I have some "Instructional" videos (tutorial videos and baby videos mostly).  I set these to [Media Sub Type]=Other and [Genre]=Instructional.  This works well for some similar video types.  I just have one "Other" view in Theater View, that filters on Media Sub Type Other and then shows the Genres below.  There aren't that many different Genres, nor that many (relatively) files within, and I don't "acquire new content" as often, so it isn't much bother to deal with.

I'm using a similar system for Documentaries now.  Instead of using [Media Sub Type]=Other for these, I just use whatever makes the most sense for that particular piece of Media (Does it show up in thetvdb or tmdb?  Does it really have a clear "series title" and separate episdoes? Etc.)  This allows me to design my Documentaries views to show both TV Shows and Movies together, and doesn't force me to categorize them one way or the other.  I just filter [Genre]=Documentary (which is often included for appropriate moves automatically from tmdb too, so they show up by themselves).  This also works well with MC's auto-categorization feature, which works pretty well when you don't fight it.

So, my Documentaries view under Theater View can show both Movies and TV Shows.  Nice, but it doesn't work quite as well with navigating through Theater View.  Because those "movies" don't have a [Series] tag, but I want that included as a category in the View for the ones that do, they get grouped together under "Unassigned".  That makes them harder to "discover" when you're browsing around looking for something to watch, and I don't like that (so I waffle back and forth on this, and maybe being more clever about it).  But, in any case, it doesn't help with "bigger level problems".

For example, my Images system has always been a mess.  I've resorted mostly to using my Main MC library only for my "personal" images, and having separate libraries for other kinds of "professional use" imagery and whatnot, but switching back and forth between libraries has its own set of problems.  But even still, it is a mishmash of different "kinds" of images.  Photos.  Desktop Wallpapers.  Screenshots.  Graphics files.  Dumb web comics I've saved.  Images for my site. Images for work.  Logos. Etc...  All of those could work as [Media Sub Type]=Other.  But mostly I have Photos.  Lots and lots of photos, and a few other things.  Photos isn't a Media Sub Type though.  But do I set [Media Sub Type] to Other and then use Genre for "Photos"?  That's absurd.  Or do I use a whole different Field to categorize images?  But then I have to remember the system 3 years from now, and why it was the way it was, and explain it to my wife and eventually my kid, and set up a few custom schemes (in triplicate: for Theater, Standard, and Web API viewers) to "hide" the complexity of the system.*

So, instead, I've mostly done nothing.  I have a mess, filtered mostly by pathname and occasional brute force [Media Sub Type] or [Genre] on things that slip through.  But it is clunky and inelegant, and it forces me to have a weird folder structure that gets cluttered and disorganized quickly and which is difficult to manage.  And, it means that really I'm the only one who can get that errant screen shot I took on my iPad out of the "Photos" view in MC.  The same story with storing Manuals and eBooks in MC.

So that's why I said I want those the most.  Media Sub Type Other (or blank) with a separate "related" Field works as a good solution when the files in question don't make up a substantial portion of the total files in Library, but when you have a bunch of them, it starts to creak around the edges.

* I should really just give up and make my own [Document Type] and [Image Type] fields and be done with it, but I've been holding out hope that [Media Sub Type] will get better.  I don't really have that many things that I want at the sub type "level" (and I don't use a bunch already there), so the total list wouldn't be that long, so why use separate fields.  And then, you know, lazy.

[rjm]

I find it a little troubling that several reasonable proposals over the years have been met with silence from JRiver. It would be easier to accept if we knew there was a reason.

[rick.ca]

* See what I did there, Rick.

Uh, a wine/whine pun? Maybe you need to explain it to me.

It seems you're putting a lot of energy into making an issue out of nothing. I have no idea why JRiver feels the need to restrict the field or believes those who want to use it for their own purposes can be satisfied by the occasional adding of allowable values. If the need to restrict the field is valid, then it follows it should be restricted to just those values used by the program (e.g., for things like 'TV Show'—so the program can tag a file as such on import, then use it to determine a meta data source and how the file is displayed in views). Doing otherwise only invites confusion. If it were always restricted that way, and something like what I've suggested provided as stock fields, there would never have been any controversy about this.

While I don't understand why the problem was created, it's obvious it's not going to be changed. Refusing to accept that and perpetually complaining of harm when such a simple solution exists is irrational. As some are wont to demonstrate, this can manifest as full-blown insanity. Intentionally suffering because something is not exactly the way you think it should be—what else could that be? And don't think I'm going to let you off the hook after you've attempted to project the issue onto your delightful wife. Haven't you heard? Women are smarter than us. When it comes to common sense, they're way ahead. Wake up—she's humouring you!

I should add.

Of course you should. We're no way near 4 pages yet.

I should really just give up and make my own [Document Type] and [Image Type] fields and be done with it, but I've been holding out hope that [Media Sub Type] will get better.

I think what I've already said applies to your second post. All of your perceived difficulties, inconveniences, or whatever are caused by the assumption JRiver's needs and yours should be satisfied by the same field. Maybe it should, but they're not allowing it to be so—after many requests. As rjm says, it would be easier to accept if we understood the reason. But that doesn't change the fact we have no choice but to accept it.

BTW, I don't use the solution I've suggested—because I don't have the problem. If I have any problem, it's sort of the opposite. I have to take extra care to ensure my episodes are not tagged as 'TV Show' because I don't like they way they're then handled in Theatre View. Other than that, I find any necessary distinction of media type is already clearly defined by other attributes—primarily the folder the folders the files are in. I prefer to refer to those attributes directly, rather than burden myself with some arbitrary and likely redundant notion of 'Media Sub Type'.

There's a final, more general point I'd like to make. Clearly, an application like this must impose some degree of organization. Genre-Artist-Album for music and Series-Season-Episode for series, for example. But since some structure is necessarily provided, many seem to think JRiver should be fully responsible for how their personal media collection is organized. That's not the case. It's a personal database, and there's no one right way to organize any media managed by it. Beyond a basic structure, it's completely up to the user to decide what fields to use (including adding their own), the criteria for assigning consistent and meaningful values to those fields, and how they're to be used in the organization and presentation of the collection. So, your images, for example...[Media Sub Type] has nothing to do with how they're organized. That's up to you. Given the diversity of image types, the best organization would probably use more than one field to classify them by type (e.g., [Image Type] and [Image Sub Type]).

[darichman]

At the risk of being utterly unhelpful, I don't use [Media Subtype] at all, beyond making sure series are series and movies are movies... and the only reason I do this is so that metadata lookups work - if you reduce it to this, it's just an artificial requirement of the program (ie not integral in views, tagging or searches).

I find using custom fields is much more useful.

[rick.ca]

At the risk of being utterly unhelpful...

It never hurts to use fewer words than glynor and I do.

[Matt]

We occasionally add additional logical choices to Media Sub Type.

But if you want a fully flexible field, you should create a user field other than Media Sub Type.  Media Sub Type is somewhat rigid out of necessity (just as Media Type can't be Music or Banana instead of Audio, Images, etc.).

Oh, and IBTL.

[MM_switcher]

Nothing to really add here, but when I have a look at the latest release 170.0.182, in the changelog I can read the line: "3. Fixed: WebGizmo playback was not working in some cases.", wich obviously might be related to my issue here: http://yabb.jriver.com/interact/index.php?topic=73167.msg496017#msg496017

IMHO it's a great job the guys do in fixing issues and enhancing functionality constantly; much more than can be expected and is usually done with other SW you can buy. We all should more acknowledge what they are doing, and not focuse and waste time on the things that are rejected.

Just my five cents.

[glynor]

Oh, and IBTL.

 

If you're feeling generous, here's what I'd really, really like:

Top Priority:
Photos
Music
Books

Without these (above) it is very difficult to use the system as-is without using a secondary adjunct field.  They just seem to "make sense" that they'd be available.  I'd basically like to use the Auto-Import Tag On Import rule to auto-tag most incoming music as [Media Sub Type]=Music and incoming pictures (in a place where photos would typically show) as [Media Sub Type]=Photos, and then manually change them to "Other" when necessary to exclude your occasional screenshot or Voice Memo that ends up in my library imported from a mobile device.

Lower Priority:

We had a list before, but these seemed to be the big ones:

Educational (or Instructional or something that would include a recorded class, tutorial, or "instructional" video of many kinds)
Documentary
Concert (or something that would cover live concert videos and audio)
Documentation (for manuals and whatnot)

These (and some of the others from the older threads) would be convenient.  However, if the user has a TON of these categories, I've come around to the idea that they are better off using [Media Sub Type]=Other/Blank and an adjunct field to further categorize them (I like [Genre] because it is standard and gets auto-filled for some media types, but to each their own).

Where I'd like to be able to use the [Media Sub Type] system that I can't is on those (previously listed) "big categories" that make up the lion's share of my library.  It is frustrating that I can categorize a Video as a TV Show or Movie, and an Audio File as an Audiobook or Podcast, but I can't categorize an audio file as... you know, Music, or an image file as a Photo.

Basically, I want to be able to use this kind of "file naming" scheme: [Media Type]\[Media Sub Type]\etc, and a similar kind of filtering scheme in many of my Views.

Right now, I can't (easily) because for the vast majority of my audio and image files, [Media Sub Type] is BLANK.
But I have to use [Media Sub Type] for Audio files and Video files to capture the special behavior of Podcasts, Audiobooks, and the rest.  So, I'm stuck, unless I go the route suggested by Rick.

So, I'm not so concerned (anymore) with covering the types like Documentary and Instructional, that can be pretty easily solved by using [Genre] or a custom field.  However, it doesn't make sense that we have Radio, Remix, Podcast, and Karaoke and not MUSIC.

[glynor]

Uh, a wine/whine pun? Maybe you need to explain it to me.

You picked on me once (rightfully, probably, though obliquely) in some other conversation that the features of the program shouldn't have to be designed around people who insist on tagging things drunkenly. 

[Matt]

Photos
Music

Interesting.

I've always thought of those as implied, but I suppose in a Pane View it could be useful.

But I'm not real excited about tagging every song I have with 'Music'.

[JustinChase]

The last big thread that discussed this had some really good/useful ideas and explanations of those ideas.  It might be good to review that for more detail in some of this.

I am of the opinion that the [Media Sub Type] is/should only be for types that need/benefit from special processing.  TV Show forces MC to change the display of "play" to "watch", and forces metadata lookup from TVDb, and Movie forces lookup from TMDb.

MC basically requires you to use these fields to get the benefits of the automatic lookup.  Any advanced methods to work around this will negate this feature.  It's not a real solution for MOST people.  It might 'work' for those that like spending all their free time programming, but that's not the average MC customer.

Documentary could be added, and it's special processing would be to lookup metadata from both databases.

Concerts could do the same, though I think they are usually in TMDb.

Music and Photos are good ideas, for completeness sake, but I'm not sure what special processing they need, or would get from this field.

Remix and Karaoke seem totally out of place to me.  What is a "Remix", and why does it deserve to be there?  Radio and Podcast and Audiobook all make sense, since they can/should be handled differently.

"Extras" could be added here, and it's special feature is that it gets tied into the movie or show it relates to, and can offer these extras more 'automatically' in Theater View for example.  I basically use "Short" for this, because I dont' know what "Short" is 'supposed' to mean/be used for.

I don't have MC running here to see what else there is currently, but the general idea is the same.  If a media subtype can/should benefit from being special, it should be in the list.

Perhaps a new library field type is in order.  Includes 'mandatory' items that cannot be deleted or changed, but allows other types to be user entered/modified.  Perhaps a hybrid field that pulls from 2 other fields, one being locked by MC, the other editable, but combined and shown as a third/separate field.   It would solve a lot of issues mentioned here, while still maintaining MC integrity of required entries.

[JustinChase]

But I'm not real excited about tagging every song I have with 'Music'.

It's not very difficult to do; I can walk you thru it if you like 

[glynor]

But I'm not real excited about tagging every song I have with 'Music'.

It wasn't even really an option to do it that way until we had Tag on Import, so then Unassigned = Music, or Unassigned = Photo, made some kind of sense.

But when you have a substantial library of non-Photo (not personal photos, anyway) or non-Music (Audiobooks, in my case) items then it starts to creak around the edges.

[rick.ca]

Since we're playing the IBTL game, and glynor hasn't even managed to get us to page 2, I'll fill a little space by reiterating the obvious...

This field should be restricted to values the program uses to determine certain actions and behaviours. Doing so would make it more meaningful and less ambiguous in two ways: (1) Even if the consequences are unknown, the existence of an allowed value tells the user there is something the program does for files fitting this type. Generally, it should not be ignored unless one knows what that something is and that it's either not applicable or unwanted. (2) Conversely, the absence of any values fitting the file in question means there are no special actions for it, and the user is free to classify it in any way and by whatever means they choose.

That useful distinction is made more obscure every time an unnecessary value is added. That makes it more difficult to use and more prone to error. It forces the developers to make even more obscure and arbitrary choices. For example, is a documentary TV series a Documentary or a TV Series? If 'Documentary' (and other such irrelevant values) is not available, the choice is unambiguous: The file is a 'TV Show'. It's further classification as a 'Documentary' will have to be done by other means.

Yes, that means two fields for which the classification role is the same, and then relevant view configuration are likely to require referencing both fields to determine how the files are presented. That may not be a big deal for some (e.g., I don't use any additional 'media sub type' values). If it is, there is the option of using an expression field to combine the two. That has the advantage of providing the means to use any logic necessary to combine the two (i.e., add, override, default) or even determine a value based on other criteria—obviating the need to tag the second field. In a well designed library, it's not difficult to imagine Tag on import and the expression field reducing manual tagging to rare exceptions.

It's clear to me this the way it 'should' be done. I also understand making any changes presents a dilemma. Since many users are relying on the way it is now, any change is potentially disruptive. But I think there are two viable options...

• By introducing additional values that are not used internally, the damage has been done. There's no longer any benefit to restricting the values used in [Media Sub Type]. Make it so the internally used values cannot be removed and are distinguished from the other 'user' values (leave them at the top of the list; highlight them; add tootips that describe how they're used). Allow any value to be added to the list of allowed values.
  
  
• Replace [Media Sub Type] with something like the two field plus expression field solution I've suggested, along with code that automatically updates existing data to the new format. In doing so, name the resulting expression field [Media Sub Type] so no further changes will be necessary to user's views, etc. Allow the expression field to be modified (or at least the expression itself), so the user can modify the stock expression—possibly adding logic for determining values automatically from other file attributes.

[glynor]

Agreed, Rick.  #2 in particular (related fields, where changing one changes both) would be the most elegant solution.

[beginner44]

Wow, I didn't think I would trigger so many inputs on this subject !

I thank you all for these information, I will need some time to go through, but I'm sure I will find what I was looking for.

Cheers,