INTERACT FORUM
More => Old Versions => JRiver Media Center 19 for Windows => Topic started by: nihilobstat on April 08, 2014, 12:06:25 am
-
I want TV series named as "Title (Year)", so that when browsing it is easy to see the age of a series.
I have done this with my movies by "Library Tools - Fill Properties from Filename - Template - Filename - [Name]" (as my movies and TV series are all named like that on disk).
When I try this with TV series, MC wants to rename each individual episode (which I don't want), but not the series itself.
I hope I'm not being dense, but I can't see any way of renaming a TV series.
... OK, so I found one way to do it. In Standard View, go to Video - Files - TV Shows, add Series as a column, select all the shows for one series, Rename the series and add the year in parentheses (rename one and they all rename).
Cumbersome, for 270 series, and easy to make a mistake.
Does anyone know a way to automate this?
-
Paste into you series cells:
=[series] /([year]/)
-
I'd like to help but I'm not sure what to offer up because it makes sense to apply terminology consistent with MC's tagging standards:
http://wiki.jriver.com/index.php/File_Properties_%28tags%29 (http://wiki.jriver.com/index.php/File_Properties_%28tags%29)
and I'm not sure that you're familiar with those terms yet. I'd also recommend that you work with MC's existing database structure and get it to work for you.
If I look at a TV show that I've got meta data populated from http://thetvdb.com/ (http://thetvdb.com/) then there are separate fields for [Year] and [Series]. This function is achieved using this feature Get Movie and TV Info (http://yabb.jriver.com/interact/index.php?topic=69316.0).
For furture reference, from this meta data, you can rename the file using http://wiki.jriver.com/index.php/Library_Tools (http://wiki.jriver.com/index.php/Library_Tools) with an example template of:
[Series] ([Year]) S[Season]E[Episode] [Name]
and the relevant file extension is tacked onto the end.
You could set up a custom view. Unfortunately the Wiki is being revised but this is the page that's been deprecated:
http://wiki.jriver.com/index.php/View_Schemes (http://wiki.jriver.com/index.php/View_Schemes)
There are various threads that you can search out on Interact (with MrC's naming popping up frequently) but to get started navigate to:
View > Add View > Add Library View
There are some templates to choose from and various standard locations, or you could attach the new view to the root of the tree in the left pane of standard view. Select the columns and order them to suit. For your purposes, you could place the [Series] and [Year] column side by side.
Does that help? At least to take you a few steps forward.
Hopefully, at least, if you've still got issues we'll all be aligned to help.
-
Thanks MrC and astromo.
MrC, yo da man. That worked a treat.
-
Paste into you series cells:
=[series] /([year]/)
Sorry for the ignorance here, but why the /s for parentheses? I've never used them and the result is exactly as I expect when I do =[name] ([year])
-
Look for the term "forward-slash" here:
http://wiki.jriver.com/index.php/Expression_Language#Expression_Language_Syntax
-
Look for the term "forward-slash" here:
http://wiki.jriver.com/index.php/Expression_Language#Expression_Language_Syntax
Thanks. I'm aware of escaping characters. I just didn't know/remember that the () needed to be escaped. As I said, in the simple expressions I use them, unescaped, MC treats them literally, and not as part of the expression. Try it and you will see that the expressoin you provided doesn't need the () escaped. I guess I just got lucky? In any case, it's probably a good habit to be consistent for when expressions are more complex.
-
He didn't need to escape them in that example. But, he's a nerd (we can smell our own), and he probably just escapes parens by default if they're intended to be literals.
Media Center's Expression Language treats all characters as literals unless they are part of a recognized function or field. For example, if you have no valid field in the Library defined as [My Custom Field #418], and you enter that in an expression, MC will treat it as literal.
So =FixCase([My Custom Field #418], 4) results in [my custom field #418] (square brackets and all). Only if that field actually exists do you have to escape the brackets if you want them. Otherwise the string passes through unscathed.
You can use non-escaped parenthesis with reckless abandon in MC, unless they are intended to be literals within an expression function. Say, instead, you wanted to Title Case the string:
MrC is a (big) nerd but so am i
If you put that in a FixCase() function without being careful, it'd be:
=FixCase(MrC is a (big) nerd but so am i)
In this case, the expression engine gets a bit confused and outputs:
Mrc Is a (Big nerd but so am i)
That's because it interprets the expression from left to right looking for a closing parenthesis, and so the closing parenthesis "big)" becomes the end of the function (and then outputs the rest as a string literal).
If on the other hand, the source text was: MrC is a big nerd (but so am i)
You put that in a FixCase() function without being careful, it'd be: =FixCase(MrC is a big nerd (but so am i))
And that works fine (except for messing up MrC, of course). But that isn't because MC's expression engine stops evaluating from left to right, and instead searches for parenthesis from outside-in. No, the first of the double )) pair still closes the function in this case. The second just becomes the literal parenthesis, and since that matches the desired output, it "works".
All of which is to say that MrC has just decided, being a big nerd, that it is "safer" to essentially always escape literal parenthesis. I think it is likely because to do otherwise would gently needle something deep down inside, violate unspoken symmetries, and just generally disturb the order of things. Plus he's a Perl programmer, and used to all sorts of crazy escaping and bizarre use of punctuation that to a normal human makes things, you know, hard to read.*
I don't, because I'm lazy, and I like to live dangerously. ;)
* As John Siracusa said in a recent (and awesome) episode of Debug (http://www.imore.com/debug-32-john-siracusa-copland-2014): "Well, that backslash is in front of them. I mean, \n, you know... It's not an 'N' it's a Special N." (Around the 1:11:00 mark.)
-
That's a good write up.
I'm a follow-the-rules kinda guy... so I don't have to think or remember too much.
glynor is a rules-are-meant-to-be-broken kinda guy... and he can remember when the rules can be broken.
Which are you?
-
That's a good write up.
I'm a follow-the-rules kinda guy... so I don't have to think or remember too much.
glynor is a rules-are-meant-to-be-broken kinda guy... and he can remember when the rules can be broken.
Which are you?
Thanks glynor and MrC. I'm in between. Rules are to be broken when unnecessary and there's some advantage in doing so.