More > JRiver Media Center 19 for Mac

Batch transfer tags to media files on Mac via MPL file created on Windows?

<< < (3/6) > >>

couchjr:
I get the same greyed out behavior whether the paths are relative or not. I've attached a screen shot of the "Get info" screen of an MPL created on MC 19 copied to my drive. File extension shows as .mpl.

When you say the relative imports fail, do you mean you can select the file and hit the "Finish" button and then you get an error message that the import fails? Or are you not able to select the file? I'd expect the former behavior. Why would a pathname in a tag value prevent the browse widget from recognizing the file as valid? (I did have the MPL file type checked in the import dialog, and have attached a screen shot of that. I've also attached a screen shot of the browse window in the Import dialog, showing the greyed out files.)

I just checked the thumb drive I used to convey the MPL file from the Windows machine to the Mac, and discovered that it's formatted as MS-DOS Fat16. Is it possible that OS X misreading from this format is could cause the issue? I'll ask my colleague to email me a copy of the MPL file and see if that changes the behavior.

The relative path looks absolutely correct for the Mac; when I created an MPL with relative path on the Mac version it found the file without trouble, and the path is the same as what the Windows version created. So even if it wasn't styled correctly to work on a Windows machine, it should work on the Mac if the MPL file and the media folder are in the same relative position (both in the same directory), no?

If that was just dumb luck, when do we expect relative paths to be fixed in MC? It will save me a lot of time.

Thanks!

MrC:
Your files show as Kind: Unix Executable File, and not MPL File, and there is no Open With application associated.

By FAIL, I meant the MPL file itself is selected and imported into MC, but the referenced media files are not imported (or have properties updated).  When you import a playlist, both the playlist file itself, and the referenced media files are imported (when possible).

Don't use Tools > Import.  Use File > Import Playlist.

couchjr:
Yes, I said in my earlier msg that even though the file suffix is .mpl in all views, the Mac thinks the file is a Unix executable. I'm hoping re-acquiring the MPL without going through a storage format other than NTFS or HFS+ will correct that--will report back.

Thanks for the instruction to use File -> Import Playlist. Hadn't discovered that method. If Tools -> Import doesn't work reliably for MPLs, perhaps the option to import MPLs should be (at least for now) removed from that tool?

Thanks also for the description of failure mode. This encourages me somewhat; we're troubleshooting two separate problems.

Question: if importing the MPL also imports the referenced media, does it automatically update the tags in the referenced media files? I was assuming I'd need to import the MPL, then do "Update tags from Library" before importing the media files. If importing the MPL updates the tags in the referenced files automatically, that will be great, but something to know for workflow. Recall that we're using the MPLs as a way to batch-transfer tags from multichannel dsf to stereo dsf versions of the same ISO's tracks. Clarification of sequence of operations here would be welcome.

Thanks again! More anon.



MrC:
An MPL import will both import the files when possible, and update the file's properties as per the Field values in each Item in the MPL.  An MPL is more than a simple playlist - it is a per-file properties list.  I do this routinely, as do other folks (in fact, my AMG script creates an MPL for importing metadata from AMG, so MPL importing has been routinely tested).

I assume the reason Tools > Import does not update properties the same way that File > Import Playlist does is that they are two distinct operations.  Tools > Import is about importing just files, including MPL playlist files (which will be imported, and stored under Playlists > Imported Playlists).  File > Import Playlist is a manual operation which allows you to force update properties via MPL.  Since properties cannot be update if the files are not imported, the media file import is a requirement for the operation to be useful.  Simple playlists types just import the referenced files, as they have no associated properties.

The MPL file I showed in the above screenshot was generated on Windows/NTFS and then coped to the Mac's HFS file system.  I don't believe the Browse dialog examines the file's contents - only the file type - so line ending differences would be irrelevant.  Maybe setting the file association will help.

couchjr:
Thanks, Mr.C. That did it!

Using File -> Import Playlist, all the MPL files (the ones with unix line endings and "unix executable" file type, the ones with just "document" file type, and the edited files saved by the text editor as "simple text" file type) were selectable in the Browse dialog. All would import. As you predicted, the ones with relative paths failed to import any media files. The one I edited to match my MacOS path style worked like a charm. Just to be sure I've understood your last post, I think you said the MPL import operation writes the new tags into the media files, not just the MC Library database. So I don't have to run "Update file tags from Library" now. That's terrific--please confirm.

So until MC gets the relative paths piece of this import sequence working, I'll take you up on your generous offer of doing an Automator script to translate the paths (I'm hoping that this can apply to all files in all albums imported by a given MPL, which may be 50-100 albums). I'll provide the before and after strings as soon as we have agreed on a naming convention and location relative to root for the directory these will live in.

I note that MC MPL seems to create the "Filename" field by combing the album name and the actual filename (which as generated by SACD_Extract begins with a track number), separated by a back or forward slash. So it looks like the script will need to do two operations: delete "Z:" (or equivalent) and change all slashes to forward slashes. Once we agree on a standard naming convention, the container directory holding all the album folders should retain the same name. Will advise when ready.

Thanks again!



Navigation

[0] Message Index

[#] Next page

[*] Previous page

Go to full version