Print

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

[ADDiCT]

The new Smartlist Editor looks quite promising now, after being close to unusable in the build it was introduced. But why is there no possibility to edit smartlists "the old way"? For long-time users, the old method is much more efficient and transparent than the editor. Is there a chance that an optional "old-style" smartlist editing will be introduced again?

I'm also having some problems with the editor. I have a lot of "History" smartlists. The idea of these is to show tracks, sorted by "Date (year)", and then sorted by "Random". The result was like:
1988 - Track 1
1988 - Track 3
1988 - Track 2
1990 - Track 3
1990 - Track 1
1990 - Track 2
The year order would stay intact, with a new sequence of tracks with every update of the smartlist. I hope this makes sense, i'm having a hard time describing this behaviour (;. These smartlists, however, do not work anymore. If i put both sorting criteria (seperated by a ",") in the modifier field, the second one is ignored. If i add another modifier field, it is silently discarded when closing the editor (not exactly user-friendly). Is there a way to achieve the effect i described?

Edit: i just discovered that there _is_ a way to use "old style" editing. But without reading this on the forum, i would have never clicked on these Import/Export buttons... But still, a second "Sort" criteria is ignored, and a second "Sort" modifier will get deleted silently after i close the editor.

[marko]

this appears to work for me..

[Media Type]=audio ~limit=-1,5,[date (year)] ~sort=[date (year)]-d,[random]

gives me 5 tracks from each year, years remain static, tracks change on refresh. copy the above and paste it into a single, solitary line in the rules section of the editor.
After pressing OK, open the customise current view dialogue and in the sorting section, load the 'empty' preset. press OK
The results should now be as expected. click the edit button to see how the editor has broken the string down.

-marko.

[ADDiCT]

Marko, thanks for you answer! The smartlist example you gave looks like it's working like it should.

But the smartlist i'm trying to get to work is a little more complex, it looks like this:

[Media Type]=[Audio] [Genre]=[Computer] [Rating]=>3 [_style_track]=[comp_mod] [_dupe]=<=1 -[Date (year)]=[] ~sort=[date (year)],[random]

This still doesn't work for me. Could you please verify this by trying something similar? I get the feeling there might be a bug in the smartlist engine, maybe because of too many parameters, or because i'm using custom library fields (the fields starting with "_").

Thanks for your help.

[marko]

Could you please verify this by trying something similar?

Before I do that, could you try something for me first...

Looking at your string, I think it's worth checking out whether it's the square brackets in the data that are confusing the issue...

"[_style_track]=[comp_mod]"

first. I tried placing [test] in a few comment fields here and got some pretty iffy results using the editor. The only way it worked was to use the "Comment is ..." setting, and pick [test] from the drop-down list. Using any of the other options, "comment contains test" for example, returned zero results, and upon relaunching the editor, the comment rule had been stripped away.

Other trouble shooting questions:
1st, what's not working. Is it just the sorting that's busted?
If the file list is empty, or includes every file in the library, you need to identify which rule is breaking things.
Set your ~sort rules first, then start at the top and work down...

[media type]=audio - yes/no?
g=[computer] - yes/no?
r=>3 - yes/no

etc. etc.. until it breaks.
at what point does it break?

-marko

[gappie]

i just pasted your line into the editor the way marko said. closed the editor and started it up again. had to change your custom fields to custom fields i use. and it worked for me.
just a guess: were there still rules with Custom before them. if so: have you tried to addapt them to the new editor.

[ADDiCT]

Ugh, this is getting complicated... (;

Some quick remarks for now:

Using any of the other options, "comment contains test" for example, returned zero results, and upon relaunching the editor, the comment rule had been stripped away.

This is not expected behaviour, is it? The "contains" function should work as in "pre-editor-versions", and stripping away criteria because MC doesn't like them (or whatever) should not happen. I believe both effects can be considered bugs.

1st, what's not working. Is it just the sorting that's busted?

Sorry, i should have been more precise. The list itself is working OK, i get the tracks i want. Sorting by "date (year)" is done, but the second modifier "random" is ignored. This basically means i'm getting the same list with every smartlist update, as the "random" modifier is not applied.

Gappie:

just a guess: were there still rules with Custom before them. if so: have you tried to addapt them to the new editor.

I'm not sure i understand what you mean. From what i understand, the "old" smartlists should work in recent MC versions, as the syntax itself hasn't changed - it's just the editor that got added. I might be wrong about that, though - i didn't have time to read all the changelogs of recent versions.

I'll do some more testing later on, thanks for the replies guys! I hope we can identify the cause of this weirdness.

[gappie]

Sorry, i should have been more precise. The list itself is working OK, i get the tracks i want. Sorting by "date (year)" is done, but the second modifier "random" is ignored. This basically means i'm getting the same list with every smartlist update, as the "random" modifier is not applied.

have you rightclicked on the list view settings>customize current view. look there and see if 'sorting' is empty.

[ADDiCT]

have you rightclicked on the list view settings>customize current view. look there and see if 'sorting' is empty.

I think you mean the area that shows the "back - forward - refresh" icons, and the name of the smartlist. The "Sort" submenu is on "Default", so this shouldn't be the problem. I also tried "customize current view", and removed all sort criteria - didn't help, either.

For testing, i've just created a new smartlist from scratch, with the following criteria:

Code: [Select]

[Media Type]=[Audio] [Genre]=[Computer] -[Date (year)]=[] ~sort=[date (year)],[random]
Even this simple smartlist gives me the same results with every refresh - the "random" modifier is not applied. Note there are no custom fields in this string. I even tried switching the "date" and "random" modifiers, and that gave me the exact same results with every refresh, too. Replacing the "-[Date (year)]=[]" with a specific entry did not make any difference (besides showing me tracks with the specific date tag, of course).

Marko, your first example smartlist is quite different from what i'm trying to do, because of the "limit" modifier. Could you try something close to that i'm trying to achieve? Like, getting all tracks with certain criteria (genre, date - it doesn't seem to matter which field you're using), and sorting these by date/random?

Btw, i'm using 12.0.203 (of course).

[gappie]

I also tried "customize current view", and removed all sort criteria - didn't help, either.

that is what i ment, and it should be empty.

[marko]

Are you sure that this is how your strings were constructed in pre-editor builds?

I've kind of let the new editor get in the way of clear thinking, and you know, I'm pretty sure that using [random] in this manner won't work.

To backup my hunch, I fired up my old test machine which still has build 130 installed and tried the following string:

[Media Type]=audio -[date]=[] ~sort=[date (year)],[random]

and it doesn't work as you expect. it only sorts by year, (and yes, the <empty> sort preset was loaded) suggesting that if something did get broken, it's been broken for quite a while now.

*I think I have a solution for you. I'll post back after tea

[marko]

there you go:

[Media Type]=[Audio] [Genre]=[Computer] [Rating]=>3 [_style_track]=[comp_mod] [_dupe]=<=1 -[Date (year)]=[] ~limit=-1,-1,[genre] ~sort=[date (year)]

try that. any better?

[ADDiCT]

Hey Marko, i'm very confused. My smartlists were working until the new editor was introduced - believe me, i have ~30 of these smartlists, and all of them were doing what they were supposed to. The thing is, i can't verify this with new MC versions, because MC will change the smartlist when i open it.

Anyway, your last example does exactly what i want. But i don't fully understand what the "~limit=-1,-1,[genre]" does. Could you explain that a little?

I'm still quite sure there is something highly illogical going on. I believe your smartlist is kind of a workaround, but not a solution to my problem. At the time i read the documention, in order to create my smartlists, the docs were saying the sorting criteria would be parsed one after the other. That seemed very logical to me, and it did work. But now, the second sort criterion is simply ignored, no matter what i do. Do you believe this could be a bug?

I also don't understand why your smartlist gives random results. From reading the code, one would assume that the result would be ordered by "date (year)", as this is the only sort criterion.

If a developer reads this, it would be very interesting to get feedback about the topic. What's with a second (and third, fourth, etc.) sort criterion? Isn't MC supposed to parse all criteria, and apply them one after another?

[marko]

I do believe you. All I can say is that it hasn't worked that way since at least build 130

Isn't MC supposed to parse all criteria, and apply them one after another?

That's the general theory, yes. It's kind of what's happening in the string above...

What I did to reach your goal was take this part (which gives you all of your desired files) ...
[Media Type]=[Audio] [Genre]=[Computer] [Rating]=>3 [_style_track]=[comp_mod] [_dupe]=<=1 -[Date (year)]=[]

Then apply the ~limit modifier. The preceding rules stated that all files must have the [computer] genre, so we already know that all of the genres returned are the same. The ~limit modifier returns a random set of files, so if for example we'd asked for 10 files that matched the [genre], it would pick 10 at random. By using ~limit=-1,-1,[genre] we're telling MC to return all files of all genres, ie, not actually limiting anything at all, but, as the default behaviour of the ~limit modifier is to shuffle the results, that's where we get the random element from. So long as there are no sorting rules in the customise current view dialogue, the only sort rule being applied is the [date (year)] specified in the search string...
~limit=-1,-1,[genre] ~sort=[date (year)]

So, the list is sorted by Year and nothing else meaning that the random element is retained. All files from 2006 are still grouped together, while the ~limit modifier takes care of shuffling their order.

Clear as mud, I know, I try, but clear explanations are not a forte of mine.
With regards to whether or not there's a bug in the system, I'm not sure. If you feel strongly that there is a bug, post it in the bug thread, and feedback will come sooner or later. Try not to get overly frustrated mind you, I have a list of stuff here that I consider to be bugs, or highly illogical behaviour, that have been deemed "by design and not in line for review any time soon".

-marko.

[ADDiCT]

OK, thanks very much for the explanation - i think i understand what you're saying, all mud aside. (;

I do consider this behaviour a bug, and i'll try reporting it. I also have a list of "strange effects" that are considered "by design". Let's just hope that, one day, JRiver will decide to fix MC instead of implementing one new feature after the other. This may sound a little harsh, but i honestly do not see the benefit of many of the new features. For a company with limited manpower, i believe it would be wiser to concentrate on quality control, instead of trying to stuff all features one can think of into the software. Well, i guess MC is _really_ something special, in more than one term. (;

Anyway, thanks again for the help, marko.

[marko]

You're welcome.

I think one of MC's problems is that one mans bug is almost certain to be another's eutopia ....
It's a balancing act I don't envy...