More > JRiver Media Center 21 for Windows
Global var issue and musings
MrC:
In the 18.0.207 thread, I wrote:
--- Quote ---I think I'm seeing a bug when selecting a value in a pane column, when the column values are derived from global variables. First, here's a link to the movie that shows the problem:
https://www.dropbox.com/s/kv9gmv2885mddya/possible%20bug.mp4
Here is how the view is created:
Set rules for file display below. These just initialize two variables to 0, and then later increment either of the variables depending upon the value of the field [Custom]:
[=save(0,exc_[Artist])1]=1 [=save(0,inc_[Artist])1]=1 [=if(isequal([Custom],EXCLUDE), save(math(1 + load(exc_[Artist])),exc_[Artist]), save(math(1 + load(inc_[Artist])),inc_[Artist]))1]=1
The library has two calculated user fields which are defined as:
_v_exc: load(exc_[Artist])
_v_inc: load(inc_[Artist])
The movie shows these in the file list column. It is clear that clicking on them selects the files that produced the cell value. So this works.
The movie also shows that the view has a calculated field - this pane column's expression demonstrates the problem:
math( [_v_exc] & [_v_inc] )
The calculated values are correct - the pane shows both values 0 and 1, as expected, since some of the 90 files have the EXCLUDE keyword in Custom.
However, notice how clicking on either value produces the wrong file list - its all files or no files.
--- End quote ---
To which Matt replied:
--- Quote ---MrC, you're in uncharted territory.
When you pick '1' in your AND expression pane, it's effectively saying "show files that match these two searches":
Code:
[=save(0,exc_[Artist])1]=1 [=save(0,inc_[Artist])1]=1 [=if(isequal([Custom],EXCLUDE), save(math(1 + load(exc_[Artist])),exc_[Artist]), save(math(1 + load(inc_[Artist])),inc_[Artist]))1]=1 [Media Type]=[Video]
[=math( [_v_exc] & [_v_inc] )]=[1]
The search compiler combines searches, sorts token ordering, etc. to help performance. It's not really designed have dependencies that require a deterministic evaluation ordering, which only arise when there are save and load calls.
It's possible we could make the compiler smarter for cases like this.
However, I'm not thrilled with packing up the global variable store like this as it seems like a complex solution. Is there some construct that would allow the same functionality without using variables like that? Feel free to start a thread.
--- End quote ---
I understand the explanation, and had previous suggested to others that this is how MC might be working. I realize these hack techniques are working by a fortuitous side effect, which has surpassed the limits by trying to impose a deterministic evaluation order. So that's cool. And I entirely agree, the current hacked solutions are far too complex and JRiver probably should spend no time trying to make this work.
Here's my assessment of the desired functionality:
- a way to deterministically evaluate an expression sequence across the list of files
Generally the technique is employed for performing some math/counting, or for string manipulation.
A more straightforward method to accomplish this (removing the gross side effect employed now) would require an ordering to MC's operations with a new intermediate stage:
1) Filter Stage: Set rules for file display (and Search) to filter the list of files
2) New: Post-filter Iteration Stage: Iterates over these resulting files evaluating an expression sequence
3) Display Stage: Presents the generated tokens based on view configuration
Stage (2) would require a loop as such:
Foreach expression
Foreach file
evaluate expression
This order is require so that values can be initialized across all files, and then subsequent calculations performed:
a = 0 (for all files)
a += 1 (for all files)
There are cases when an expression only needs to be run once (e.g. number_of_tracks = 0), and cases where it needs to run for every file (number_of_albums_per_artist). Performance optimizations could be done by providing two evaluation sections or lists:
1. Run Once:
Evaluate run-once expressions
2. Run Always
Foreach run-always expression
Foreach file
evaluate expression
Allowing things like this (non-MC pseudo-code):
1. Run Once:
1a. n_tracks = 0
2. Run Always
2a. n_albums_[artist] = 0 (for each file)
2b. n_albums_[artist]++ (for each file)
Clearly item selection in the view would have to restart the sequence of operations (which MC essentially seems to do already). Selection seems tantamount to filtering via Search.
I have no idea how much impact this has on MC code. But folks want to count things, and aggregate cross-file data. And these folks seem willing to accept a performance penalty for such capabilities.
vagskal:
To a layman like me it looks like the logic proposed by MrC could be used to introduce global search and replace for Regex as well (and an operation applicable to each item in a field). That would, for me, be even more useful.
But since I understand only a fraction of what Matt and MrC said I might be totally wrong. I just wanted to give input on the priority of new features (that would both be so advanced that normal users including me would still probably need help from MrC to implement).
MrC:
This topic is primary focused on a method for using the expression language on the set of files: for each expression, evaluate it for each file. This is inverted logic from the current operation.
Replacement would work within the current implementation: for each file, apply an expression (which just happens to massage a single file's data in some fashion). It's no different than Left(), or RemoveRight(), or Replace(), for example.
I wholeheartedly agree with your priority bump! Time for some more advanced constructs so that other tools can go into the bit bucket.
vagskal:
Thanks for the support regarding the suggested priority! I will shut up now since I obviously do not know what you are talking about.
MrC:
I probably didn't do a very good job clarifying the subtlety, so sorry about that.
For tasks like these, we're using some trickery that just happens to work because of they way MC operates. It is a side effect in essence, but I've encountered a limitation for which I've not found a workaround. The trick relies on how MC figures out which files are to be displayed based on the Search query in Set rules for file display, and that MC allows Custom expressions posing as a query. The trick needs each rule in the query to run first and in order, so values can be pre-calculated in order to show values in a file list cell or in panes columns.
The technique fails in some cases, like the one at the top of the post. It seems some expression values are calculated and cached prior to those set in the Set rules for file display, so selecting panes values produces incorrect results (see the movie, if you're curious to see it working in some cases but failing in another).
In explaining how to perform these global calculations, it has become clear the trick is too complicated for users to modify for new values, and is too finicky. But the pattern of requests has been consistent - a means to perform some calculations on the set of files in a view, before the values are shown in the view, so that those values are selectable and usable in the view itself (the first parts of the movie).
Anyway, maybe this helps clarify the ideas a bit for you.
Navigation
[0] Message Index
[#] Next page
Go to full version