If you think that you found a bug in Magic Nodes, you should:
1. make sure that you are using the latest available version;
1a) if you are using the enhanced version, please specify its full version including the build number;

2. post the full mask that causes the issue (it could be found in the Mask text box on the bottom of the Mask Settings dialog box);

3. try to be detailed and precise how to reproduce the problem;

4. post the screenshot with the error message containing the line number in the script (if it shows up), and/or the screenshot of the selected node that causes the issue with the visible filelist.

By the way, the Magic Nodes add-on doesn't have the auto-refresh feature, not for the filelist and especially not for the Media Tree. Maybe that sounds like a nice idea to be implemented in the add-on, but there are many Magic nodes that execute a very complex SQL code, which takes a quite long time, and it will be terrible if users need to wait to see refreshed filelist and/or Media Tree whenever they change any metadata in any displayed file.

You need to collapse/expand the parent node in the Media Tree to see refreshed its child nodes.

Need some help.

I copied metadata from one record to an other and no magic nodes is acting strange on those records.

In het magic node of lyricist/screenwriter, if have a node with a name that's used in the director field.
It even has files under the node while the fields lyricist and screenwriter have a different value than the node.

Thanks for your kind words. :)

[quote=ZvezdanD post_id=476990 time=1610817319 user_id=4223]
I will replace it with Upper in the next version and you will not have out-of-memory errors anymore. The only issue will be if you use any non-ANSI character in [i]Split By, Left Of, Right Of[/i] or [i]Right Until[/i].
[/quote]
Most excellent, great catch. Again appreciate your hard work on this plugin (and all your others). It is a genius piece of work, I truly cannot imagine organizing my music without it. :D

[quote=benfucius post_id=476944 time=1610753438 user_id=105480]
I've made a number of optimizations to my masks across the past few days, things are working much better now. I also came up with a workaround to the issue in my first post a few days ago.[/quote]
Yeah, that is what I mentioned in the "Split examples" section:
"... This is the nice trick to know if you need to use Split part qualifier with large values and some of String * arguments, since if you use Right of you could decrease the Split part value and avoid generating of the error message."

However, it turned out that the real reason for those errors is not the complexity of SQL queries generated by the script, but MM's UpperW function that was used in queries. I will replace it with Upper in the next version and you will not have out-of-memory errors anymore. The only issue will be if you use any non-ANSI character in [i]Split By, Left Of, Right Of[/i] or [i]Right Until[/i].

Discogs|Child of:Playlists|Show tracks:No\<Path|Exclusive right of:Library\|Split by:\|Split Mode:Single Part|Split part:2|Filter:<Folder> Like '% @%'>

Well that now makes a lot more sense, I had read that on your page before but didn't quite understand how complex it can get. So I will stick with Single wherever possible. Thanks for clearing that up.

I've made a number of optimizations to my masks across the past few days, things are working much better now. I also came up with a workaround to the issue in my first post a few days ago. This uses what I've learned about Split to pull out the Discographies (marked by an @ symbol at the end of the folder name) on a specific folder-level where they would reside. Works fast and very low RAM cost!

[code]Discogs|Child of:Playlists|Show tracks:No\<Path|Exclusive right of:Library\|Split by:\|Split Mode:Single Part|Split part:2|Filter:<Folder> Like '% @%'>[/code]

[quote=benfucius post_id=476930 time=1610740245 user_id=105480]
I am noticing a huge difference when using "Single Part" vs using "String Part".

I can create a mask as a Magic Node, or as a child of Playlists, doesn't matter where, as "Single Part" and the RAM of MediaMonkey rarely grows above 10%, never above 1gb.

However, if I change that same mask, only the very last node change Single to String Part, leaving everything else the same, and within a minute or two MediaMonkey will have consumed all of it's RAM and crash/freeze.

(Ideally I would use String Part on the last subnode of my masks, so that I can utilize Sort, which cannot be done with Single Part).
[/quote]
Here is the excerpt from the Usage section:
"The Split mode combo box has the next items: String part, String Before, String After, Single Part, Parts Before, Parts After, All Parts, Categories, Odd Parts and Even Parts. The first three items that start with the "String *" don't affect the enabled state of other controls in the dialog box because they are based on the SQL code to do parsing of the MN field, but [b]the complexity of the implemented code raises exponentially with the Split part value specified with the spin box, and for the large numbers you could even get the error message![/b] The remaining items from the Split mode combo box don't have that problem since they are not using the SQL code, but VBScript instead. However, the drawback of the remaining items is that they cannot be used with the Sort by/Statistics qualifiers as well as almost none of the Show * qualifiers."

[b]It doesn't matter if you use "String Part" only on one node. Its complexity determines the "Split part" number specified after it.[/b]

Here is the node field for Split part:1 with "String Part":
SubStr(Medias2.DriveStr || Songs.SongPath, 1, InStr(UpperW(Medias2.DriveStr || Songs.SongPath) || '\', '\') - 1)

Here is the node field for Split part:2 with "String Part":
SubStr(SubStr(Medias2.DriveStr || Songs.SongPath, InStr(UpperW(Medias2.DriveStr || Songs.SongPath) || '\', '\') + 1, 9999), 1, InStr(UpperW(SubStr(Medias2.DriveStr || Songs.SongPath, InStr(UpperW(Medias2.DriveStr || Songs.SongPath) || '\', '\') + 1, 9999)) || '\', '\') - 1)

Here is the node field for Split part:3 with "String Part":
SubStr(SubStr(SubStr(Medias2.DriveStr || Songs.SongPath, InStr(UpperW(Medias2.DriveStr || Songs.SongPath) || '\', '\') + 1, 9999), InStr(UpperW(SubStr(Medias2.DriveStr || Songs.SongPath, InStr(UpperW(Medias2.DriveStr || Songs.SongPath) || '\', '\') + 1, 9999)) || '\', '\') + 1, 9999), 1, InStr(UpperW(SubStr(SubStr(Medias2.DriveStr || Songs.SongPath, InStr(UpperW(Medias2.DriveStr || Songs.SongPath) || '\', '\') + 1, 9999), InStr(UpperW(SubStr(Medias2.DriveStr || Songs.SongPath, InStr(UpperW(Medias2.DriveStr || Songs.SongPath) || '\', '\') + 1, 9999)) || '\', '\') + 1, 9999)) || '\', '\') - 1)

and so on...

Here is the node field for Split part:1 with "Single Part":
Medias2.DriveStr || Songs.SongPath

and it is the same for Split part:2 or for Split part:3 or any other number.

And that is just a SQL code for the caption of node that is displayed, but there is also the hidden statistical field that is necessary for each node to correctly show if it could be expanded or not:

Split part:1 with "String Part":
Count(DISTINCT NullIf(SubStr(SubStr(Medias2.DriveStr || Songs.SongPath, InStr(UpperW(Medias2.DriveStr || Songs.SongPath) || '\', '\') + 1, 9999), 1, InStr(UpperW(SubStr(Medias2.DriveStr || Songs.SongPath, InStr(UpperW(Medias2.DriveStr || Songs.SongPath) || '\', '\') + 1, 9999)) || '\', '\') - 1) COLLATE IUNICODE, ''))

Split part:2 with "String Part":
Count(DISTINCT NullIf(SubStr(SubStr(SubStr(Medias2.DriveStr || Songs.SongPath, InStr(UpperW(Medias2.DriveStr || Songs.SongPath) || '\', '\') + 1, 9999), InStr(UpperW(SubStr(Medias2.DriveStr || Songs.SongPath, InStr(UpperW(Medias2.DriveStr || Songs.SongPath) || '\', '\') + 1, 9999)) || '\', '\') + 1, 9999), 1, InStr(UpperW(SubStr(SubStr(Medias2.DriveStr || Songs.SongPath, InStr(UpperW(Medias2.DriveStr || Songs.SongPath) || '\', '\') + 1, 9999), InStr(UpperW(SubStr(Medias2.DriveStr || Songs.SongPath, InStr(UpperW(Medias2.DriveStr || Songs.SongPath) || '\', '\') + 1, 9999)) || '\', '\') + 1, 9999)) || '\', '\') - 1) COLLATE IUNICODE, ''))

and so on...

And that is just for the Path field, but for the Folder field things are even more uglier.

[quote=ZvezdanD post_id=476838 time=1610617419 user_id=4223]
Anyway, I think that I managed to reproduce the issue and I will see if I could implement a workaround for it.
[/quote]

Just to reiterate here for clarity, hopefully there is some knowledge or solution within this. I am noticing a huge difference when using "Single Part" vs using "String Part".

I can create a mask as a Magic Node, or as a child of Playlists, doesn't matter where, as "Single Part" and the RAM of MediaMonkey rarely grows above 10%, never above 1gb.

However, if I change that same mask, only the very last node change Single to String Part, leaving everything else the same, and within a minute or two MediaMonkey will have consumed all of it's RAM and crash/freeze.

(Ideally I would use String Part on the last subnode of my masks, so that I can utilize Sort, which cannot be done with Single Part).

Whole Library|Icon:Top level|Child of:Playlists|Position:Child\<Path|Unknown:No|Exclusive right of:Downloads\|Right until:\>\<Path|Split by:\|Split Mode:Single Part|Split part:5>\<Folder|Split by:\|Split Mode:Single Part|Split part:6>\<Folder|Split by:\|Split Mode:Single Part|Split part:7>

[quote=ZvezdanD post_id=476879 time=1610657610 user_id=4223]
Well, in such case I suppose it would be better to use Folder instead of the Path field. You could try the predefined mask "Drives & Folders (string part)": replace Path with Folder and, if you don't want Sort/Stat, you could replace Split Mode:String Part with Split Mode:Single Part to get faster nodes.
[/quote]
You and your addon never cease to amaze. I'm sure you had probably thought of this before.

I just tried that predefined mask, both as default and with your change suggestions.

Default: I can only make it navigate down 5 levels before MediaMonkey fills the RAM again, and it freezes/crashes. Similar to my original post. Perhaps it is the the size of my library that is causing this issue across masks that dig deeper than ~5 levels.

Changed String Part to Single Part + Changed Path to Folder: It is slower, but very interestingly the RAM goes up a bit while processing, [u]and then falls back down again[/u] to ~80mb. I haven't seen this behavior anywhere else using your addon. It seems to be the change to "Single Part", as I changed one node back to "Split Part" and the RAM fills up substantially more. However with "Single Part" I can use Folder or Path and MediaMonkey RAM usage always falls back after it finishes processing the currently selected node. This is the same for populating as either a Magic Node, or as a Playlist. I can definitely use this.

Edit: Working mask as follows. I modified the one you mentioned so that I can specify a certain folder as the root (using Exclusive Right Of), then using only Split Part subnodes for the subfolders.
[code]Whole Library|Icon:Top level|Child of:Playlists|Position:Child\<Path|Unknown:No|Exclusive right of:Downloads\|Right until:\>\<Path|Split by:\|Split Mode:Single Part|Split part:5>\<Folder|Split by:\|Split Mode:Single Part|Split part:6>\<Folder|Split by:\|Split Mode:Single Part|Split part:7>[/code]

[quote=benfucius post_id=476871 time=1610650467 user_id=105480]
[u]I want to restrict the nodes to only Folders, to exclude Files as nodes.[/u] Any idea how to use any functions like Split, etc to remedy this?
[/quote]
Well, in such case I suppose it would be better to use Folder instead of the Path field. You could try the predefined mask "Drives & Folders (string part)": replace Path with Folder and, if you don't want Sort/Stat, you could replace Split Mode:String Part with Split Mode:Single Part to get faster nodes.

<Path|Unknown:No|Exclusive right of:(path specific)|Split by:\|Split Mode:String Part|Split part:1,2,3,4,5 (depending on node level)

Separate related topic:

I'm learning more about Split, reading your documentation on it (from the older MN version page) today. I am wondering if there may be some ways to use Split instead of needing symbols in my folders for Right Of uses (+,~,=,etc)

Edit: Read and tested, think I've found a way to get rid of the symbols in my folder names.
[code]<Path|Unknown:No|Exclusive right of:(path specific)|Split by:\|Split Mode:String Part|Split part:1,2,3,4,5 (depending on node level)[/code]

This seems to work similarly to having hard-coded symbols to differentiate the folder levels, but is more elegant in that it simply shows the folder that corresponds to the level depth. i.e. it mirrors the folder structure as nodes.

[u]Use case[/u]: A folder 3 levels deep is where I add new "unorganized" music. I set the [b]Exclusive right of:NewMusic[/b], and then subnode(s) as copies of this mask, but increasing the [b]Split part:[/b] up by one increment, down through to the end of the folder levels. This would effectively "pull out" this folder tree as a MN or Playlist unto itself, making it easier to access directly without needing to first navigate down 3 levels to reach "NewMusic", and also easier for syncing to the phone.

[u]Issue/Question[/u]: If in a folder there are two folders, one has songs directly within it, and the other has more folders within it, using the above mask the nodes build out to include the song names in the nodes for the more shallow folders. This is if using either Path or Folder. Example below:

{Playlists} ~
|----[Rock] #
|--------All for Metal
|------------Song 1
|------------Song 2
|----Classical Essentials
|--------Song 3
|--------Song 4

Turns out like this using my above mask:
[img]https://i.imgur.com/HwvtbLd.png[/img]

[u]I want to restrict the nodes to only Folders, to exclude Files as nodes.[/u] Any idea how to use any functions like Split, etc to remedy this?

[quote=ZvezdanD post_id=476838 time=1610617419 user_id=4223]
Thanks for the detailed report. My suggestions was intended just to locate the source of the problem, not to force you to use them permanently.

Anyway, I think that I managed to reproduce the issue and I will see if I could implement a workaround for it.
[/quote]
No worries, I wanted to be sure I was clear in my responses to you. Happy to try anything you suggest. Thank you for taking the time to understand!
[quote]
By the way, the Magic Nodes' Path field is almost the same as the database field from the Songs table, with the addition of the drive letter taken from the Medias table. However, the MN's Folder field doesn't have a corresponding database field, but it is parsed from the Path field. So, when you apply any of the parse qualifiers as Right Of on it, you are basically double parsing the same data, which is why it is slower than Path.
[/quote]
This is interesting, it fully explains why this phenomenon was occurring in my nodes. I switched some uses of Folder to Path in my other nodes, and they do refresh much faster now.

[quote=benfucius post_id=476800 time=1610560175 user_id=105480]
I have just tried this as a Magic Node instead of a Playlist, and it does work without MM crashing. I expected this. However, my goal is to create this as a Playlist,[/quote]
Thanks for the detailed report. My suggestions was intended just to locate the source of the problem, not to force you to use them permanently.

Anyway, I think that I managed to reproduce the issue and I will see if I could implement a workaround for it.

By the way, the Magic Nodes' Path field is almost the same as the database field from the Songs table, with the addition of the drive letter taken from the Medias table. However, the MN's Folder field doesn't have a corresponding database field, but it is parsed from the Path field. So, when you apply any of the parse qualifiers as Right Of on it, you are basically double parsing the same data, which is why it is slower than Path.

:[Discogs]:|Icon:31|Show tracks:No|Filter:<Path> Like 'E:\Music\Library =\%' AND <Path> Like '%@~%'|Child of:Playlists|Position:Child\<Path|Unknown:No|Right of:+\|Exclusive right until:@~\>\<Path|Unknown:No|Right until:\|Right of:@~\>

[quote]
Did you try the same mask outside of the Playlists branch, e.g. inside the Magic Nodes folder?
[/quote]
I have just tried this as a Magic Node instead of a Playlist, and it does work without MM crashing. I expected this. However, my goal is to create this as a Playlist, due to the limitation of MediaMonkey that the Android app will not access (and therefore) sync any music files from the Magic Nodes branch. I must create them as Playlists to access and sync to my phone. Such is the pain necessitating Playlist nodes. Unless you know of a better way?
[quote]
Why are you using the Filter string on the local level of mask (for the HAVING part of the query), when it is intended for the WHERE part of the query? Did you try the same Filter to apply on the global level of mask?
[/quote]
Yes, I've tried both, same result. I always do my testing in Magic Nodes node first, since it is faster, and then when I am sure the filters work, I change it to a Playlist child node.
[quote]
In the first post you said that you have two local levels, one for artist and another for album, but the mask contains only the first local level. Do you have the same issue with this mask?
[/quote]
Apologies, while I was trying to fix it, I mistakenly posted a redacted version of the mask yesterday. I'll post the correct mask at the bottom of this post, including edits following your suggestions.
[quote]
In the first post you said that you are using Right Until, but the mask has Exclusive Right Until. Do you have the same issue with both of them? What happens if you use Exclusive Right Of instead of Right Of?
[/quote]
Yes I just tried both. The result with non-exclusive is that I get all artists (both @~ and ~). My goal is to show only @~ in this particular playlist, because these are the ones I have full discographies of. Using exclusive produces exactly what I want to see, before it ends up crashing MM.
[quote]
What happens if you replace '%@~%' in the Filter with '%@@~%' (since the "@" is an escape character for the SQLite LIKE operator)?
[/quote]
I've just tried this too, it seems to break it, I get an error "Magic Node produced an error". However, my original issue is not that I get incorrect information; my mask works correctly. It causes MM to fill the RAM.
[quote]
Why do you use filtering by "@~" in the Filter when it is already applied by the Exclusive Right Until? The Exclusive Right Until (and all other parsing qualifiers) has the effect to the all level of the mask, not only on the level where it is specified.
[/quote]
I have now removed the second Exclusive Right, so that only the first/root one exists. I've tested the original issue, and it still occurs the same.
[quote]
What happens if you use Path instead of Folder?
[/quote]
I tried switching all instances of "Folder" to "Path" in the mask, and interestingly Path processes nodes faster than Folder, however this also means that the RAM fills up much faster (~3 minutes instead of the 15 or so with Folder). So I switched all Path to Folder to see what the difference might be. It runs slower overall, but produces the same end result.

A quick video I made of the RAM filling, sped up 3x:
https://imgur.com/FXKjgea

A still image of the crash:
[img]https://i.imgur.com/1TgJKw8.png[/img]

The issue, from where I stand, seems to be that when Magic Nodes is populating Playlist child nodes, MediaMonkey will store all this data into RAM. MediaMonkey does not empty or cleanse it's RAM at any point, it keeps it all in RAM. After some time of populating a Playlist node that filters through ~8,000 subfolders, the RAM fills to the 3.5gb limit of a 32-bit application, and crashes.

[b]Question: Would it be possible to tell/force MM to clean it's RAM storage between node populations, or at all?[/b]

My current mask, including your above suggestions. Produces the same end result as my original post.
[code]:[Discogs]:|Icon:31|Show tracks:No|Filter:<Path> Like 'E:\Music\Library =\%' AND <Path> Like '%@~%'|Child of:Playlists|Position:Child\<Path|Unknown:No|Right of:+\|Exclusive right until:@~\>\<Path|Unknown:No|Right until:\|Right of:@~\>[/code]

[quote=benfucius post_id=476772 time=1610491058 user_id=105480]
[b]Mask:[/b]
[/quote]
Did you try the same mask outside of the Playlists branch, e.g. inside the Magic Nodes folder?

Why are you using the Filter string on the local level of mask (for the HAVING part of the query), when it is intended for the WHERE part of the query? Did you try the same Filter to apply on the global level of mask?

In the first post you said that you have two local levels, one for artist and another for album, but the mask contains only the first local level. Do you have the same issue with this mask?

In the first post you said that you are using Right Until, but the mask has Exclusive Right Until. Do you have the same issue with both of them? What happens if you use Exclusive Right Of instead of Right Of?

What happens if you replace '%@~%' in the Filter with '%@@~%' (since the "@" is an escape character for the SQLite LIKE operator)?

Why do you use filtering by "@~" in the Filter when it is already applied by the Exclusive Right Until? The Exclusive Right Until (and all other parsing qualifiers) has the effect to the all level of the mask, not only on the level where it is specified.

What happens if you use Path instead of Folder?