Can Plexamp read and use m3u playlists?

I was able to use this Plex Playlist API via Postman (using a POST call) to load my playlists.

This worked for me, but only when I don’t include the X-Plex-Token parameter.

I’ve made a more automated way of getting your .m3u playlists to show in Plex, you can find it here. That said I am completely new to all of this (I have used linux for like a week total) so apologies if it doesn’t work for others.

3 Likes

I’m fairly familiar with Linux and bash scripting. Cool if I make PR as/if I find issues? Been wanting to work towards importing playlists to Plex but never had time to figure out the POST requests.

Yeah go for it! :slight_smile:

I have a low tech but very reliable way of importing any m3u playlist into Plex.

  1. Get hold of Amok Playlist Copy
  2. Use it to create a copy of all the actual mp3 or m4a media files from the information in the m3u file. Amok will place a copy of the files in a single folder of your choice.
  3. Use a tag editor to re number the tracks in the new folder so they are contiguous from 1 to whatever number of tracks you have
  4. Add the folder to your existing music library or create a new one. Make sure you check the box to use embedded data.
  5. Open the new folder in Plex in List/Folder view, select all files and create a playlist.

I realise this creates duplicate files but I think most people have only a small percentage of their music in playlists and the duplicate files are in a separate folder, easily deleted later if not required.

The POST url + Postman method posted above (that’s a lot of ā€œpostā€ in a single sentence) works like a charm, bonus is you can save post requests in Postman and group them under a ā€œcollectionā€, so if you have a bunch of m3u playlists you can regroup them and make it a single-click action to upload/refresh all your playlists at once.

In my usecase I manage my music and playlists locally via MusicBee, and sync the ones I want + playlists to a folder that Plex scans. So now I just sync m3u playlists to that same folder and do the single-click Postman method to update everything at once. Much easier than using MovieFan before it broke.

Only works with m3u for me though, any variation of m3u8 or certain UTF8 encodings break it.

1 Like

UPDATE: I just collapsed my libraries together, which I probably should have done in the first place. All’s well, and the playlists upload correctly.


Thanks for putting this feature together, @timwoj!

Does the API support playlists that span multiple sectionIDs? Put another way, if I have two libraries, is there some way to upload a playlist that includes paths in both of those libraries?

My testing shows that I’m only able to upload items into a playlist from one library at a time, and since the upload logic is to replace an existing playlist (vs. append), I can’t get all items in there.

I can work around this by collapsing libraries but wanted to check first.

Thanks again!

I’ve been tinkering with this quite a bit today. My primary music player is JRiver and I use Plex for sync/remote capabilities. Over the years I’ve built up several playlists in JRiver and was hoping to import them.

I downloaded Postman, created a POST request with the syntax above, exported my lists from JRiver, and tried sending them to Plex.

I was able to consistently get it working using the m3u (extended) playlist option with absolute filepaths (it has options for m3u extended or simple, with either absolute or relative filepaths). I was also able to use Webtools to sync the playlists between household users on my server and have them play successfully.

That being said, unfortunately this only worked for certain playlists - others always gave me the 500 server error. Those playlists show it the library, but are empty.

I checked the Plex Token (I apparently have three separate ones - it’s different if retrieved from Tautulli, the Plex viewxml page, or from Webtools). Any of the tokens is accepted for the working playlists, but all give the 500 server error for the non-working ones.
Leaving it blank gives a 401 authentication error.
Using 127.0.0.1:[port] for the server address instead of the LAN IP works identically also (good for the test lists and 500 error for my real ones).
Putting ā€œā€ around the file path instead of using %20 for spaces allows the POST to finish successfully (no error), but the playlist never shows in Plex (so apparently the syntax doesn’t accept ā€œā€, use %20 for spaces in the filename).

I initially thought there was some kind of length or size restriction since the working ones were all in the 10-20 track range (one non-working playlist has 1200+ items where others are in the 100-300 area).
I thus played with removing 1/2 or 3/4 of the tracks from a non-working playlist to try and pin down a length that always worked. I also wondered if it was song-length size and tried different combinations there.

Eventually I realized that anything with a scandinavian character ā€œĆøā€ gives a 500 error. If I remove the tracks with those characters in the playlist .m3u file I can import playlists hours long.
There thus appears to be a bug of some sort that causes the playlist importer to crash on reading the file when it encounters ā€œĆøā€ (though it is already imported partially since it shows in the playlist library as an empty list). Those tracks are already in my music library, so Plex doesn’t choke on them overall - it’s just the playlist importer.
I suspect there are other special characters that also cause it to crash but haven’t pinned any down.

Any way to confirm this or see if we can fix it?

I’ve tried checking the logs and I don’t see anything specific to playlists.

You need to urlencode that, AFAIK

It appears you are correct. Even though the Ćø is in one of the track title/filenames and not the actual playlist filename, the error can be bypassed by swapping them with %C3%B8 instead (what your link provided).

Unfortunately I have many special characters in my tracknames from various languages or alphabets, so manually changing them all is prohibitive (even with find+replace).

Instead I tried pasting the entire contents of the playlist file in the conversion site and then saving what it spit out in the playlist file for Postman to sending that to Plex.
500 error every time (apparently it can’t parse a filename without the slashes and such, or possibly without the .txt structure).
I then tried several workarounds.

Eventually I figured out that saving the text file as UTF-8 instead of ANSI in Notepad worked - I could send those to Plex via Postman with no error and they actually loaded properly in Plex (with the offending characters still present). My longest playlist is over 3½ days and seems to be working properly (I put them on random-play, which is why some are so long).

This success notwithstanding, the UTF-8 ones seem to have some problem actually loading inside Plex. I almost always get ā€œUnable to load itemsā€ after it tries for 20-30 sec. The ANSI-encoded files of the same playlists load just fine (ones I had working earlier).
Despite these errors all of them begin playback nearly immediately if I click the play button on the playlist from the main screen or the three dot > shuffle, and I can go to the queue once playing and view the list just fine there (or at least the first 20-30 items before it fades out).
It’s more a cosmetic issue than anything - I maintain them outside of Plex so this doesn’t bother me.

So to assist others with the similar problems, in summary:

  1. The process of using POST to send playlists to Plex via Postman using the above syntax works great - assuming you know the playlist encoding requirements. What I’ve figured out is mentioned below, since there’s no documentation I could find.

  2. The files can be m3u simple or extended (tested both) and need to have the full track filepath (not relative).

  3. If the playlist text file is ANSI-encoded, special characters aside from those in a normal filename path or m3u extended formatting will give a 500 error (ie \ : # or the like are fine but Ć„ or Ćø cause the error).

  4. After a 500 error on POST, if the file is m3u simple it will sometimes show in Plex and sometimes not, but if so it’ll be blank. If the file is m3u extended it’ll always show, but will be blank.

  5. If the file is UTF-8 encoded then the special characters that cause 500 errors in ANSI don’t cause problems - no 500 error and the lists show properly in Plex.

  6. Spaces in the filename must be replaced with %20. Putting the parameter in quotes on the POST command doesn’t work - it doesn’t give a 500 error like with the space, but Plex doesn’t load the list.

  7. There is not a length or track count limit I’ve encountered (so far 1.3k tracks for 3.5 days is my longest).

  8. Playlists load only on the main server profile. These can be copied to other users via the Webtools plugin (at least ā€œhouseholdā€ users - I don’t have non-household users added) and work fine, but there’s no functionality built into Plex that allows sharing playlists that I could find.

  9. As mentioned by a prior user, Postman works great for this - save command string in a folder, get the POST command working, duplicate it and change the filename parameter, and then you can run a sync for all your playlists at once by running the entire folder of commands.

Hopefully this helps!

2 Likes

I appear to have spoken too early on this part.

I can get to webtools and select to copy the playlist. It appears to go through without error, but then it never shows up on the destination account (in Webtools or the Plex UI/app). The Plex log seems to say something about a ā€œCaught exception trying to stream fileā€ using PhotoTranscoder. I’m not sure if that’s related, but it’s the only entry in the timeframe.

I’m also not able to download the lists from inside Webtools - I click the button and get a ā€œā€˜NoneType’ object is not iterableā€ or ā€œā€˜NoneType’ object has no attribute ā€˜getā€™ā€ error after it thinks for 10-15 sec.

I think this may be related to the list not ever loading in Plex after changing the encoding to UTF-8 - Webtools seems to be going to the same URL and using that to copy/download, so if it’s not loading for me it’s probably not loading for Webtools and hence causing the failure.

I can copy the old test ANSI playlists back and forth fine, and lists made inside Plex just fine, so I think it’s got something to do with the UTF-8 playlists I was able to send to Plex.
If I load one of the UTF-8 ones that’s imported in Plex and add it to the queue, then save the queue as a new playlist (which presumably would put it in Plex’s format) I still am not able to copy it to another profile in Webtools (though one much much larger does work that was created wholly inside Plex as opposed to this queue method).

Any ideas on what I can do to get them to other users? (Changing formatting in the playlist or such). Or is this something now to take over to the Webtools thread?

Sorry about the triple-post, but I felt an update was warranted.

I tinkered with these playlists much of last weekend and ended up with nearly a dozen that originated in various encodings and formats (UTF-8 or ANSI, m3u with and without URL encoding, etc). I still had trouble loading the playlists in Plex under my main account, but they would play and shuffle fine, and I couldn’t use Webtools to copy them over.

On a lark I tried again today to copy one of the playlists to another profile in Webtools. It worked.
All of them also worked fine in Plex to load almost instantly (even one of 3+ days) and play normally, regardless of original encoding format (so long as it made it to Plex).
The server settings haven’t changed, it hasn’t been rebooted, and I didn’t even refresh the Webtools or Plex pages (they were still open from last weekend). The computer hasn’t even really been used.

The only thing I can figure is that Plex does some kind of playlist scan/import process after they’re first sent over to confirm that files in the playlist are actually in your library, and that hadn’t yet completed during my original testing. Once it was (a week later, though I don’t know how long it really takes) they can be played and moved between users normally.

In short, my numbered list from above is indeed correct, with the caveat that you may need to wait a while after it shows in Plex before being able to play or copy the list.

Thanks again for the help with getting this working!

1 Like

Hi!

I’m trying to get this to work, but I keep seeing ā€œCould not find pathā€ errors in the log despite the fact that…

a) the playlist is available on the server (QNAP), at the path specified by the path= parameter
b) the media server is finding the playlist since it’s trying to scan through all the files referenced within
c) all filenames have had the spaces converted to %20 - both in the playlist filename and the song filenames within
d) I can confirm that the filenames the server seems to be looking for (as per the log) are indeed visible in the server via the path the media server is trying to find them at (i.e. /a/b/new song.mp3 does indeed exist at ā€œ/a/b/new song.mp3ā€)

I had to use the Plex Library Scanner to get the correct sectionID number since apparently that can vary between installations, but other than that everything else seems to fit…except, of course, that it doesn’t find the stuff to create the playlist :slight_smile:

Any ideas?

PS/ Importing a user’s existing playlists seems to be to be very basic functionality - why would Plex, such a feature-complete and advanced engine and UI, be missing it?

Ok so I figured it out. It rang in my memory that at some point I had read that some special paths had to be used for Plex on QNAP instead of the ā€œbasicā€ ones. So I changed the playlists to reference ā€œ/a/b/new song.mp3ā€ as ā€œ/a/special-path-for-qnap-stuff/b/new song.mp3ā€ and it worked.

For those interested, the paths need to be rooted at ā€œ/share/CACHEDEV1_DATA/.qpkg/CodexPackā€. You can check to see which path you defined your Music library to be based off of, and use those.

Cheers!

Bad move, and the CodexPack is a QNAP addon, not related to Plex in any way, and is known to cause problems for Plex

As I recall, this is what the QNAP configured for Plex when I added the libraries. I recall that when I added the libraries, I added them from the ā€œnormalā€ path of ā€œ/share/Library/ā€¦ā€ (i.e. no CACHEDEV1_DATA reference) but then that was somehow transformed.

I’ll look into it but I suspect this was done transparently ā€œfor my benefitā€.

Cheers!

Plex NEVER EVER use the CodecPack from QNAP, and it is known to cause multiple issues!

If only using Plex as the MultiMedia solution on your QNAP, then it’s STRONGLY recommended to remove the CodecPack

Well, I know for a fact I didn’t set it like that… I’ll try removing a small library and switching it to the simpler paths to see what that does. Cheers!

1 Like

Ok so I modified all the libraries to not link in through the CodexPack paths, and I looked into why they’re set like that to begin with.

It turns out that when one is trying to add a library, one is shown paths rooted at /mnt/HDA_ROOT … unfortunately, the ā€œshareā€ directory that one can navigate through there points to ā€œ/share/CACHEDEV1_DATA/.qpg/CodexPack/shareā€. This means that if one wants to skip the CodexPack, one has to:

  1. know that in advance (this is the big one!)
  2. manually input the path into the text field rather than picking from the list

My libraries were all rescanned, garbage cleaned up, metadata refreshed, etc, but otherwise intact using the new paths that don’t go through the CodexPack.

The key takeaway is that the paths inside the M3U files, as well as the location of the M3U files themselves MUST lie within the path(s) defined for the Music library, or Plex won’t find the songs (obviously, since they’re not in the library) nor will it accept the playlist for inclusion (because it wouldn’t be within the library paths).

Cheers!