Print

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

Yes. Even though I understand why it behaves the way it currently does.

Yes. I've never understood why it needs to behave the way it currently does.

No. Please don't change it. I find its current behaviour invaluable.

[marko]

In MC's "Help" file, the Full Album (~a) modifier is not listed in the "Special Modifiers, Functions and Expressions" table, which pretty much hides the fact that ~a is probably the most 'special' of all search modifiers due to the fact that it completely over rides every other file exclusion rule in the search string.

This means that even if you specify a limitation of [media type]=audio, and then add a ~a modifier, you may end up with images in your results list.

Speaking only from personal experience here, I've found no real, every-day use for ~a in its current form, but have been forced to look for ways to work around its behaviour many times, and have found myself answering many, many forum questions regarding usage of ~a and unexpected search results.

Over time I've come to just accept it as 'one of those things' and just put up with workarounds. I don't even know if a change is at all possible, but if it is, I for one, would welcome it. How about you?

-marko.

[marko]

if this were to be changed, I guess some discussion is required....

for example:

[media type]=audio [track #]==1 ~sort=random ~a

One would expect a list of audio tracks, sorted randomly, but grouped by album. So, we want it to honour the [media type] instruction, but over-rule the [track #] instruction.

So what do we actually want? I'd say...

As far as preceding rules go, it should only honour any [media type] specification, and for following rules, it should apply them as they would be in any other regular search string.
This way we can filter down to a chosen subset of files, then expand that to bring in all other tracks from each album in the list using ~a, and then add a little final fine-tuning of the results list by adding some exclusions if required.

-marko.

[gappie]

[media type]=audio [track #]==1 ~sort=random ~a

One would expect a list of audio tracks, sorted randomly, but grouped by album. So, we want it to honour the [media type] instruction, but over-rule the [track #] instruction.

as far as i can see it does honour the media type instruction and overrules the track instruction. but:

the interesting thing i noticed with my random album playlists (and i just checked with this one), is that when you look at the result with album thumbnails it is alphabetic sorting the album artists. but looking at it in detail keeps the albums together but random as expected.

[marko]

as far as i can see it does honour the media type instruction and overrules the track instruction.

This just means that you don't have any other media types with a matching [album] tag, or...
You forgot that the default sort order used by MC starts with [media type]. Did you look down the bottom of the list too?

[gappie]

when you mean with matching album tag, that non of my non audio albums have the same name as one of my audio albums. then you are right. i just tested.

im sorry i did not understand that from your initial post.

[hit_ny]

This means that even if you specify a limitation of [media type]=audio, and then add a ~a modifier, you may end up with images in your results list.

By any chance has your album art also got the same [Album] tag as its tracks ?

If so, what is the right thing to expect here, that ~a return everything that is tagged with the same [Album] right ?

I re-read your post and opted for #2, but what does ~a really mean ?

~a will return all items from the resulting set that have the [Album] tag with which it is used.

~a only gets applied at the end of the rule chain regardless of its position in the rules list. ~a is put at the end as it reads better that way.

[marko]

If so, what is the right thing to expect here, that ~a return everything that is tagged with the same [Album] right ?

Yes, my album art is imported and tagged. I also have a few video files with [album] tags that match albums in my audio library, and for a few bootleg albums, I have some txt and htm files too.

I would expect ~a to list all media types if, and only if, I did not specify a [media type] in the search rule. At least, I did, away back in the day when I first tried using it, and I posted it as a bug that though I'd specified a [media type]=audio, all media types were being listed. I was told that this "was just the way ~a worked" so I shrugged my shoulders and moved on, never fully understanding the logic behind it.

I just can't help the feeling that ~a would be a lot more useful if it would at least honour the given media type instruction, and at most, allow some fine-tuning exclusions to be added to its right in the string too.

...

[hit_ny]

for ~a to do its job it should not matter where its placed in the rule chain. So taking your example

[media type]=audio [track #]==1 ~sort=random ~a

give me all the files referenced by [Album] but umm actually i only want the audio ones.

you are saying that because [media type]=audio was specified, it should filter what ~a returns.

Well you also said [track #]==1  couldn't that also mean, you *only* want the first track of the albums.

So how to tell which one of the fields ([media type] or [track #]) should take precedence ?

The only reason the idiom (to get a random set of albums) even works is because ~a is all powerful.

This used to work fine in the 10.0 days when they left album art alone, but i think in 11.0, they started sticking dates into the album field (!), never understood why.

To this day i just ignore it and have not tagged any album art.

[marko]

Which is why I wrote:

[media type]=audio [track #]==1 ~sort=random ~a

One would expect a list of audio tracks, sorted randomly, but grouped by album. So, we want it to honour the [media type] instruction, but over-rule the [track #] instruction.

So what do we actually want? I'd say...

As far as preceding rules go, it should only honour any [media type] specification, and for following rules, it should apply them as they would be in any other regular search string.
This way we can filter down to a chosen subset of files, then expand that to bring in all other tracks from each album in the list using ~a, and then add a little final fine-tuning of the results list by adding some exclusions if required.

If we only wanted the first track of the albums, we probably wouldn't use the ~a modifier in the first place?
I think that what's needed is for it to respect any [media type] restriction that comes before it, and to allow further limitations to be applied after it.

-marko.

[hit_ny]

so promote [Media Type] to be a modifer more powerful than ~a ?

the random albums rule is the only one i can recall that uses ~a, have you used it  in others ?

[marko]

I can't use ~a to get random albums because it pulls in all these other media types too, and if I use a second smartlist to filter out the unwanted files, I lose the random sort order.

I have a view scheme here that uses ~a to show all files for all albums which can often be quite useful, and if the proposed changes ever came about, it would not break this view scheme because it does not have a [media type] restriction imposed on it.

[hit_ny]

I appreciate in the example you gave above, we only want random albums.

but say it was

[Media Type]=Audio [field 2]=b [field 3]=c.... [field n]=z  ~a

I was tyring to say the way its setup now, means any of the other fields act as filters in the same way as [Media Type] but you are asking for [Media Type]to be exepted only

I guess that  sounds ok in practice, i find its quite often that [Media Type] is the starting point for any smartlist. I only have audio & album art in my library, would be interesting to hear from ppl that have other media types as well.

[marko]

but say it was

[Media Type]=Audio [field 2]=b [field 3]=c.... [field n]=z  ~a

open a new smartlist - All files of all media types are listed...
(assume you have albums that contain files from each media type)

[media type]=audio - the list now contains only audio files.
[field 2]=b
[field 3]=c
[field n]=z - the list of audio files has now been filtered down to quite a narrow set files, and you would like to have all tracks listed for each album in the results.

so you add ~a

now you have all media types in your list, not just audio. is this what you would want or not?

[hit_ny]

For me, No, since i said what Media type to use in the beginning, and if i had tagged my Album Art, i would *also* expect Audio Only. If i wanted more than Audio i would not have specified [Media Type] or done it explicitly, agreed your suggestion would elliminate the use of workarounds for this purpose.

Are there any other known uses for ~a ?
If it can be shown that it won't break things then i think there is a good case for [Media Type] to be excepted.

Searching around the forum for use of "~a", ("~a" won't work so had to use

Code: [Select]

~a modifier and then the web browser to find just ~a, could not even get google to do it) shows in nearly all cases where one is trying to get a random list of albums, having ~a honour [Media Type] would be a good thing.

Anything with a tilde is a post processor.  That means it's run after all the regular search expressions are done and there's a set of output files.

You may be able to make one smartlist reference another smartlist to accomplish advanced nesting.

How difficult would it be at this stage to make ~a more aware of [Media Type] ?

I'm guessing ~a is the only modifier that would require such an exception.

[gappie]

i use the ~a to get a list of recently played albums. including the songs that were not played. shows all songs in the right order in details view. same for new albums. so the overruling character is ofcource very usefull. but i do see the point with [media type].

[marko]

Came across this in my bookmarks...

[media type] has trumped ~a for a few months now.

thanks for listening.