OK, this is an odd example, but Illustrates what I'd like to do. Everything I do is geared towards theatre view.
I have a field called Disc, which I use for audio albums, where there are multiple disks, or I want to create mutiple "disks", within an album. So for an album with a bonus disk, I only want one master title to be seen, but when you select it, you see both disks individually. Can be done with just Disc #, I hear you say, but I like to make life difficult, and I have alphabetic values in the disc # tag. (I do most of my tag editing outside MC, with MP3TAG). So instead of just "1", I may have "1 Original Album". I don't use it much, but I've just downloaded a 12 disk Paul Weller album........
You could argue that as I've got to edit the fields anyway, I should just create a new field, but most albums with Disc # values are simply 1, 2 etc, and I never touch them, so I looked for a way of achieving the best of both worlds. One more compliaction though, and this is very Theater View specific, using the Album/Disc structure in queries a bit of a mess. Most albums have no Disc # tag, so when a query with Album/Disc tries to show the tracks, it correctly identifies that there is a single, and in this case, blank, value, so does not show a Disc selection screen, and drops down to the tracks. But the title at the top of the screen, doews not show the album tag, but the disc # tag, which unfortunately reads "Unassigned"
So, eventually getting to the point, I created my new calculated field called Disc, which originally looked like this
if(isempty(tag(Disc #)),[Album],tag(Disc #) (don't worry about the syntax..)
Why tag? Strangely, this brings in the alpha value of the tag on the file, ignoring the fact that MC thinks Disc # is numeric.
This then gives me in the new field either the Disc #, if there is one, or the Album name.
It wasn't until recently that I saw the performance warning about using tag(...) so preferably I'd like to get rid of this. And tag(...) does not work in a client installation as it cannot get to the original file.
So, the options I started to play with.....
1. Use a modified version of my expression, without the tag(...) on the server, and pass the value to the client. Problems 1) Without the tag(...) the expression only picks up a numeric value, and 2) the value doesn't get passed to the client anyway, only the expression.
2. Create a new string field which is updated by a batch command on the server. I'm happy to take the performance hit of using tag(...) if it's running in the middle of the night, or on demand. The value would then be passed to the client (I assume).
It's a bit of a daft example I know, but it illustrates what I'm playing with.
One final question, you say that the the client downloads a temporary copy of the server library. How and when are changes to the server library itself reflected in the temporary copy. One of my ongoing issues with my MC14 installation is that new files (on the server) don't seem to be picked up, and I have to manually run the import. I was hoping that the server copy would pick up new files automatically, and that the client would somehow know they were there. Initial testing suggested that the client is unaware of changes to the server library, and that you can't even manually run an auto-import. I had not gotten very far with that, so I was hoping that there was something I hadn't set up yet. Your comment worried me.