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. Just FYI - the error message always says "relative" even if absolute path addressing is used (likely an artifact of your absolute addressing quick fix).
In this case, the e-umlaut (ë) has a decimal character code of 235 (+00EB).ĭoesn't matter whether in this example is relative ("dot notation") or absolute (:). 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):\Music Library\Saint-Sa\xc3«ns\Violin Concerto No. If the path (artist, album) or track filename contain other than basic alphanumeric characters thru ~ (code \Music Library\Saint-Saëns\Violin Concerto No. Now on to the character set/codespace problem.
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? 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. 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.
I noticed that it took a while for the data to propagate there, however. 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. There's no Refresh opportunity in the Playlist dialogue to force this otherwise. 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. In both cases - playlist or music browse - Plex plays the track correctly. mp3 file, and when one browses to the album in Plex, it, too, has the track length correctly shown.
A quick check with mp3tag showed the metadata for length as indeed being included in the. Further, when the playlist is opened in Plex, all the track lengths are shown as 0:00. 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. Unless there are character codes beyond the basic alphabet (see below for a description of this newly discovered problem), the. m3u created in another app (e.g., MediaMonkey, mp3tag, Notepad) and resave it with no BOM.
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.