Print

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

[locust]

Hi, one last request for the day.

I love calculated fields and also global expressions. I find, it can become very cumbersome on the system and can slow mc down a lot.

Some calculated fields and especially global expressions and only made for specific views and they still slow other views down.

I have a couple of views where I use custom fields and sometimes global expressions to get around the fact it isn't a relational type database, to calculate and store values for other views to use. The custom fields regardless still slow my system down, to a point, where I've thought of cloning the library and having an expression view scheme heavy library to calculate values and update tags for an expression light version of library to use.

I was wondering if it could be possible to have calculated data flag types conjoined to view scheme tree image types, i.e. scheme, scheme group, audio, image, video, cd, folder.

We can already segregate a custom field and it's expression to either or a combination of audio, image, video, data, tv.

Although they aren't the same as in those are media types and the flags I propose are view scheme types, i.e. scheme, scheme group, cd & folder. Although the scheme group types still contain the media group types apart from data & tv.

Extending the flag type functionality would as I understand, allow flagged custom fields with expressions to only be asserted on the flagged types and invisible to the rest, either media types and or flag view scheme types. It would allow a much more efficient building of view schemes regarding custom views containing expressions, therefore I imagine a much less sluggish system due to those expressions.

I've thought about going down and trying only to use smart lists, as for instance, and I don't know why but a smartlist search list using IsMissing(), is so much faster than using the same expression in a pane expression. But not everything as I understand it can be done expression wise in smart list, arch lists or is difficult to achieve, in ease of writing expressions as to pane expression.

If I've got my facts right, I think this could be a very useful feature to have, and it seems like there's not much change in scope of coding and the groundwork for flags is already there. I hope it's possible. thanks

[zybex]

I'm not sure what you mean by "scheme, scheme group, cd & folder", perhaps a screenshot would help.

You asked for something similar here, and if I understand your idea correctly the reply would still the same: this would not really help as calculated fields are only calculated on access; if you don't need them for a given View, then don't reference them; if they are needed for that View then they will be calculated for each file in the View. Flags would not help there.

Here's an alternative: I released a new tool called ZStats that can be used to pre-calculate an Expression and store it to a field in MC (for all files or just a subset). If you don't need real-time results you can schedule the tool to run nightly/weekly to update the value of one or more fields that you need for your views, instead of having the expression run when you open the view. ZStats also generates some playlists and statistics, but you can disable that part if you don't need it:
https://yabb.jriver.com/interact/index.php/topic,131845.0.html

[locust]

I just mean by the assignable icon type that can be applied to any view. For the most part it's essentially like a pseudo media type with a few additions.

Yeah them being calculated on access, well right now we can flag a custom field with it's calculated data to on calculate on access, if the media sub type of a view scheme is set to audio or video, etc.



Having an extra flag field, I guess we can forget about flagging, Audio, Image, Video, Data & TV, as the goal in mind is already achievable for those subsets with media type flags. The addition of being able to flag scheme, scheme groups, CD and folder view scheme types in a custom field, even though they aren't media types would add an extra layer to being able to sub divide calculated fields and where and which they operate on access.

Like audio for instance. I have a custom field that does some things with Artist, Album artist and a custom remixer field I made, populated on a per track basis. I can't explain how it works the best of the top of my head now, MrC helped me and well, I asked and he created view schemes with regex and global variables, with and using custom fields to hold some calculate data. Amongst other calculated fields I've made specifically for certain views. Well it's to my understanding. If a calculated field is ascribed and flagged to audio only. Then such calculated data will never execute on any view where the media type is set to video only.

Although for every view scheme flagged to audio only, that calculated field to my knowledge, is calculated and labour intensive depending on how complex the expression is, if it dynamically updates somehow from other input or calls upon another field or calculated field, in that in every audio view, regardless if that field is used in an expression or category pane, I think it's still accessed and calculated? As it is accessible and can be seen in the tagging window. Does that not mean it's being accessed, on opening of a view?

So being able to ascribe flags for certain custom fields to lets say, they only appear in the tagging window and calculate their expression on access for a view scheme with the image type set to scheme or scheme group. It would allow partial redesign in my library. I could assign maintenance type views, which could utilise maintenance only custom calculated fields, which wouldn't ever slow down the on access time of opening another view that isn't a scheme group, as the calculated field will never be populated unless I actively open the maintenance views.

Maybe I've misunderstood some integral operations of the program itself. Wouldn't be the first time.

Actually that you mention it. I recently been perusing github. Believe it or not, I downloaded your ZStats today before seeing this, I haven't used it yet. I'm not a programmer but I love computing and programming, in that I wish I could program. I studied computer networking at college level got into third year at university for networking, but the difference between college and university here in Scotland is stark in that college is closer to a school than it is university. So when I started in third year, mind you I come from a rural remote village, the contrast in enormity of size of the camput and location compared to what I was used to, I didn't like it. So I didn't stick it out.

It was a bit overwhelming and I felt underprepared in that, what was taught in the latter years of college leading into third year at university, what we had been learning as opposed to what we were expected to already know was nothing alike. I felt I should have just started at first year university rather than the college route and I should have chosen programming. No disrespect to networkers, but programmers, might not be doing the manual graft of networkers but they still know the ins and outs the networking technology, as for most programs, having grasp of computer networks is needed, especially when programmatically developing for networking itself. Generally and mostly those in the field of networking, don't need to know anything about programming.

I've recently just started to get the grasp of github a little, in understanding, as before I never saw the wood for the trees. In that the software github contained, I focused on that, I never really paid much attention to git itself. It's pretty remarkable in that although it's made for coding, it can be used for so many things. Like it may be overkill bit imagine having historical git like operations in MC itself. Being able to record the progression of a media library over time, view a historical graph, rewind to any point. Branch off and merge branches later on, working probably solely on sidecar files rather than the media itself as the git repository would swell with media. But for reversing file naming operations to any recorded point in the libraries history could be useful.

There so many cool projects on GitHub though, I'm finding myself hard pressed for time in exploring there and learning. I'm currently experimenting with Rclone and the first ever program I actually complied from source. rar2fs. But with rclone, I'm setting up remote mounted drives that are stored in RAM. I don;t know how stable it is but I'm considering setting the cache of many a program I use to use a RAM drive, so that it reduced the wear and tear on my physical drives.

[zybex]

Well, as long as you're doing what you love to do, anything is fine

Showing any given field on the Tag window doesn't slow a View because the Tag panel content is just populated when you select an individual file, calculating only the field contents for that single file. What slows down a View is the view definition for filters and grouping; to generate the list of files that will be part of the view, MC needs to go through ALL files in the library to check which ones pass the filters, then group the remaining files according to the grouping settings. If the filter/group definition include expressions or calculated fields (directly or indirectly) then they will be calculated for ALL files during the filtering phase, and for all filtered files during the grouping phase. This is what takes a long time. If you can use static fields instead of the Expressions/calculated fields then the view is much faster. Field flags won't really help - as long as a field is referenced, it will be calculated regardless of flags.

I make some assumptions regarding MC internal workings here, but it's unlikely that the process is much different from what I've outlined.