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

I'm working on updating the software this weekend.

I'm working on updating the software this weekend.

Ok. I see. I did that, but by trials and errors, I've run into several annoyances.
I guess that french characters is the cause of that error:"List Importer 'Winamp playlist':'utf-8' codec can't decode byte 0xe9 in position 323:invalid continuarion byte
I chose an full English playlist. I have that:"Playlist name has already been taken by a non-playlist"
It seem that my plex playlist name can't be the same as the artist that is already in my plex library, so I change the playlist name to "paramorelist":DB Error: no such module fts4

You need to either be running on the computer that has the plex server installed, or be able to access plex's config directory directly. If it is not running on the same computer, let me know and I'll elaborate.

---

Go to your current directory with your playlist file.
Run: PlexPlaylistImporter YourPlayListFileName.m3u PlayListNameYouWantInPlex
E.x.: PlexPlaylistImporter Disc1.m3u "They Might Be Giants"

Hello, I want to use the PlexPlaylistImporter, but I don't know how to enter my parameters. I run this command in powershell (I use win 8.1):
    python PlexPlaylistImporter.py and it returned me that:Parameters:        1 (Required): The path of the playlist file. If the file extension is not recognized, the file is parsed as a Winamp playlist (.m3u)        2 (Required): The name of the playlist in Plex to import to. If it does not exist, the program will prompt on whether to create it        3 (Optional): The path to the sqlite3 database file\n        * The program tries to guess the path for the Plex data directory. If it cannot be found, this path needs to be passed explicitly        If the database is still not found from the given Plex path, the full path to the database is required
And my playlist is not in plex. I tried to look in the readme file of github, but I don't even have an exemple of how to do that. I tought the program would ask inputs as usual.

A. I'm as sure as I can be with the tools at my disposal that these .m3u's are UTF-8:
1. They're exports from Mp3tag, which allows me to establish the output character set in the .mte export spec (attached). It's set to UTF-8.
2. Notepad reports they're UTF-8.
3. I used EditPad Lite to force the text file to be no-BOM, UTF-8.

B. I'm certain the underlying .mp3 files are present in both the library at the location found and are individually playable in Plex (and thus in the Plex Library). The .mp3 files appear in all Plex Library listings irrespective of filtering (Album, Artist...).

C. I'm using your Windows .exe only; I do not have Python running separately. I'm running in a Win 7 x64 environment, in case that matters; machine resources should not be an issue (quad-core i7, 32GB RAM).

D. The longest playlist I've tried to import (5.5hr running time) has only 73 tracks, but I appreciate the heads-up on the 150 track limit.

E. Also attached per your request is a fragment of the playlist with the problematic character set entry described above.

Hope this helps. Thanks again very much for your efforts.

OK, I merged in another authors branch to fix the linux absolute path problems. I fixed the UTF8 bom problem, so you don't have to worry about that anymore either. I also added cygwin compatibility.

I just tested with a utf8 m3u file and file names with Japanese characters and it imported fine (had to set up special test cases). Are you absolutely sure your file is utf8? Assuming your command line is in utf8, when the error is shown it should have the proper filename at the end of the error.

I also just tried to save a list from an older version of winamp and it just put question marks for any of the japanese characters ~.~

I also just did a massive import of all my music into plex (have been rebuilding my library). And interestingly enough, 0 of my 100+ files that had japanese characters even imported into plex!  So are you also sure those files are actually in Plex?

There have been weird errors in the past regarding playlist and file lengths in plex. One example is that if your playlist has more than 150 entries, plex no longer recognizes it. The person on my forum that discovered it submitted a bug report to plex. Not sure if it was ever resolved.

But anywho, the playtimes are grabbed from what is already in the plex database, so it is possible it had not recorded them yet at the time you did your playlist import. Or perhaps they are storing additional information about the tracks elsewhere and not updating the main table. I didn't try very hard on that part, as I knew it would auto correct. Once the file is in the plex server playlist, my program no longer has any control over its values.

The error that you are showing regarding the charset looks like it might be b/c you are not in utf8 mode in your tty console. Also, the character you mentioned, c3, is "Ã", which is interesting.  I think I see that one a lot when there are encoding problems. If the board lets you, any chance you can post your playlist file with just that one song for me to inspect. And western european character set would definitely not work with the importer. UTF8 is essential.

Also, have you been running via the executable, or the python scripts? If the latter, I have the newest source up on github @ https://github.com/dakusan/PlexPlaylistImporter/ . If you are unable to run from source, I'll get an executable compiled for you (its a minor PITA). Not wanting to release a new version on the site until your problem is resolved

OK, my forum is acting super crazy right now and not showing your last post >.<; here it is again, and I am working on the stuff now.

Skipper42:

Well, I solved (kindasorta) the basic problem of BOM inclusion by  installing EditPad Lite (freeware, unlike the Pro version), which  permits me to create (Options menu) an M3U file type and specify UTF-8  and no BOM, and to replace the existing BOM with none if found. I can  then open an .m3u created in another app (e.g., MediaMonkey, mp3tag,  Notepad) and resave it with no BOM.
Unless there are character codes  beyond the basic alphabet (see below for a description of this newly  discovered problem), the .m3u will then import successfully...
...kindasorta.  After the first two successful playlist imports, PMS stopped displaying  the total duration (length) of the playlist, reporting only 'x Items'  where x is the track count. Further, when the playlist is opened in  Plex, all the track lengths are shown as 0:00. A quick check with mp3tag  showed the metadata for length as indeed being included in the .mp3  file, and when one browses to the album in Plex, it, too, has the track  length correctly shown. In both cases -- playlist or music browse --  Plex plays the track correctly. Interestingly, once a track has been  played from the playlist, suddenly PMS finds its brain and correctly  displays the track length on the Playlist page. There's no Refresh  opportunity in the Playlist dialogue to force this otherwise. After the  track lengths are displayed correctly once, they're displayed correctly  henceforth, along with the overall playlist length on the main Playlist  browse page. I noticed that it took a while for the data to propagate  there, however. Even after playing all tracks in a 1:46 duration  playlist (duration doesn't matter, simply starting each track is  sufficient to update the track length display after a few seconds), the  initial value shown for playlist length upon return to the main Playlist  page was 20 minutes. Returning to the track listing for the playlist  showed that indeed all the track lengths were still there, and on return  up to the main Playlist page, suddenly the duration was the correct  1:46 value.
I'm unable from where I sit to determine whether this is a  PMS bug or a PPI problem; perhaps there's a missing commit in the PPI  SQL update query for the track metadata records, and absent some refresh  mechanism, takes PMS a while to update itself?
Now on to the character set/codespace problem.
If  the path (artist, album) or track filename contain other than basic  alphanumeric characters thru ~ (code < 128 or 007F), then you run  into problems like the following, where PPI can't find the track .mp3 to  get its metadata:
Actual mp3 file record in m3u  playlist:<path>\Music Library\Saint-Saëns\Violin Concerto No. 3\02  Romance for violin & orchestra in C major, Op 48.mp3
PPI import  error:ListImporter 'Winamp playlist': Cannot find file listed in  playlist (must be relative to the playlist):<path>\Music  Library\Saint-Sa\xc3«ns\Violin Concerto No. 3\02 Romance for violin  & orchestra in C major, Op 48.mp3
In this case, the e-umlaut (ë) has a decimal character code of 235 (+00EB).
Doesn't  matter whether <path> in this example is relative ("dot  notation") or absolute (<drive letter>:<folder path>). Just  FYI - the error message always says "relative" even if absolute path  addressing is used (likely an artifact of your absolute addressing quick  fix).
Since PMS correctly renders the special characters and  correctly finds and plays the track, and since other apps (MediaMonkey,  mp3tag, Notepad, EditPad Lite) correctly find/render/play the .mp3 file,  this flaw appears to be inside PPI.
I checked and it also doesn't matter whether the character set used is UTF-8 or Western European.
This would seem thus that PPI's character set issues are larger than just ignoring the UTF-8 BOM in an .m3u file.
I  know that's not good news, but do hope there's enough info here for you  to diagnose and correct the bug; I've made enough progress with a  handful of successful playlist imports to be excited about the prospect  of overall success!

OK, my forum has been randomly deleting posts  I just recovered this from the trashbin.

Pierre: it requires python3. I will be making a minor change soon to verify it uses that.

ulle: Playlists are not user based, they are library based. If you mean you want to use a non-admin user to import a playlist, it is possible as long as they have access to the plex sqllite3 file.

Sorry for taking so long on this, should be able to look into this and update the software tomorrow or the day after.