Print

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

[hoyt]

I renamed (changed the display) of the Series field to Series/ Tour because I use it to group live recordings by series and apply coverart (only way I could figure out how to do that).  If I add a new rule line item to an existing rule and use the Series item, it doesn't seem to work.  I noticed that the dropdown box says "Series" where I would expect on my MC to see "Series/ Tour."  I can't then edit the rule in the text box and it drops the series that I entered at the end of the line with no context:

Here are the steps I'm taking:

1) Setup new recording and it auto creates this rule (Screen Shot 2015-11-23 at 12.24.32 PM)
2) Add a new line to the rule and select Series, note - not Series/ Tour (Screen Shot 2015-11-23 at 12.26.24 PM)
3) Click OK, rule now shows as this (Screen Shot 2015-11-23 at 12.27.30 PM)

I know this rule makes no sense, just setting it up quickly to get some screenshots.

[CountryBumkin]

Where did you change the name "Series" to "Series/ Tour"? Did you go the "Library & Folders > Manage Library Fields"?
I think you would just be changing the displayed name - and not how the field works - so that really would be just a cosmetic change.
You would still be working with the same field "Series" internally in MC.

[hoyt]

Correct, that's what I'd expect too.

Here's a test when changing a field that I haven't touched (Name) vs a field that has been changed.

EDIT: the last screenshot represents what happens when I go back into the rules editor after having set a field with the Series dropdown.

[RoderickGI]

This is probably an unintended consequence of JRiver copying the rules functionality from another area of MC, which included the ability to Import and Export expressions for rules. For example, the Theatre View, "Set rules for file display..." function.

I saw this problem recently where I created a field called "FavouriteTV", with attributes of String Checkbox, and a display name of FTV to keep it short for display in views, so that the column could be just wide enough for the checkbox.

I wanted the rule to say "FavouriteTV = checked". Of course checked mean equal to "1", so the actual rules should read "[FavouriteTV]=1". But I could not select the field named "FavouriteTV", as the field was displayed as FTV. This gave me some grief, although I have since improved that by making the field an Integer. At the time though, I had to use the Rule Import functionality to import "[FavouriteTV]=1", which was then displayed as "FTV is 1".

When creating complex rules in MC, it is common to need to import expressions to create the rule, as the rules just can't be entered directly. I don't know if this issue can, or will be fixed in the Subscription Rules functionality. I'm sure Yaobing was aware of the issue. Of course, maybe the functionality is just picking up the real field name, instead of the field display name as it should.

For the moment, I would advise not changing the display names of key fields such as [Name], [Series], [Season], [Episode], [Description], etc. as they have functionality built around them. Is the meaning of "Series" so different from "Tour" that you really need to change the display name?

[hoyt]

Is the meaning of "Series" so different from "Tour" that you really need to change the display name?

Well, I did it so I'd remember that's what I had used that field for. 

My music collection splits in two, live recordings and studio recordings.  I have roughly 4TB of live music across 30 or so main artists.  When I go into one of those artist, I want to break the display down by more then just the date.  I also wanted that to have coverart associated, but not add a coverart file to 4TB of FLACs, when it really boiled down to a few hundred "tours."  Think of a Tour like "Dave Matthews Band - Summer 2015."  If I have 130 recordings from that year, with 25 tracks each, I want 1 coverart file to apply to all 3k+ files.  So, one view may look like the attached document.

Updating this is a manual process that I do in batch, it's not much work, but I didn't want to forget that it was the Series field that I used to hold the tour - and it's not something that I do often, so it's a nice reminder.  I noticed I could change the display and not the name, that seemed pretty safe.  I've had this for probably two years and this i the first thing that I noticed a core problem.  Since this functionality is new, I'm assuming it was a mistake.

You're probably right, I could get around this by not renaming the field.  But, I'd rather have it addressed so I can leave the field as is. 

[CountryBumkin]

Could you have just used "keywords" to accomplish the same thing?

[hoyt]

Could you have just used "keywords" to accomplish the same thing?

I didn't think that would work for the coverart piece...  So my AppData\...\Cover Art\Series folder looks like the attached.

[hoyt]

I should say... I needed two layers.  So the Series is one, but then I used the Season to represent the actual concert.  So each concert has multiple recordings.  But, again, I didn't want to put coverart into all of those files.  At the concert level, I have the applicable poster show.

[RoderickGI]

I think you have built a good solution for what you need. Using the Series and Season functionality is perfect for what you are doing. I don't know if you could build the same functionality even using custom fields, because of the hierarchy built into Series/Season/Episode library fields.

I was just suggesting maybe change the field display name back for the moment, and try to remember the meaning for the tours, until Yaobing spots this thread and perhaps comments on the chances of a fix. Because this is probably a problem for any field that has a display name different to the field name, not to mention what may happen with the plural display name!

[hoyt]

I was just suggesting maybe change the field display name back for the moment, and try to remember the meaning for the tours, until Yaobing spots this thread and perhaps comments on the chances of a fix. Because this is probably a problem for any field that has a display name different to the field name, not to mention what may happen with the plural display name!

Makes total sense, and I suspect you're right.  In my case, I got around it by simply building the rule on the name, not the series (-[Name] = "College").  Good point about the plural display...