Print

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

[Antoine.]

I have a lot of smartlist whose rules are based on whether or not a file belongs to a given other smartlist.

I don't why but they constantly disappear now! Leaving only "Custom" & "Playlist ID=" instead of the specified playlist.

[marko]

This happens with server/client MC's.... although acknowledged, a fix does not look likely...

I don't think any of those playlist id things are going to magically be fixed, the playlist ids are not synchronized between clients - just the playlists themself are.

There is however, a neat way around the issue....

Morning glynor,

It was one of the first shortcuts I learned back in the heady MC v9.0 days.

I have a couple of playlists at "Playlists\Viewscheme Groups\Duplicates\" called "Hidden" and "Recycle". These are a crucial part of my whole library, as dicussed somewhere else many moons ago. I use them for duplicate management in a view scheme hinged around a pane that displays the playlist group. By selecting files, I can then use pane tagging to add or remove tracks from these play lists.

The idea here is that during random playback, I don't want duplicates playing. So, all the dupes (kept for whole album integrity) except the best or chosen one, go in the "Hidden" playlist. Files marked for deletion go in the recycle playlist. I don't want those in the random playback lists either. As these two are so crucial to how my library works, having the server blow up the playlist exclusions ever so regularly is not so good. These are used everywhere!

If, instead of using the wizard to glean the playlist ID's, I simply enter -p=hidden,recycle it enters those as a "Custom" rule in the wizard, and so far, these have never gotten borked.

There is a caveat though...

Imagine I had a playlist on the playlist root called "Hidden Gems" that had stuff I always wanted to hear...
the -p=hidden,recycle rule would unfortunately exclude that playlist too as it contains 'Hidden'.

The shortcut does appear to match anywhere in the playlist path though, so if I used -p=duplicates\hidden then the "Hidden Gems" list would not be excluded.

-marko

Hopefully, that helps a bit.

[Antoine.]

Thank you for your answer!

The developpers should consider either fixing this Playlist rule in further updates or removing it altoghether. Keeping a broken feature is just frustrating.

Playlist rule is really usefull if you have one big underlying rule (for example a long list of given artists) to a lot of smartlists: when this big list must be changed, it only has to be changed in one place not in every derivated smartlists. Playlists & smartlists are really central to my JRiver experience, I'm really bummed out about this...

[marko]

I can't show you an example right now, but you replace the playlist rule with p="playlist name" or for  exclusion, -p="playlist name"

The rule will work, and never get corrupted.

[Antoine.]

Thanks! I finally got it working!

Is this whole thing of playlist rule not working related to playlists IDs?

[marko]

Yes. When the client MC attempts to sync playlists back to the server, the playlistid values in the rules get corrupted.

Pleased to hear you're off and running now. Good stuff.

-marko.

[RoderickGI]

There is an easy fix to this caveat though Marko;

There is a caveat though...

Imagine I had a playlist on the playlist root called "Hidden Gems" that had stuff I always wanted to hear...
the -p=hidden,recycle rule would unfortunately exclude that playlist too as it contains 'Hidden'.

The shortcut does appear to match anywhere in the playlist path though, so if I used -p=duplicates\hidden then the "Hidden Gems" list would not be excluded.

-marko

Just use the rule:

-p=[Hidden],[Recycle]

Which excludes the files if it belongs to a Playlist that exactly matches "Hidden" or "Recycle". The [] meaning the beginning and ending of the characters to match, so that anything that only includes "Hidden" or "Recycle" will not match.

I did a quick test using your example "Hidden", "Recycle", and "Hidden Gems" Playlists, in a Smartlist which included files based on them being in a Playlist called "Enigma" that I manually created, and that seems to work just fine. A file in the Smartlist "Hidden Gems" is not excluded, while files in the "Hidden" and "Recycle" Playlists were excluded.

Of course, the above rule can only be added using a Custom rule as you did or using the "Import/Export" button to manually code the rule.

I didn't test with the "Playlist Path" used for Grouped Playlists such as duplicates\hidden though... Wait, I just did. I put all my test Playlists and the Smartlist in a Playlist Group called "Duplicates", and the following rule worked:

-p=[Duplicates\Hidden],[Duplicates\Recycle]

[Antoine.]

I have a question about the difference between [ and " when writing a custom rule for playlist:

p="playlist" : retains all the playlists whose name contain the word playlist?

p=[playlist] : retains the playlist whose exact name is playlist?

Also, what is the point of specifying the playlist path (regarding groups)? Can 2 playlists have the same name in 2 separate groups?

[RoderickGI]

I have a question about the difference between [ and " when writing a custom rule for playlist:

p="playlist" : retains all the playlists whose name contain the word playlist?

p=[playlist] : retains the playlist whose exact name is playlist?

Correct. Well, actually;

p="Happy" : retains all the files which belong to a Playlist whose name contains the word Happy.
p=[Happy] : retains all the files which belong to a Playlist whose exact name is Happy.

This is part of the MC Search Language, and in explained in the Quoting and Anchoring
That is different to the way the [] brackets are used in the Expression Language, where [Name] actually means field(Name), for example.

Also, what is the point of specifying the playlist path (regarding groups)? Can 2 playlists have the same name in 2 separate groups?

I have no idea. Try it!... Actually I don't think two Playlists can have the same name, as only the name is stored against the file. However, the search I wrote above requires the path once the Playlists are grouped. I tried it without the "Duplicates\" component and it didn't work.

Just one of the idiosyncrasies of the MC Search Language, and Playlists structuring, I guess.

[glynor]

Playlists can absolutely have the same name, assuming they’re in different playlist groups. The “full name” reported back by the API though includes the full path of the playlist.