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

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!
Thanks again for all you've done on this.

Whatever program you used to save the playlist file as UTF8 is adding a BOM (byte order marker) to the beginning of the file, specifically, the utf8 BOM " ". It needs to not be in the file. You can generally set a setting in your text editor to not include it. I'll see if I can't make an update soon to bypass this problem.

For some reason, I'm unable to reproduce the working import function with other m3u playlists.
I'm getting the same gibberish characters as the earlier poster (Clowg) at the front of the first line; switching to relative paths from absolute paths doesn't help. Doesn't matter whether the line is blank or an actual reference to an mp3 file. The references are correct; I've verified that with Explorer.
I've used mp3Tag, Notepad, and Wordpad all. Saving as UTF-8, Unicode, Unicode Big Endian... none of that changes the outcome. I'm also not getting the prompt to create the new playlist.
Here's what I get:ListImporter 'Winamp playlist': Cannot find file listed in playlist (must be relative to the playlist): E:\Users\Public\Music\Music Library\<artist>\<album>\<song>.mp3
Also doesn't matter whether I'm running from the command line, from a batch file, or where the playlist file is relative to PlexPlaylistImporter.exe. I'm specifying in the command line the filename of the playlist, the playlist name, and the file path and name of the PMS database. Doesn't matter whether or not PMS is running.
Finally, mp3Tag has no problem finding the associated mp3's from the playlist when opening the playlist .m3u in mp3Tag.
Hope this helps you diagnose the fault.
Thanks!

Awesome! Glad you got it working! Sorry I couldn't have been more help on fixing it. Busy busy.

Very interesting @ the proc architecture. I had never even thought about seeing what arch the files compiled as. Though x86 makes sense for the extended compatibility, which for a project like this, is appropriate. Will definitely keep it in mind for the future

Googled the problem and found this:
https://www.sqlite.org/fts3.html#section_2

• If a build of SQLite does not include the FTS modules, then any attempt to prepare an SQL statement to create an FTS3 or FTS4 table or to drop or access an existing FTS table in any way will fail. The error message returned will be similar to "no such module: ftsN" (where N is either 3 or 4).

Since that seemed to suggest the sqlite3.dll in your executable binary distro was built without FTS4, I hunted down an x86 version that did (the x64 version didn't work, since your app is x86, apparently). After putting the DLLs, the executable, and the importing .m3u all in the same directory...
IT WORKED! I now have the test .m3u successfully imported into the Plex Playlists, and it plays!
I can't believe the Plex folks cannot figure out how to do this on their own.  You're my hero for the day!
Many thanks for your patience, advice and hard work on this.

I've disabled the services using sqllite3.dll, rebooted, and confirmed those services are not running. I've also not started PMS.
When I run the batch file that launches PlexPlaylistImporter.exe, however, after answering 'y' to create the new PMS playlist, I get the same error:   Plex playlist is not already created. Would you like to create it now (y/n)? y   DB Error: no such module: fts4
I've verified in the Registry (HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\KnownDLLs) and in Process Explorer that the sqllite3.dll in the PlexPlaylistImporter.exe folder – C:\Program Files (x86)\PlexPlaylistImporter – is not known to the system. The same is true of the python34.dll in the same PPI folder. It looks to me like the program is failing to find and load the DLLs.
Any suggestions?
Thanks!

Yes, the sqlite3.dll is in the same folder as the executable.
A quick check in Process Explorer shows three other active instances of two separate sqlite3.dll copies: - Backup software infrastructure component; I may be able to stop this service, reboot, and proceed without having the service restart, so it's at least something I can try. - PlexDLNAServer.exe - PMS
If I don't need PMS running when doing the import, this should be manageable. Both PMS and the DLNA server use the same copy in the PMS directory.
I'll note that a Win Explorer search found 9 separate copies of sqlite3.dll, all with different dates and sizes, including some not currently active: - PlexPlaylistImporter - PMS - MediaMonkey (which I'm using til I get music playlist imports to work in PMS) - Kodi (ditto; horse race for which gets there first) - Backup software - Security software
Thanks!

Just to make sure... you do have the sqlite3.dll in the same directory as the PlexPlaylistImporter.exe, right?

Yeah, my next guess was going to be that it was choosing the wrong dll.

The article I linked says:

• If a DLL with the same module name is already loaded in memory, the  system uses the loaded DLL, no matter which directory it is in. The  system does not search for the DLL.
• If the  DLL is on the list of known DLLs for the version of Windows  on which the application is running, the system uses its copy of the  known DLL (and the known DLL's dependent DLLs, if any). The system does  not search for the DLL. For a list of known DLLs on the current system,  see the following registry key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\KnownDLLs.     

So it is most likely the first one. Is it possible for you to temporarily unload the program that is using it? You can also search for DLL usage handles by using Process Explorer. In the find menu there is a "Find Handle or DLL... (Ctrl+F)" option.
If you are unable to stop the other process, you can try manually replacing the .dll in its folder, but that is risky

You're correct - I'm using your binary from here.

I copied all the content from the downloaded Zip archive to a corresponding folder: C:\Program Files (x86)\PlexPlaylistImporter\.

I don't have SQL Lite installed per se; I only have PMS (latest version) installed and running. Do I need to do anything else to ensure the correct DLLs get used?

Thanks!

Find all directories that do not contain subdirectories

Code: [Select]

find -type d -exec sh -c 'test `find "{}/" -mindepth 1 -type d | wc -l` -eq 0' ';' -print