Print

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

[MrC]

Long ago...

16.0.117 (6/22/2011)

7. NEW: Added 'Playlists' column that can be added to any list to show the playlists that a file is in.

this new Playlist column was added.  Great.  However, it is fatally flawed.  The value shown is the playlist name, not its full playlist path, so given identically named playlists in a tree of playlists, it is not possible to trace the file back to the correct playlist.

How does MC generate this value, and would it be possible to get an alternate mode that shows the entire path?

I'm writing some code to merge files into playlists (by reading this Playlists read-only column), and I've just hit the brick wall.

[MrC]

I ended up writing a pscriptor scriptlet to get the playlist path for every file.

MC's playlist column still stinks.  :-)

[glynor]

+1

But I'm curious about the thing you wanted it for*...

Is the goal to preserve playlists somehow (as my Replace mode does in the ingester)?  I'm just wondering how you'd deal with locating position within the lists, if so?  Parsing every one to find its list order and saving that out, I suppose, but that seems like a ton of work.

But, that's probably not what you were doing at all, so is somewhat irrelevant.  In any case, I'm curious.

* And using this thread to discuss it will keep this thread, with your better point about the utility of the [Playlists] field, at the top of Interact longer too.

[MrC]

Many people over the years have asked about renaming files for offline use based on the Playlist name.  I got tired of telling them NO.  Recently, user stiv32 had a need for this (from our offline discussions) and also a similar request here:

   http://yabb.jriver.com/interact/index.php?topic=88467.0

If it were required, I could certain capturely the sequence number (on a per-playlist basis), but my approach is to generally add features as they are requested or as I need them.

FYI: I enumerate all the playlists, and then enumerate all their files, saving each filename in a by-Filename associative array each containing the file's list of playlists (by full path).

[glynor]

Many people over the years have asked about renaming files for offline use based on the Playlist name.  I got tired of telling them NO.  Recently, user stiv32 had a need for this (from our offline discussions) and also a similar request here:

   http://yabb.jriver.com/interact/index.php?topic=88467.0

If it were required, I could certain capturely the sequence number (on a per-playlist basis), but my approach is to generally add features as they are requested or as I need them.

Sure, of course.  I wasn't criticizing (or doubtful about the possibilities of doing so), I'd just been curious when I saw the previous thread... More of a wonder what he's up to thing.  I too have often wondered about that [Playlists] field and if it could be useful (or had more functionality hidden under the covers).

Your task makes perfect sense, of course.  I've seen those threads too and thought about it.

One thing I suppose you could do to speed up that algorithm is use the existing [Playlists] field as an excluding filter.  So...

You can't know, with the current kinda-dumb [Playlists] field, if a given file is in a particular playlist because the user could have three different "Bob's Favorite Songs #14" lists buried in different Playlist Groups.  But, if you are searching for a given set of files, you can tell from the field if the track isn't in a particular Playlist.  If you're looking for \Utility\Bad Songs\Crappy List 12 (and 14 other potential matches) and the track doesn't have "Crappy List 12" in [Playlists] then you know it isn't in that list and you can skip it.

Of course, that only works if you have a pre-defined list of possible Playlists you want to use, so, it doesn't really apply to your file-renaming task, I guess.  Still, an interesting possible use for even the current kinda-useless field.

I bet under the covers that field contains the Playlist IDs, and they just have it set up to display the MJPlaylistAutomation.Name property to the users (us).

[MrC]

I didn't detect even the slightest hint of criticism, so no worries.

I don't have a lot of playlists, so don't know how well this will work out for very large numbers.  It took 4 seconds to complete the entire enumeration and updates to my field in MC across ~18.5k files.  So I'm not yet worried about speed.  If I need to increase performance, I'll do exactly what you suggest - build the list of playlist candidates from the collection of playlists across all the selected files.  And probably allow a selection pattern to be supplied as well.

I intentionally exclude Smartlists, since their contents tends to vary with each run.  I coded the playlist download code with a filter of types to include:

       $playlists = $mcws->get_playlists(qw/Playlist/) ...

so adding type=Smartlist into the mix is easy (and I'll update the scriplet to include an option for which types to pull):

       $playlists = $mcws->get_playlists(qw/Playlist Smartlist/) ...