|
-
December 10, 2024, 08:12:32 pm
- Welcome, Guest
News:Official site launch very soon, hurrah!
Topic Summary
Posted by: clowg
« on: January 30, 2019, 12:52:47 am »
PS: There is a new API available for Playlist importing:https://forums.plex.tv/t/can-plexamp-read-and-use-m3u-playlists/234179/32 G.
Posted by: clowg
« on: January 30, 2019, 12:38:42 am »
Hi @Dakusan
I have come back to your script/.exe because Plex threw away one of my previously imported m3u Playlists.Im getting this error: PlexPlaylistImporter.exe -p "D:\PlexServer\Plex Media Server\Plug-in Support\Databases\com.plexapp.plugins.library.db" "D:\7mc\plexplaylistimporter\top 550 songs.m3u" Top550SongsPlex playlist is not already created. Would you like to create it now (y/n)? y DB Error: no such collation sequence: naturalsort
This is on Windows 10 x64, on the Plex Server console. The exe worked really hard for about 10 minutes before coming up with the playlist creation question, and then immediately failed with the error.Any ideas on that one? G.
Posted by: Dakusan
« on: July 24, 2017, 12:00:18 pm »
I'm very sorry to everyone who has been waiting for me to get some updates done. I've just been super busy lately and getting to spend time on this project has just been impossible. I will be getting to it as soon as I can.
Posted by: Dakusan
« on: July 07, 2017, 04:52:58 pm »
Most likely a database update I'll take a look at it as soon as I have a chance. (Should be sometime in the next week)
Posted by: Dakusan
« on: June 26, 2017, 02:35:11 am »
Ahah. Should have thought of that. The latest version on github has options for plex user accounts, but I don't think I've put it on my site yet.
Posted by: Dakusan
« on: June 24, 2017, 11:47:49 am »
First, "/var/lib/plexmediaserver/Library/Application Support/Plex Media Server/Plug-in Support/Databases/com.plexapp.plugins.library.db" needs to be quoted, since it has spaces, or your command line interpreter will think those are separate parameters.
I'm surprised it decided to import at all with what you gave it, since you gave an unquoted (and therefore bogus) path to the database. I'm guessing it found the path on its own so it didn't error out.
Second, you only gave the "Playlist_Path" parameter and not a "Plex_Playlist_Name" parameter.
Posted by: Dakusan
« on: June 19, 2017, 04:09:42 pm »
"DB Error: no such module: fts4" indicates an outdated or incomplete sqlite3 version. Google also points out that this happens when trying to compile for iOS, or possibly osx.
Posted by: Dakusan
« on: February 17, 2017, 02:47:07 am »
Same disclaimer. Guess I gotta add command line flags for this and update on github. Already have 1 pull request on github. PITA cause I don't release code without thoroughly testing.
Line 137. Change
sys.exit("File not found in DB: "+FilePath) to
continue When I update on github it will throw a warning instead.
Posted by: Dakusan
« on: February 14, 2017, 10:23:31 am »
In PlexPlaylistImporter.py, below line 177 #Insert the items into the playlist Add the following line
Cur.execute('DELETE FROM play_queue_generators WHERE playlist_id=?', (PlexPlaylistID,)) I have not tested this code, so make sure to backup your database before attempting it.
Posted by: Dakusan
« on: July 26, 2016, 08:12:09 pm »
You mean a separate Plex pass user, correct? One in which you would have had to of shared your libraries with via Libraries->...->Share ? (Or shares visible via plex.tv->launch->settings->users->friends)
Posted by: Dakusan
« on: July 05, 2016, 01:53:02 am »
Yikes. It feels like on a lot of this you are going to way more trouble than should be needed 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. I think I might actually have been providing a bad sqlite3.dll with my previous releases, which could have been the problem. That is fixed in the new archive I had sent you. I don't really see an easier way to do distribute this without the dlls as separate files in the archive. I'm not big on installers. The first of two small issues is that ListImporter is intolerant of blank lines in the m3u (e.g., at the end). I have updated the code to ignore lines that are blank or only have whitespace. It is up on github and I will included it on my next executable install. The second small issue is that any error in one track reference causes the entire import to abort with Errorlevel set to 1. [...] This is always something I haven't really been sure how to handle. Do you have any suggestions? I guess I could include a batch error mode that would be the default... (a) execution message output appears to go to stderr vs. stdout, which can interfere with batch file output piping for logging/analysis purposes I believe throwing errors to stderr is the proper behavior. Would it help if I included a parameter flag that instead pushed everything through stdout? In bash shell environments, it's as simple as adding "2>&1" after your command. Not sure about windows. I think that covers everything you mentioned, minus track length. I just looked in the DB, and from a quick glance, I'm not actually sure where the track durations are stored for items on a playlist. I think I skipped that since I wanted to make a minimum number of modifications to the database and knew it would auto correct. [Edit] P.S. The latest version (have not compiled into exe yet) allows dragging playlists onto the executable.
Posted by: Skipper42
« on: July 04, 2016, 03:15:18 pm »
The latest ListImporter version for Windows works like a champ - thanks!I've successfully tested with:- Both relative and absolute paths to track files in the m3u
- With m3u's exported from MediaMonkey (aka MM; ver 4.1.12.1798; I'll let you know if this changes with the latest version, 4.1.13.1801)
- With m3u's exported from Mp3tag, and
- With m3u's exported from my iBasso DX90.
I confirmed that byte order no longer matters; I no longer have to go thru the extra pass through EditPad Lite to drop the BOM.If an actual file cannot be found from its m3u reference, I've confirmed that ListImporter correctly notifies the user of the path and filename of the file it cannot find (with one exception; please see below).If errors are encountered, ListImporter correctly sets Errorlevel so it can be checked in a batch file. Thus, I can use this to avoid prematurely archiving failed import playlists until the issues are resolved.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.I did find a couple of small residual issues plus a couple of what you're free to view as extremely minor quibbles.The first of two small issues is that ListImporter is intolerant of blank lines in the m3u (e.g., at the end). This leads to the mysterious error message that the track file must be located relative to the playlist, but since the reference line is a blank, there's no file reported. Took some lengthy trial and error to find what was causing the glitch. I'll note that part of my confusion was that the same error message ("relative to") appeared irrespective of whether I was using dot notation relative paths or absolute paths for the track references (I suspect this is a holdover from versions prior to those permitting absolute path references).The second small issue is that any error in one track reference causes the entire import to abort with Errorlevel set to 1. That meant the original m3u with one or more blank lines would abort, while trying to identify the problem track reference by successive runs each with a new reference added from the original always was successful. That's actually how I tumbled to the blank line intolerance.My benchmark for whether the m3u had valid references has been Florian Heidenreich's excellent freeware Mp3tag (http://www.mp3tag.de/en/). In sum, if Mp3tag can import all the rows successfully, then I can safely assume the m3u is valid; it reports any track files it cannot find. That means anyone should be able to debug issues with ListImporter using Mp3tag to test the m3u's track file references for validity (plus verifying that the track files can be played independently in Plex).I also use Mp3tag to convert relative paths in m3u's to absolute or relative paths matching the location of the m3u file to be imported to Plex. MM's relative paths are relative to where the m3u is originally stored). MM is a far richer playlist editor/maker than Plex, so combining your tool with my methods gives me the best of both worlds.The .mte export configuration file I use in Mp3tag is:$filename(<path>\to_import\Plex.m3u,utf-8)$loop(%_counter%)%_folderpath%%_filename_ext%$loopend()...with care to have the file end after the $loopend() statement so as not to generate the blank line that ListImporter thinks is an invalid track reference. In my case, E:\Users\Public\Music\My Playlists\! Plex Playlists\ is the folder also containing the ListImporter .exe, .dll's and ppibatch.bat file.Once exported, I rename Plex.m3u to whatever I want the playlist name to be. Note: to export with relative vs. absolute paths, change %_folderpath% to %_folderpath_rel%, tho ListImporter always worked irrespective of which was used.The two minor quibbles are (a) execution message output appears to go to stderr vs. stdout, which can interfere with batch file output piping for logging/analysis purposes, and (b) delays/problems updating the track length once the playlist has been imported into Plex (an issue I noted in a previous post).The batch file I use (ppibatch.bat, attached) presumes the m3u playlists to be imported are in a particular 'to_import' folder, and if the import of each is successful, the m3u file is moved to an 'imported' folder in the same hierarchy.In the batch file, I used UTF-8 encoding, but set it explicitly in the command line vs. relying on the default. Ditto the file type setting (explicitly 'mp3' vs. default). These were more for self-documentation than any requirement to do so; worked fine with the defaults. Ditto the location of the Plex database.When piped to a log file, each execution in my batch file generates an entry of the following form:Sat 07/02/2016 14:38:28.48PlexPlaylistImporter.exe -f -e utf-8 -t m3u "<path>\to_import\5hr Playlist.m3u" "5hr Playlist"73 items imported 1 file(s) moved....showing there could be value in having error messages, etc. in the consolidated app+OS output also.The track length update problem seems to be avoidable if one turns on frequent Library updating and updating of the Library with any change to the Library, prior to importing the m3u. If that's not done, the track lengths of some tracks remain at 0:00 after import. This also means the overall playlist length will be misreported until each of the 0:00 tracks is launched and another track launched afterward, at which point Plex updates the playlist track length entry and overall playlist length. Even forcing Library updates failed to update the track and playlist lengths.I cannot tell from info available to me here whether the track length update problem is a Plex bug/feature (they clearly have yet to envision importing m3u playlists, and thus without your tool would have no way to test for this bug!) or whether there's some other additional Plex database field references that need updating in your update query SQL (e.g., possibley a field in a different table from the main Playlist records). Regardless, once I turned on frequent Library updating/updating after every change, the problem seemed to disappear.With all that in mind, and given the general end-to-end utility now available, I recommend you post an update to the Plex Forum that details these working methods. Please feel free to share my Mp3tag export .mte above and batch import method's .bat file attached in your post.Thanks again very much for all your efforts here. This has now made Plex finally usable for me!
Posted by: Dakusan
« on: July 01, 2016, 04:16:31 am »
I have made multiple updates to the software and recompiled it. I have attached it to this post if you want to check it out. I confirmed that it worked fine in command prompt with your m3u file. Update log is on github. P.S. If possible, please let me know within the next few days if all is well now. Would like to get the confirmed updates and compilation up on my website.
Posted by: Dakusan
« on: June 25, 2016, 03:24:48 am »
I'm working on updating the software this weekend.
Posted by: Skipper42
« on: June 20, 2016, 08:52:25 pm »
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.
|
|