Official site launch very soon, hurrah!
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.mp3PPI 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.mp3In 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!
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.
I've not found a good way to execute ListImporter from a folder not containing both the .exe and all its .dll files. This would be useful but is not essential. I do have to manage Acronis' insistence on restarting one of its supposedly unneeded services that uses a different sqlite3.dll. The sqlite3.dll used by the latest version of PMS no longer conflicts.
The first of two small issues is that ListImporter is intolerant of blank lines in the m3u (e.g., at the end).
The second small issue is that any error in one track reference causes the entire import to abort with Errorlevel set to 1. [...]
(a) execution message output appears to go to stderr vs. stdout, which can interfere with batch file output piping for logging/analysis purposes
#Insert the items into the playlist
Cur.execute('DELETE FROM play_queue_generators WHERE playlist_id=?', (PlexPlaylistID,))
sys.exit("File not found in DB: "+FilePath)
continue