Print

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

[mark_h]

I know this has been covered in the past, but wanted to revisit and see if there was any change in opinion since the last time it was discussed.

What I'd like to be able to do is write directly into a user field within MC.  Rather like save() can be used to write into a temporary variable, it would be incredibly useful to be able to calculate data and then save() or write() into a permanent user field.   

I have so many views now where I have to manually copy this data to keep the information in my database up to date (I typically do this during my import workflow) that being able to do it automatically would be a huge timesaver and would more importantly ensure the correctness of the data within my database at any given time.

[JimH]

So, a custom tag?  Can't you use an expression now to do that?

You can also copy and paste between tags.  Ctrl C and Ctrl Shift V.

I'd guess you know that already.

[mark_h]

Jim, I want MC to do the work for me without intervention on my part.

I want to be able to build an expression to do something like:

write( whatever , [my user field] )

I could then have any number of view or smartlists which when accessed would auto-update my user fields for me.

This is not currently possible but over time the amount of data that I have to handle manually to accomplish this is increasing.  Would be great to have MC do the legwork instead...

[JimH]

Tag on Import?

https://wiki.jriver.com/index.php/Tag_on_Import

[zybex]

write( whatever , [my user field] )

I could then have any number of view or smartlists which when accessed would auto-update my user fields for me.

Why not just have [my user field] defined as a calculated field, with expression = "whatever" ?

[mark_h]

Because the calculations can take 10-20 seconds (I use a LOT of variables)...  I'm trying to cache the results in user fields so I don't have to keep calculating...  I have a scheme that works, but right now I'm having to hand copy the data after calculation.  I want MC to write the results and then I can test for their existence rather than recalculating, which will be much much quicker.

[zybex]

Would you mind pasting a full example?
Maybe it's something that can be added to Zelda.

[mark_h]

Not easily possible - there are many many nested views/smartlists containing loads of calculations, variables etc.

[lepa]

How and when would you trigger the save? Every time for every file in the view? Or should the view only show files which are yet to be processed so the view would be empty when every file has gone through postprocessing?

One way could be to create some kind of macro system to MC which could be used to after touch the files which will move different calculations into database.

I for example am calculating total tracks, album DR and album duration in a WIP view, which I am then moving by hand to user fields so I don't have to calculate them real time anymore.

If I could instead call say a macro command which would calculate these values for selected files and move results to the the database fields, it would be a great time saver

[mark_h]

How and when would you trigger the save? Every time for every file in the view? Or should the view only show files which are yet to be processed so the view would be empty when every file has gone through postprocessing?

The simple answer is every time a field is evaluated, just like every other field...  It's up to you how you use it.

For instance, I'm also using LOCK variables that short circuit the calculations inside smartlists, so it needn't happen every time.  If the lock is present, MC knows that calculations have already been done and only returns the result set instead of running the calculations.

[RoderickGI]

This functionality is so close to being there.

The only thing stopping you from doing it is that a calculated field seems to always be considered to have content, even before it is first evaluated.

For example, I created a calculated field, [Calculating Value X], with Standard editing, and the expression;
If(IsEqual([Calculating Value X],,),[Artist]+[Album], NotEmpty)

It seems that on the first pass processing this, MC might set the field to [Artist]+[Album]. But the result is always NotEmpty, so I assume that either MC considers a calculated field to always have content, or MC evaluates the expression a second time, finds the field has content, and sets it to NotEmpty.

I tried a second expression that used IfElse() instead of If(), because the If function always puts out a value for either true or false. We want a value output if a condition is met, and nothing to be done if it is not.
IfElse(IsEqual([Calculating Value X],,),[Artist]+[Album])

This always evaluates as empty, which leads me to conclude that MC does consider a calculated field to always contain some value, even on first evaluation.

I tried the expression;
FirstNotEmpty([Calculating Value X], [Artist]+[Album])

But just got the output "Expression Error (Circular Reference)", which while true, is a little strange because MC normally evaluates an expression from the inside out, and allows its current value to be used in an expression. I tried a few more variations of this expression but didn't get a working version.

.
.
.
I then I cracked it... almost.
IfElse(IsEmpty([Calculating Value X], 1),[Artist]+[Album])

Gives an evaluated output of "[Artist]+[Album]...". In my example, "Mariah Carey+Music Box...".

It adds the three dots at the end. Now I forget what the three dots mean in an output. Something like an incomplete expression? Hendrik has explained this before. But that is so close to a solution.

Strangely, an Expression Column of;
removeright([Calculating Value X], 2)

Removes the three dots. That's right, removing two characters of the results above, removes three dots. Strange.


If the above worked, to re-evaluate the expression, you just delete the value in the calculated field. If the field already has a value in it, the complex calculation shouldn't be evaluated again. Of course, you would have to test that with your real-world example. Mark_h.

So I guess someone just needs to solve the issue of the three trailing dots, if it can be solved.

[mark_h]

I've just remembered the past hurdle to this:

How to handle writing to a user field that also updates file tags.  You could end up constantly writing to files, which, without care, could cause issues.

Perhaps write() (assuming that's what it's called) should have an optional parameter such that updates aren't written to files unless the user specifies.

write( whatever, [user field], FILE_UPDATE_OFF )

[RoderickGI]

Actually, this just worked.

RemoveRight(IfElse(IsEmpty([Calculating Value X], 1),[Artist]+[Album]), 0)

But it might be a bit risky without knowing what the three dots mean.

With the expression above, even if the [Calculating Value X] field was set to write to the file tag, it should only write on first execution of the expression, or if the value in the field was deleted at a later time, forcing a recalculation. Otherwise the field isn't updated, so I would hope that didn't trigger a write to the tag.


Hmmm, maybe I am wrong about the re-evaluation. I just edited the [Artist] field and the expression above recalculated and updated to the new [Artist] value. Maybe when a field value is changed, the Library record is marked as dirty, and all expressions are re-evaluated.

Maybe put the concept into practice Mark, and see if you get slow View load times or response.

[zybex]

Roderick, I'm under the impression that a calculated field doesn't have a value per se, or alternatively, the value is the expression string itself. The expression is calculated each time a display value is required, but then this value is not saved back to the field. So you can't delete the "current value" of a calculated field.

The three dots are probably an Ellipsis unicode character, perhaps followed by a \n or other blank char. That why deleting 2 chars gets rid of it.
I don't get the ... with your expressions - I just get it when the string is longer than the column width.

[zybex]

You can check that the expression is just being calculated over and over again by adding a counter() call:

RemoveRight(IfElse(IsEmpty([Calculating Value X], 1),counter() - [Artist]+[Album]), 0)

Just moving the mouse over the value causes it to be reevaluated and the counter goes up.

[mark_h]

Actually, this just worked.

RemoveRight(IfElse(IsEmpty([Calculating Value X], 1),[Artist]+[Album]), 0)

Impressive work.  Will take a look   Still can't help thinking a dedicated write() command would be simpler, both to understand and perhaps in terms of processing time.  But in lieu of that, this may be a solution I can work with!

One of things about this that slightly bothers me is that it might work NOW, but may not in the future if the underlying expression engine changes and breaks it...  again, a dedicated write() function solves that issue.

[mark_h]

Roderick, your method doesn't persist across sessions...?

[RoderickGI]

Roderick, your method doesn't persist across sessions...?

Well, I'm not sure it persists at all based on Zybex's post above. If the counter is being incremented, the expression you are trying not to calculate over and over is being calculated even when it is not required.

The same issue exists if Calculated fields don't actually store the value they evaluate to. I don't know if they do or don't, because I've not seen that documented anywhere. I do know that creating an Expression Column with the expression;
[Calculating Value X,0]
Gives the same result as my calculated field. Which either means that the value is stored, or using that expression triggers a new evaluation of the Calculated field...

And the latter is the case. See the attached image. You will note that the calculated field column on the left has a counter value one less than the Expression Column on the right. I was moving my mouse over the right column. That shows that the two fields are recalculated with the Expression Column being updated immediately after the Calculated field.


That seems to be an inefficiency in the Expression Language. If the expression was evaluated inner to outer brackets, and left to right, the IfElse would have determined that last part of the expression didn't need to be evaluated, and so it shouldn't be. But if the Calculated field doesn't actually store a value, it is always empty, so the whole expression will always be calculated. Also, my experiment above and shown in the image implies any reference to a Calculated field also triggers its value to be recalculated.

Sorry Mark, I think this line of thought is a dead end. My bad. 

[RoderickGI]

BTW, the Ellipsis do have specific meaning in the output of an expression. I'm sure it has been mentioned on the forum somewhere.

However, I just changed my Calculated field back to;
IfElse(IsEmpty([Calculating Value X], 1),[Artist]+[Album])

and the Ellipsis no longer appear. Maybe a restart of MC fixed something.

[mark_h]

No worries.  Always fascinating to see what others can pull off with the expression language in MC!  Thanks for input anyway.

[zybex]

BTW, the Ellipsis do have specific meaning in the output of an expression. I'm sure it has been mentioned on the forum somewhere.

However, I just changed my Calculated field back to;
IfElse(IsEmpty([Calculating Value X], 1),[Artist]+[Album])

and the Ellipsis no longer appear. Maybe a restart of MC fixed something.

The ellipsis means that there are more lines in the output - you're just seeing the first one.
If you accidentally add a newline to the expression, the ellipsis will be there. When you add a RemoveRight() you're removing that newline char(s), making the ellipsis go away. CR+LF = 2 chars, or perhaps you just added 2 blank lines by accident.^(nonsense)

[RoderickGI]

The ellipsis means that there are more lines in the output - you're just seeing the first one.

Indeed it does, but if there was another line, I didn't put it there.

I think there is another meaning though. But it isn't repeatable, so I guess it doesn't matter.

^(nonsense)

 

[RoderickGI]

So what would a field write function look like guys? Perhaps something like;

IfElse(IsEmpty([Saved Value X], 1),Write([Saved Value X], [Artist]+[Album]))

I guess I'm not sure where the requested Write() command would be placed, other than in a Calculated Field. I would guess as long as the Calculated field wasn't included in a View, or the Views it was in weren't opened, and as long as it wasn't referenced in a View that was opened, then it would get recalculated.


Also Mark, I'm interested in how you use the LOCK variables for Smartlists, given how my attempt above failed.

[Hendrik]

So what would a field write function look like guys? Perhaps something like;

IfElse(IsEmpty([Saved Value X], 1),Write([Saved Value X], [Artist]+[Album]))

Note that if something like this were to exist, this would not likely do what you want it to do. The inner expressions always get executed, so your IfElse will not stop the Write from being executed, no matter what the conditions are.
As was pointed out earlier in this thread I believe, expressions are executed from the inside out, which means the Write would actually be the very first function to be executed, right after the fields inside it got resolved to values.

I think that is what makes such an expression rather dangerous to add. Expression is not a programming language, its a markup language, it doesn't follow many of the usual rules actual logic flows would follow, and as such adding something like the "Write" expression suggests that it is something else then it really is. Its purpose is to retrieve and format data for display. Not modify the database itself.

[mark_h]

An example of my lock code:

(([=load(var_view_lock)]=1
            [Media Type]=[audio])
or
([=load(var_view_lock)]=[]
             playlistid==108929911
             [=save(1,var_view_lock,1)]=1))

Pretty easy.  The var_view_lock variable is used as the lock.  If it is set to 0, the smartlist is evaluated and then the lock is set to 1.  If it's 1 then the smartlist is bypassed and the results are simply returned.  Would obviously need to be customised to needs.

You can force reevaluation of smartlist by setting the lock variable to 0.

[mark_h]

Expression is not a programming language, its a markup language, it doesn't follow many of the usual rules actual logic flows would follow, and as such adding something like the "Write" expression suggests that it is something else then it really is. Its purpose is to retrieve and format data for display. Not modify the database itself.

That makes complete sense.  Disappointing, for my needs, but entirely reasonable. 

In the time we've been discussing this I've completely re-engineered my database/smartlists to largely (not entirely) resolve the issues I was struggling with and am content to move on.

[syndromeofadown]

I have so many views now where I have to manually copy this data to keep the information in my database up to date (I typically do this during my import workflow) that being able to do it automatically would be a huge timesaver and would more importantly ensure the correctness of the data within my database at any given time.

Back to the first post. I would greatly benefit from what mark_h is asking for. I also use tag on import but it has limitations. A few off the top of my head:
- I have 14 rename actions for each of my 9 drives just for video
- There are conflicts with embedded tags.
- Having to delete, remove from database, delete xml, re-import, re-scrape, when the data needs updated.(or paste 14 expressions into the tag window)

I think the solution is to add a feature called "Actions".
In the actions gui you can build a list of expressions to be applied certain fields of certain media types.
Basically like doing a tag on import on files already in your library.
It can be set to run in background or with the press of a button. Like auto import.

I would use it for all video and documents since I get all my main fields from the filenames.

I would also use it for audio instead of calculated fields. I have a high end NUC9 as an audio server that runs at a crawl from all of the calculated fields I use. The values could all be written to my custom fields via "Actions" to make everything snappy again.

Please consider.