Print

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

[wer]

There is currently a very limited amount of customization a user can do to the built-in (stock) fields.  Hence the "Revert all changes to stock fields" button.

What's the view on allowing a stock field to be change to type "Calculated data"?

I'm lazy when it comes to tagging: I don't like to type in a bunch of stuff that I don't have to.  Which means if I can figure out a way to calculate something from something else, that's how I want to do it.

Case in point: there are stock fields for Movement, and Movement Number.  If you have good systematized naming, those fields can be calculated from [Name] with no extra effort.  But only if they are calculated data.  Right now, you can change a predefined field to Calculated Data, and it works, but the change is lost the next time you start MC. Switching it to Calculated Data is not persistent. (I should mention this was true up until the recent change where Matt corrected the bug where some stock fields were incorrectly listed as user fields- after this fix, you can't change them to calculated data at all.)

This means we have to invent new fields (Movement Name, Movement #) to supersede perfectly good field names that already exist.

Since the sky does not fall when I change the type, I see no obvious harm in allowing these changes to be made.

What would you all think of this?

[glynor]

While I don't have any particular issue with this (nor any opinion on it myself), I will note that JRiver folks are loathe to allow changes to stock fields and so the overall request is unlikely. From their point of view, it just makes something that should be reliable, possibly unreliable. While your particular use-case doesn't cause issues, you can probably envision some stock-fields and some user-supplied (probably broken and ill-advised) expressions that would cause trouble.

But that wasn't the point of my post, because you probably already know that as well as I do.

The point of my post was to ask you to maybe reconsider your system a little. On this note:

I'm lazy when it comes to tagging: I don't like to type in a bunch of stuff that I don't have to.  Which means if I can figure out a way to calculate something from something else, that's how I want to do it.

Totally, completely 100% agree. However, if you can calculate the [Movement] and [Movement Number] from [Name] then why not fill those fields?

If [Name] is standardized before import, then use a Tag on Import rule and you won't ever have to look at it. If [Name] isn't standardized before import then the simplest thing would be to use Expression Field Value assignments to quickly tag them (I'd assume this is what you are doing now). However, the issue there (I imagine I can hear you saying) that then there are two "data stores" for the same information, and if they don't agree, when which is true?

The alternative is: Actually use the built in fields rather than building your fancy [Name] scheme.

You can still pull this detail out of [Name] with Tag on Import and Expression Field Assignment to get your current data converted. And you can, of course, always make a [Fancy Name] calculated field that rebuilds your current standardized [Name] scheme and use it for display everywhere you currently use [Name] to look at and browse the files (and RMCF and whatnot). So, my question is: Why not actually use the fields as Matt intended, and get that extra crap out of [Name]?

You probably have a good answer that isn't effectively "because I don't like it that way" but I'm curious what it is? I find it is almost always best not to "fight the system" when you can avoid it, because your clever hacks are only ever 1 bug fix away from breaking entirely. I used to, for TV Show episodes (for which I have a ton, and have had for a long, long time), have a complex system for [Name] that encoded various details about the show. But I found over time that I was always having to "fix something" or "tweak something" or "fight something". And, in the end, it was far lazier to stop "fighting the system" and to actually just use or make fields for the individual components that I originally encoded in [Name].

So, I guess I would say my modification (or corollary) to your "lazy tagger rule" (with which I wholeheartedly agree) is my "keep field values as simple as is possible and use separate fields for separate information" rule. This, IMHO, actually helps you to accomplish being lazy more effectively over the long term.

[glynor]

And, in the end, it was far lazier to stop "fighting the system" and to actually just use or make fields for the individual components that I originally encoded in [Name].

Just to be completely clear, in my case, this meant using [Name] only for the "episode title". That meant that in various places throughout my Library I needed to make Expressions to "reconstitute" the "display name" I previously used extensively throughout various places in MC (in Tooltips, Theater View, columns, etc).

However, in the end, I'm very glad I did the work. Because they eventually built the Auto-Metadata Lookup system which would have borked my whole system anyway, and even beyond that, I found that making those "display name" expressions allowed me to customize exactly how I want the content to appear (including formatting) for the use-case at hand, rather than just using [Name] everywhere. So what shows in Theater View can be different from what shows in the Tooltip, based on what "fits" or "works" better for that use, and so on and so forth.

I know you have a very rigorous naming scheme and strategy for Classical music (though, admittedly, I don't know the details because I don't care right now). I'm not suggesting completely reinventing the wheel or anything, but... Maybe try to think of a way to store the details in discreet Fields rather than parsing a "master field".

Like I said, I'm sure you have reasons. But it is always good to check your assumptions.

[leezer3]

I've personally found it easier to rename the display name for many of the stock fields & use my own custom replacements.

[wer]

I'm curious what it is?

Because the movement name and movement number information HAS to be in name. If it were removed from name, the name fields of the 4 tracks that comprise Beethoven's 5th symphony would all be the same, unless you added some other info to make them unique.  The "I. Allegro con brio" is what tells you what track you're listening to.

Oh, you say, just use an expression to display the other fields too.  Except you forget, for the last 10 years you COULDN'T use an expression for now playing in theater view, until I asked for it. MC versions prior to 27, theater view now playing displays Name only, there was no way to also display the other fields.

And then of course there's the minor detail that no other device (no car, no phone, no receiver, no streaming player) supports Movement and Movement Number.  What gets shown on the display of your car is Name.

So the info has to be in Name.

Tag on import is fine if the file data is nicely formatted before you import. It's often not.

[glynor]

Because the movement name and movement number information HAS to be in name. If it were removed from name, the name fields of the 4 tracks that comprise Beethoven's 5th symphony would all be the same, unless you added some other info to make them unique.  The "I. Allegro con brio" is what tells you what track you're listening to.

Totally makes sense. I knew you'd have a reason.

That said, it would be good to be able to customize the playback info everywhere needed inside MC. But that doesn't help when playing the tracks in "substandard" players. 

So, then your only choice is to either do your fancy on-the-fly expression extracting from [Name] or to have two possible "sources of truth". I gotcha.

EDIT:
I will say, if it was me, I'd go the other direction. Instead of trying to parse [Name], I'd fill all the other fields (with individual fields designed to "hold" the various types of information needed), and then I'd have an Expression in my text file to use to =Expression the [Name] field manually as the last step when I was doing my tagging of the tracks (which, if you are very fancy, could get done via Tag on Import). Easy enough to make that a Calculated Field so that all you have to do to "manually update [Name]" would be to do =[Classical Name Generator].

Yes, you'd have to accept that you'd have to remember to re-do this or the information in [Name] could get stale. But... Meh. That would be worth it to me for the other benefits, especially since I'd only ever really see [Name] when using one of those "inferior players".

But, that's me.

[wer]

But, that's me.

Fair enough. I think it's easier to go the other way, for exactly the reasons you described.

Plus, there's the kicker.  A lot of online metadata (Name) is already in the form  Composition:Track specific info

With that colon in between. It's quite common, I find. It sometimes needs a bit of cleaning up, but sometimes it doesn't.   So since a lot of tracks I rip already have data in that format, for those I have to go to zero or very little effort.

[glynor]

Note: You could do that auto-parsing AND fill [Name] with Tag on Import. They're executed in the order specified in Auto-Import settings. For any that match, it would be just as automatic.

You could even have it "flag" any files that don't seem to match your expected Regex (if you're clever with Regex) that don't contain the expected colon so that you could have a queue of files to check over manually. You'd just need to write to a "checkbox" type field (or assign a [Keyword] or whatever) if the auto-parsing doesn't get what it expects out of [Name].

Not saying it is the right way to go for you. But, just thinking of how to maybe do what you need to do with the tools we already have.

[Doof]

To piggyback on this topic, I would absolutely love it if I could simply customize the Media Sub Type field with my additions. I've tried the trick with renaming the display value but the problem is that in expressions I still need to reference my custom field by its true name, and that would mean having to fix countless expressions across my library. It would be so much easier if I could add my own somehow. I understand there's a need to protect certain values within this field, but maybe if there was something like a companion field that we could use to add our own entries that MC could then include along with its defaults?

[Hendrik]

Media Subtype has a technical meaning for Media Center, as such we'll not allow it to be customized. If you want a fully customizable field for sorting your content, just put it all in the closest Media Subtype and use an entirely separate field for your organizing purposes - that way you have absolute control. Every view or other organizing feature in MC is customizable to just use your own field, so there is really no gain from changing media subtype over using your custom one.

[Doof]

I'm curious, what is MC's requirement for Media Sub Type? Some of the entries I can understand, like Audiobook, Podcast, Movie, TV Show, since MC natively handles such content, but Workout? Remix? Are those important somehow?

If you want a fully customizable field for sorting your content, just put it all in the closest Media Subtype and use an entirely separate field for your organizing purposes

Would I lose any built-in functionality if I don't tag anything with a Media Sub Type and only use my custom tag? I was sorta under the impression it was necessary for some things, but if not I'll just migrate everything to a custom tag and not bother with it anymore.

[Hendrik]

You need a Media Subtype for certain functionality, like metadata lookup, bookmarking behavior, etc, but you can just use one that roughly approximates the content, since you are not going to use it for display purposes.

[glynor]

You need a Media Subtype for certain functionality, like metadata lookup, bookmarking behavior, etc, but you can just use one that roughly approximates the content, since you are not going to use it for display purposes.

Yep. There's no particular reason to set videos, for example, to really anything other than Home Video, TV Shows, or Movies really so that it can do automatic metadata lookup, and so the Bookmarking works right by default (though you can override this). But you can use the other settings, if you want, to further classify your content. They just don't do anything useful, other than let you categorize your content.

Making a separate [Media Category] field of your own is a completely viable alternative. This even has some benefits, because then you can set the "real" [Media Sub Type] such that MC "likes it" (as a Movie, or whatever, so that maybe automatic metadata will find something useful), but use your own classification field to drive your Views.

I've often considered doing exactly that, but have basically been too lazy. I currently use [Media Sub Type] for a few other types of content (concerts, for example) but to get the lookup to work and update them every so often, I have to manually switch it to Movies and then back to "my category". Using your own field would make that problem go away.