INTERACT FORUM
More => Old Versions => JRiver Media Center 20 for Windows => Topic started by: Denti on May 06, 2015, 12:51:11 pm
-
The Caption settings are still there, and they're much more powerful than they used to be. You can set different captions based on any search, so different types of files can have different captions.
Thanks, but can you explain to me how I would get the default [Name] to function like it does in Standard View, that is: not displaying the field "Name" but the category at that level of browsing?
-
I think you mean the captions of Categories themselves (the "levels" of categorization, as opposed to the files themselves). You could never change this, and I don't think you can now (though I could be wrong).
Can you explain more clearly, though? Perhaps with a screenshot or three? Because I'm not sure at all what you mean by that question.
The old Caption setting, though, didn't lose anything. It just moved into the Template system. The old system was global (all files got the same caption), and was the same as the "Standard" caption, but otherwise is identical.
-
In Standard View I use a custom "All Artists (Last Name)" to sort artists by last name. But if I choose to display [Artist] I get "[Varies]" for those artists where I use a ;-delimiter, because it can't for some reason recognize the ;-delimiter. But if I use [Name] I get the artists allocated properly with the ;-delimiter. Only problem is: they are displayed Last Name, First Name (as per the sort). BUT... since JR20 I can use the Unswap function to fix that, and Viola! it works....
But not in Theater View, because it won't output [Name] in the same way. Make sense? Any way to help?
-
Screen shots please. I'm still not sure if you're talking about Category names or File Captions.
-
If I use [Name] viewing Categories that I've sorted by last name the ;-delimiter works and I can unswap the names. See the thumbnail expression editor in the top left.
(http://i58.tinypic.com/ekjp1f.png)
If I use my last name sort field the ;-delimiter doesn't work, and I get [Varies] where I've used ; :
(http://i58.tinypic.com/dzbi8y.png)
In Theater View things get uglier. The ;-delimiter problem is the same as in Standard View, so using my last name sort custom field for display is out of the question, though it isn't consistent in how it displays things (this baffles me, honestly):
(http://i59.tinypic.com/2nrlhmo.png)
And using [Name] pulls up the *field* "Name"--so that's out of the question:
(http://i57.tinypic.com/5zdw2.png)
I see two possible solutions:
1) [Name] is made to function in Theater View just as it does in Standard View / Categories.
or
2) The ;-delimiter is made to work for all fields when displaying.
What I want is to see what I'm getting to display in Standard View also in Theater View. Is that impossible?
-
Ok, yeah... It is the Category Name. Saying [Name] there and up above was confusing me, because that notation usually refers to the Library Field called name. In this case, it means the category name, rather than to the [Name] field.
I think you can fix it if you make it a custom Field instead of an expression, because you can make MC treat the custom field as a list-type field. You can make a calculated field that has a custom type using this trick:
http://yabb.jriver.com/interact/index.php?topic=97230.0
You should be able to apply a custom sort-order to Theater View if you've saved a sorting preset elsewhere. You can't make them within the Theater View editor, but you can apply sorting presets to the categories if you've saved them elsewhere, much like the panes in Standard View.
-
I'm using a custom field that is set to "list type" but that doesn't help.
Can you explain how I would apply a custom sort order (distinct from display?) in Theater View? How would this get around the ;-delimiter not being recognized?
I'm confused.
-
I'm a little confused too, and I'm on my phone, so no, not right now.
Tomorrow evening I'll have more time. But this should really be split out to its own topic.
-
I'm a little confused too, and I'm on my phone, so no, not right now.
Tomorrow evening I'll have more time. But this should really be split out to its own topic.
Well, I'd love to get help. I've been trying without success for a year to get this to work. Frustrating. If the developers would only make the ;-delimiter work with custom fields and in Theater View.
-
I think they do. It works perfectly well with [Keywords], for example. Artist is something of a special list-type field, but it shouldn't be impacting Your issue is separate (I think your expression is wonky).
I'm going to split this out. After I do, can you please describe in detail both:
* How you have the files tagged?
* What you'd like the final Theater Media View to look like?
Avoid how you want it to look that way, just the end results. In other words, I'm still not sure what exactly your data in the tags looks like (is it swapped or unswapped or what), what those custom expression fields you have there are doing, and all of that. I'm not even 100% sure what sort order you're looking for.
Also, remember that to output a List-type expression, you should tag it as such:
http://wiki.jriver.com/index.php/Expression_Language#Data_Types
Yours posted above is not tagged that way, so it will always be treated as a string.
-
There. I finished splitting it decently well.
I'm on pretty limited time tonight (I'm at work), and won't get home until much later, so I don't know if I'll have time/energy/sobriety to do anything tonight. But, if you post more details, I'm sure I can help. I can't promise I can fix everything, but I'd be pretty surprised if we can't get something acceptable for your use. I'm not positive, because I don't use multiple-artists at all, so I could be way off base, but I think it is worth trying.
To answer your question above, though, you can sort Categories in Theater View arbitrarily.
(http://glynor.com/img/screenshots/MC20/TheaterView-Category_Sorting-small.png)
Click to embiggen. (http://glynor.com/img/screenshots/MC20/TheaterView-Category_Sorting.png)
In the View above, I have the [Series] category added to a Theater Media View, and the categories themselves sorted so that Series with the most recently imported files are on top.
The Sorting drop down (ascending/descending) shows you the same list of Sorting presets that you get here:
(http://glynor.com/img/screenshots/MC20/Sorting_Preset_Editor.png)
You can add your own sortings, but you can't do it from within Tools > Options > Theater View. You have to create the sorting preset using anywhere you can load/save Sorting Presets within Standard View. Then it will show up in the Sorting drop-down combobox in Tools > Options > Theater View.
-
Alright, let me try answering your questions:
1) tagging:
For groups:
[Artist]: Black Flag
[All Artists (Last Name)]: Black Flag
For individuals:
[Artist]: Bob Dylan
[All Artists (Last Name)]: Dylan, Bob
For multiple individuals/groups:
[Artist]: Bob Dylan; The Band
[All Artists (Last Name)]: Dylan, Bob; The Band
or
[Artist]: Lou Reed; John Cale
[All Artists (Last Name)]: Reed, Lou; Cale, John
The rest of the tagging is basic. I have some odd things I use, but these don't interfere with the issue at hand.
Here's how I would want the above sorted/grouped and displayed:
The Band
John Cale
Bob Dylan
Lou Reed
It's that simple. This means that the record with both Dylan/The Band would appear under *both* the grouping "Bob Dylan" and "The Band." And of course those albums by *just* these artists would also be grouped there. Ditto with the Lou Reed/John Cale collaboration. I would like it to appear in both groupings.
It's a simple request. And the *only* way I can get it to work is in Standard View (Categories) by sorting/grouping by [All Artists (Last Name)] and then putting "unswap([Name])" in the thumbnail display. Nothing else works. I want this display in Theater View, since I use JRemote and also Theater View.
Adding &datatype=
to the expression does *not* make a difference.[/list]
Both [Artist] and [All Artist (Last Name)] are user defined as "List (semicolon delimited)", "Not relational" and edit type "Standard"
-
You can add your own sortings, but you can't do it from within Tools > Options > Theater View. You have to create the sorting preset using anywhere you can load/save Sorting Presets within Standard View. Then it will show up in the Sorting drop-down combobox in Tools > Options > Theater View.
By the way, when I try to set a new preset sort by the program freezes on me ?
-
I think they do. It works perfectly well with [Keywords], for example.
By the way, I tested this, and it does not work with [Keywords]. The problem is with grouping together albums that have only one artist with those that have more than one. Only by using the Category can I get the right display results using ; Otherwise I get [Varies], which of course defeats the purpose of the ;
-
Just a reminder to glynor that I'd love your help on this!
Thanks in advance.
-
Thanks. Yeah, I'd forgotten.
-
[All Artists (Last Name)]: Black Flag
Is this field tagged manually, or is it auto-generated? If it is auto-generated, please provide the expression used.
If it is tagged manually, I don't know if there's a way to do it. That's because MC can't associate item #3 in one list of terms with item #3 in the other list of terms. You might have manually ensured they were always entered in the same order, but it can't know that, so it doesn't have that capability.
If you are auto-generating it, we can use the auto-generation on one string at a time and it should work.
But I don't know how you have this set up.
EDIT: Nix that. We should be able to do it either way.
-
Also, can you provide a Library Backup?
I don't have enough stuff tagged this way to test it otherwise. You can PM me a file sharing link using DropBox or WikiSend or something like that.
-
Okay. I loaded your Library and played around with it a bit.
I can confirm this, at least, the Category sorting is definitely acting crazy with your [All Artists (Last Name)] field. I haven't figured out yet exactly what it is doing, but it is doing odd things.
I haven't figured out exactly what logic it is using to sort on the field. But I can, at least, see that it is acting crazy. I suspect the sorting doesn't fully support List Type fields, when applied to a Category.
But, I'm not sure on that, and will have to look at it more.
-
I should also note... You have some really messy stuff in there. An epic ton of custom fields (it looks like most of them are previous attempts at things), and half-way broken expressions.
For example, in addition to the [All Artists (Last Name] field you use, you have one called [All Artists (Last Name)2] that is a string field, and is empty. And a metric ton of other [Artist (Last Name] style fields. It looks like you did a lot of experimentation and didn't "clean up" failed attempts and things like that.
Also, even if it worked in an expected manner... Your tag data is pretty inconsistent. I found lots of files that had a [All Artist (Last Name)] value, but where [Artist] itself was completely blank.
So, I do agree that something is broken here, but... You have some poor performing views and stuff, which is almost certainly all due to the mess.
-
Does "crazy" mean "not normal" or just "wow, I didn't know it would act this way"? I mean, should it be able to not act crazy and do what I want it to do?
Any clarifications/help you need from me, just let me know. And again: thank you!
-
I should also note... You have some really messy stuff in there. An epic ton of custom fields (it looks like most of them are previous attempts at things), and half-way broken expressions.
For example, in addition to the [All Artists (Last Name] field you use, you have one called [All Artists (Last Name)2] that is a string field, and is empty. And a metric ton of other [Artist (Last Name] style fields. It looks like you did a lot of experimentation and didn't "clean up" failed attempts and things like that.
Also, even if it worked in an expected manner... Your tag data is pretty inconsistent. I found lots of files that had a [All Artist (Last Name)] value, but where [Artist] itself was completely blank.
So, I do agree that something is broken here, but... You have some poor performing views and stuff, which is almost certainly all due to the mess.
Yeah, there are lots of experiments I didn't clean up. But there shouldn't be any empty [Artist] fields. Let me look into that.
EDIT: I see those, and have no clue how that happened. Fixing now.
-
Does "crazy" mean "not normal" or just "wow, I didn't know it would act this way"? I mean, should it be able to not act crazy and do what I want it to do?
It meant, with your large data set and complex Library, I couldn't figure out what it was doing logically. So, it certainly seemed to act crazy.
I needed a simpler example set. Still working on it.
-
Ok. I've confirmed some behavior.
* You cannot sort Categories based on List-Type fields reliably except when using Ascending or Descending sorting.
* You cannot use List-Type fields as the sorting key for any categories. If you do, the Edit Category dialog actually blanks out the Sorting drop down after you apply it. It does actually apply some kind of sorting order when you do this, but it makes no logical sense.
The latter thing, based on the fact that it "clears out" the Sorting drop-down, makes me think they know something in there doesn't work, but it doesn't do enough to stop you from trying.
The former thing, seems to be a bug. I'll post example screenshots later, but right now Windows is insisting on rebooting.
-
To test this, I made a View that shows only a certain set of test files I have. I created two user-defined fields: [Test Field (Display)] and [Test Field (Sort)]. Lastly, I added [Test Field (Display)] as the only category in the View (a Panes-style Media View in Standard View).
Lastly, I added some values that are easy to sort to these two fields. Simple letters for the Display field, and incremental numbers for the Sort field.
If these fields are created as Data Type String, then everything works as you'd expect. Here it is with the [Test Field (Display)] category with Sorting set to Ascending:
(http://glynor.com/img/screenshots/MC20/List_Category_Sorting-String_Normal-1.png)
I also made a Sorting Preset called Test Field (Sort) which is defined as:
~sort=[Test Field (Sort)]
That's a nice and simple example. Since [Test Field (Sort)] contains just numbers 1-24, and the "alphabetical" display field is done in the reverse order, then it should sort the category in "reverse alphabetical order" if I apply it to the View. Just like the file list in the screenshot above lists the files. That works fine, as you can see here:
(http://glynor.com/img/screenshots/MC20/List_Category_Sorting-String_Normal-2.png)
So, that's great. I'm using [Test Field (Display)] as a category, but I'm sorting it based on [Test Field (Sort)]. I knew this worked well. I sort tons of my View categories by Date Imported and other special sortings.
* Change [Test Field (Display)] to a Data Type: List.
And, add a few items that have multiple values. If you add these only to items at the "bottom" of the list (those which would sort to the bottom anyway based on the Sorting field), then everything still works as you'd probably expect.
(http://glynor.com/img/screenshots/MC20/List_Category_Sorting-List-Ok_Sorting-1.png)
Value m comes right after b and before a because both b and m have the same sorting value (21). Then we get a and lastly n. Makes sense. Likewise, if I add the value n to one of the items previously tagged only l, then it still works like you'd expect. Now we get l and then n at the top of the list.
(http://glynor.com/img/screenshots/MC20/List_Category_Sorting-List-Ok_Sorting-2.png)
You can go further, and move category m upwards in the list if you want. I tagged the file with sort value 10 with "m; h" As you can see, I reversed the order of the items this time, but it still worked "right" and sorted these "h, m, g".
(http://glynor.com/img/screenshots/MC20/List_Category_Sorting-List-Ok_Sorting-3.png)
If I switch this, and make the item with sort value 9 "m; h" instead, then it is "right" and shows the categories "m, h, g":
(http://glynor.com/img/screenshots/MC20/List_Category_Sorting-List-Ok_Sorting-4.png)
Okay. Up until here, everything makes a kind of sense, and follows a logical, consistent pattern. In my next post, they won't anymore...
-
Okay, next, I took that same list, and tagged the first two items (sort key 1 and 2) as "l; o" and "l; p" respectively. No other changes at all, so, following the logic we discovered above, you'd expect the order of the categories to be: "l, o, p, k". Well, look what happens:
(http://glynor.com/img/screenshots/MC20/List_Category_Sorting-List-Weird_Sorting-1.png)
What? Where did f and e come from? And why are o and p way down at the bottom of the category list? The only entry for o is tagged with the sort key 1, and the only entry for p is tagged with the sort key 2, so what are they doing way down at the bottom of the list?
The order of the files themselves is still correct. It should follow the sort order shown in the file listing, but it doesn't. And somehow, e (sort keys 15 and 16) and f (sort keys 13 and 14) got "promoted" way up in the list. And all the others are all out of whack too. It follows no rational order I can detect anymore. They aren't "shuffled" (the order stays the same each time you look at the view) but I have no idea where it is coming from now.
If I take the o value out, and just leave the p value, then for baffling reasons, e goes back down the list (but not back to where it was supposed to go) and f stays up there in the "second" spot. Look at the order down at the bottom of the list as well! Somehow, c is above e and d, and i and g are out of order. The whole thing is just... crazy-pants.
(http://glynor.com/img/screenshots/MC20/List_Category_Sorting-List-Weird_Sorting-2.png)
It behaves up to a point, but depending on the values in the category, it eventually gets all... Crazy. I don't know what it is doing, but it does not work in any way I'd expect it to work. I'm not even entirely sure what triggers it. It seems like if items that sort at the top of a list have unique values, then it goes haywire, but if those values are "anchored" somewhere further down, then it is okay. But why it is that way, and where exactly the "line" is that it breaks, is a mystery to me.
Of course, if you change the category back to ascending or descending, then everything works fine.
(http://glynor.com/img/screenshots/MC20/List_Category_Sorting-List-Sorting-Ascending.png) (http://glynor.com/img/screenshots/MC20/List_Category_Sorting-List-Sorting-Descending.png)
I've done tests with changing Test Field (Sort) into a List-type field, as well, and this breaks even more quickly.
If anyone from JRiver wants to play with this, PM me and I'll send you a copy of my Library Backup which includes this view, so you can play around with it.
-
So... I was wrong. Something is all wonky in there, and you cannot do what you want.
It obviously would be much better if Swap() and Unswap() could handle List-Type fields. That's really what I'd like, so that I can display [Actors] and [Directors] (which are filled automatically by the Metadata Lookup system) in "name swapped" order. Those are easy cases, because each value is going to be a regular name, and there are no "band names" to content with.
I can also see wanting to store Artist names "regular" (Firstname Lastname, style) but display them in a category swapped (Lastname, Firstname). This is tougher to solve, but... If sorting on List Type categories worked "right" then you could:
1. Make a list-type [Artist (Sort)] field, which you fill in manually by "Swapping" the names for each value where it makes sense, and leaving band names untouched.
2. Add the regular [Artist] field as a category, but sort it by [Artist (Sort)].
This would, essentially, recreate the ARTISTSORT field used by iTunes. I've seen that request come up a few times. You could do it, back before [Artist] was a list-type field. But now you can't, because sorting on list type fields is all broken.
-
Just so you know, my temporary solution has been to use my last name field as the sorting field and to display "Unswap([Name])".
[Name] at this level in the Categories View is able to parse the list of artists sorted by last name, and the Unswap expression is able to flip them over. But this only works by using [Name]. Using Unswap with my last name field doesn't work.
This solution is great, but does not work for Theater View, which is where I really want to use it.
Any way this could be addressed in future builds?
-
This solution is great, but does not work for Theater View, which is where I really want to use it.
Yeah. Theater Media Views work just like Panes-style Standard Media Views.
Panes don't have that special "Name" category type that refers to the "current" level category (because there is no "current" level, they're all simultaneously open).
That's why I made my test view a panes-style View. Those are the direct-corollary to Theater Media Views, and are usually easier to understand (because you can see all the "levels" at once).
-
Yeah. Theater Media Views work just like Panes-style Standard Media Views.
Panes don't have that special "Name" category type that refers to the "current" level category (because there is no "current" level, they're all simultaneously open).
That's why I made my test view a panes-style View. Those are the direct-corollary to Theater Media Views, and are usually easier to understand (because you can see all the "levels" at once).
So, glynor, what's the solution, in the long run? Put another way: what should I be requesting for future builds that would allow me to do what I want to do?
I guess for now I'll just have to duplicate files.
-
Patience.
-
Patience.
So then, it will be addressed? Nice. I can be patient.
-
I can't promise, but there's a good chance.
-
I can't promise, but there's a good chance.
Thanks! :)
-
By the way, when I try to set a new preset sort by the program freezes on me ?
I think I figured out what was happening to you here:
http://yabb.jriver.com/interact/index.php?topic=97661.0
-
By the way, I tested this, and it does not work with [Keywords].
By the way, you misunderstood what I meant here. You had said previously that you wished Theater View could just handle the semicolon and list type fields. I said, it does with [Keywords], because it certainly does. It works with all List-Type fields when added directly as a category (I also have views that show [Directors] and [Actors] and they work fine).
(http://glynor.com/img/screenshots/MC20/TheaterView-Views-Photo_Keywords-small.png)
(http://glynor.com/img/screenshots/MC20/TheaterView-Setup-Photo_Keywords_Category-small.png) (http://glynor.com/img/screenshots/MC20/TheaterView-Setup-Photo_Keywords_Category.png)
It just can't handle it when fed by an expression. I think there are even ways around this if you're clever, but it doesn't matter for your purposes because the sorting is all whacked, as discussed above, so you can't do it.
-
Just checking to see if anything came of an inquiry into the sorting problem...
-
Just checking to see if anything came of an inquiry into the sorting problem...
I think I can say this is being looked into ;)
But I think its obvious that something should be done this is not a sorting issue with a field that is the problem; it is sorting on expressions for display. This should allow multiple entries per field to be split via the separator and sortable on an expression.
It almost seems like certain out of the box fields are handled differently in that they act like list fields but are data fields, from custom fields that are set up as list fields dependant on standard fields. Not 100% sure on this one
Minimally what I hope we get to is a simple non regex way to sort lastname, firstname and show first name lastname with multiple field items per record. I'm thinking that this would have to be done using custom list fields (or standard fields like Artist and Artist Sort, which are standard vorbis comment fields). Maybe this could be done with an advanced function mode using swap/unswap as mentioned?
-
To be clear: my examples above involve no expressions at all, fancy or otherwise. They're just regular fields. One List Type and one String. All List Type fields, including built in ones (like [Keywords] and [Actors] for example) behave this way. It probably applies to [Artist] too, if you actually use it as a list (I don't).
So, for example, you cannot sort a Keywords Category to show the most recently imported ones first. I do this a lot in all of my views, just not before with a list type field by dumb luck.
-
I think I can say this is being looked into ;)
Well this is good news!
-
So, I can say for sure that what you were looking to do originally, cannot currently be done. Sorry. It comes down to the fundamental nature of the way MC handles fields. Even if they fix what I found above, that won't help you because if you have a file tagged:
[Artist] = "Jay Random; Johnny Appleseed; Florence McFakename"
[Reverse Artist] = "Random, Jay; Appleseed, Johnny; McFakename, Florence"
Then what you've essentially done is made the value "Jay Random" equal to all three of:
* Random, Jay
* Appleseed, Johnny
* McFakename, Florence
But, the discussion continues over here:
http://yabb.jriver.com/interact/index.php?topic=97647.0
-
Wow, thanks guys for giving this a good go! Man, I'm in over my head. Half of this discussion is hard for me to follow.
What's strange about this whole thing is that I am able successfully to do what everyone keeps repeating in this thread cannot be done! It works, perfectly fine, in Standard View/Categories View. I simply sort by my custom Last Name, First Name field and display Unswap([Name]). Done.
So what's this special [Name] field doing that can't be replicated elsewhere?
I want to be able to duplicate this behavior in Theater View, that's all. But [Name] functions differently there.
P.S. If no solution is forthcoming (and I'm willing to wait!), then I'll resort to duplicating files, which seems to me a little absurd.
-
I moved this over here, because I'm trying to keep the other one about the particulars of the sorting issue with List-Type views. This has more to do with the overall Name Swapping thing.
-
I moved this over here, because I'm trying to keep the other one about the particulars of the sorting issue with List-Type views. This has more to do with the overall Name Swapping thing.
So can you explain why all the talk of what I'm wanting to do being impossible, when in fact it is possible, just only in Standard View?
-
So can you explain why all the talk of what I'm wanting to do being impossible, when in fact it is possible, just only in Standard View?
It isn't possible using the tools we already have, because the special "Category Name" category isn't available except in Categories-style Standard Views.
I'm not sure why it works with that, but in either case, Theater View (and Media Network Views) don't use that special thing.
-
It isn't possible using the tools we already have, because the special "Category Name" category isn't available except in Categories-style Standard Views.
I'm not sure why it works with that, but in either case, Theater View (and Media Network Views) don't use that special thing.
But the point is that is *does* work with that special "category name"--so the talk of it being "impossible" seems to me to be missing something crucial. It IS possible. Just figure out what is allowing that special field to do what it does and implement it in the other fields.
-
Impossible doesn't mean impossible forever. But, not prevented by a bug in the system we already have.
I'm also not sure your system using the special Name Category works in all cases. Sounds like it does, but I haven't tested it thoroughly.
If you can't do it in Panes, you can't do it in Theater View or Media Network.
-
Impossible doesn't mean impossible forever. But, not prevented by a bug in the system we already have.
Why not just create a field that functions like [Name] does in standard view and make it available in all views? That would solve my problem instantly.
Or better yet: figure out how that special "Category Name" field is able to do what it does and make that possible in other list fields.
-
I'm also not sure your system using the special Name Category works in all cases. Sounds like it does, but I haven't tested it thoroughly.
It definitely works in all cases. You've seen the size of my collection. Believe me, it works.
-
I think the reason it works is that, internally, the special Name Category gets data from the source Category "already processed". So it never sees the list-type fields as semicolon delimited strings, but just individual string items.
Then, it can reprocess them itself.
That's pretty cool. To be clear, that's why I left this thread open and didn't want it all to move to the other discussion. The issue isn't a sorting problem. It is something more fundamental.
However, MC itself already has this special Name Category function. What we need, I think, is a more generic version of that: a "pointer category". If we had that, it might solve this and a whole class of display issues in MC.
-
However, MC itself already has this special Name Category function.
What or where is this? You just mean at the Category level of Standard View?
-
I think the reason it works is that, internally, the special Name Category gets data from the source Category "already processed". So it never sees the list-type fields as semicolon delimited strings, but just individual string items.
Then, it can reprocess them itself.
That's pretty cool. To be clear, that's why I left this thread open and didn't want it all to move to the other discussion. The issue isn't a sorting problem. It is something more fundamental.
However, MC itself already has this special Name Category function. What we need, I think, is a more generic version of that: a "pointer category". If we had that, it might solve this and a whole class of display issues in MC.
Any way to rally support for this?
Or should I resign myself to duplicating files...
-
What or where is this? You just mean at the Category level of Standard View?
Yes. That's what I meant.
I've had some more thoughts on this over the past week, but no time. I'll come back with more this weekend.
-
Bump. Still interested in solving this.
-
My reading of this is that there might be a bug somewhere, but it's so long and dense that I'm struggling to find it.
Would you be willing to state the bug as simply as possible? Give a simple example if it's possible.
Thanks.
-
My reading of this is that there might be a bug somewhere, but it's so long and dense that I'm struggling to find it.
Would you be willing to state the bug as simply as possible? Give a dirt simple example if it's possible.
Thanks.
In short:
In Standard View [Name] returns the name of a category.
In Theater View [Name] is applied to the items inside the category.
The simplest example I can think of is to create a new view where the rule for files to display points to a single compilation album. (i.e one with multiple artists)
In Standard View, set the category to [Artist] and thumbnail display to [Name]
In Theater View, set the expression to group by [Artist] and the expression to display to [Name]
Standard View returns artist names for [Name]
Theater View returns track names for [Name]
So any expression which tries to modify [Name] e.g. an expression to swap first and last names, tends to break in Theater View.
-
Personally I think the Theater View behavior is more consistent, if anything. I assume any other fields also behave the same way even in Standard View, ie. reporting data for the files inside the category, instead of being "special"?
This special name behavior should probably just be a function instead of overriding the Name field.
I don't know why they behave differently though, and it may in the end be easier to override the Theater View [Name] field instead of mocking with a new expression, which probably doesn't even know the value for this field, since it would be on the "outside".
-
This special name behavior should probably just be a function instead of overriding the Name field.
It should be a separate "field" called [Category] (or an equivalent function), because that is what it is. Using [Name] has always been weird. It violates the "rules" of square-bracket field notation.
-
It should be a separate "field" called [Category] (or an equivalent function), because that is what it is. Using [Name] has always been weird. It violates the "rules" of square-bracket field notation.
This would be great!
What is the expression behind the [Name] field in Theater View? Is it an expression? If so, I would be perfectly happy creating my own custom field with it.
-
Thinking about it some more, I agree.
It would be more consistent to change how [Name] behaves, and introduce a new field.
[Name] returning track/file names should be what it does, since that is what's inside the name tag.
A new field to display or modify the category name, such as [Category] would be more consistent.
Only I don't know what you would want to do about Standard View.
Would you modify it to use the same logic as Theater View? That would probably break all existing views, which use [Name] for the "Thumbnail Text" by default.
-
Personally I think the Theater View behavior is more consistent, if anything. I assume any other fields also behave the same way even in Standard View, ie. reporting data for the files inside the category, instead of being "special"?
Theater View is more consistent. The special behavior only applies to Standard Media Views set to Categories style. Those in Panes style behave exactly like Theater Views, as do those in Media Network Views.
The special use of the term [Name] is limited to only Categories-style Standard Views.
-
I bet it would unleash quite the storm if I were to break this use-case of [Name], and move it to a different field or something, huh.
Not like [Name] is actually useful on a category group, you can't really do anything useful with that, so maybe I should just leave it be and make Theater View also do that? I bet for some reason that would also break someone elses workflow, though. Somehow something is always broken for someone with such changes. :p
-
You're screwed. ;)
-
I bet it would unleash quite the storm if I were to break this use-case of [Name], and move it to a different field or something, huh.
Not like [Name] is actually useful on a category group, you can't really do anything useful with that, so maybe I should just leave it be and make Theater View also do that? I bet for some reason that would also break someone elses workflow, though. Somehow something is always broken for someone with such changes. :p
I doubt anyone uses [Name] in the Theater View for song titles, which is what it displays, I think. I mean, really, who would use that? I think you're safe making it do what it does inn Standard View.
Please. :-*
-
I use [Name] as a category fairly often in Theater View (and Panes-style Standard Views, and Media Network Views). Two reasons:
* Grouped (so it shows A-B, C-D, etc).
* To combine episodes of shows with movies into a single View (which I do with Documentaries). Here it does a If(IsEqual([Genre]) test to check what the type is, and then displays either [Series] or [Name] as the Category output depending on the result.
That way be dragons.
-
If [Name] is the grouping field anyway, then the content of [Name] in the display expression also wouldn't change, would it?
So would it actually change behavior for you if [Name] behaved like Standard View?
-
If [Name] is the grouping field anyway, then the content of [Name] in the display expression also wouldn't change, would it?
So would it actually change behavior for you if [Name] behaved like Standard View?
I'm not following. I simply want [Name] to do the same thing in Theater View as it does in Standard View. Can we somehow make that possible? Even if it simply means creating a new field for it.
-
I'm not following. I simply want [Name] to do the same thing in Theater View as it does in Standard View.
It only does it in certain conditions in Standard View (only within Views set to Categories view mode). Most of mine are not in Categories, so to me, having [Name] altered across the board spells danger.
If [Name] is the grouping field anyway, then the content of [Name] in the display expression also wouldn't change, would it?
So would it actually change behavior for you if [Name] behaved like Standard View?
Thinking on it. I don't know.
It definitely seems counter-to-expectations that all square-bracket notation works one way, except for [Name] which is weirdo. Whomever decided to use that notation for the special behavior of Categories style views probably didn't think it out fully. We don't know what we don't know, you know?
I'd be much more comfortable with "fixing it right" and using [Category] or CategoryName() or something like that, surely. It would cause some short-term pain in fixing a few Views for people, but perhaps at the MC21 division this wouldn't be so bad?
Not sure. But, thinking on it.
-
I'd be much more comfortable with "fixing it right" and using [Category] or CategoryName() or something like that, surely. It would cause some short-term pain in fixing a few Views for people, but perhaps at the MC21 division this wouldn't be so bad?
This seems reasonable. How feasible/doable is it, Hendrik?
-
Checking back. I'm stubborn, and while patient, I'm not giving up on this. ;)
-
So, any developments?
-
So then, it will be addressed? Nice. I can be patient.
Any chance this has been or will be addressed? I'm still hoping!
-
They are done with version 20. Try asking on the version 21 board if you are thinking of upgrading.
-
its not necessarily a version issue
I replied (euh, at length ;D) to this in Denti's other post here http://yabb.jriver.com/interact/index.php?topic=101338.msg704591#msg704591 (http://yabb.jriver.com/interact/index.php?topic=101338.msg704591#msg704591)