playlists Android Poweramp not accepting Linux/WINE playlist files

[baconneggs]

I'm running the latest version of Poweramp on Android (non-Google version) and have tried every playlist file format under the sun exported from MusicBee (.m3u, .m3u8, .pla, mbp, etc) and all fail to be recognized by Poweramp in Android.
All my music syncs and plays directly via USB from MusicBee perfectly fine as a virtual device.

Steps to Reproduce Issue:

1. Export playlist file(s) from MusicBee
2. Plug in Pixel 4 and enable file transfer on Pixel
3. Drag playlist file to mounted Pixel 4 directory (mtp:..) via Linux Mint 20 Cinnamon PC running WINE
4. Reboot Pixel 4
5. Open Poweramp and run Full Rescan
6. Open playlist and it is empty while the music files are still in library
7. Run Resolve/rescan within playlist and it still remains empty

It's worth noting, trying to sync directly via MusicBee also fails with the following error lines within log file:

12/27/2020 2:48:30 PM - MTP device detection failed=Retrieving the COM class factory for component with CLSID {0AF10CEC-2ECD-XXXX-XXXX-3XXXXXXXX} failed due to the following error: 80040154 Exception from HRESULT: 0x80040154 (REGDB_E_CLASSNOTREG).
12/27/2020 2:49:10 PM - Add playlist "C:\users\joe\Desktop\MusicBee\Playlists\Testplaylist.mbp" General failure. [P:\Music\Playlists\Testplaylist.mbp]
12/27/2020 2:49:10 PM - General failure. [P:\Music\Playlists\Testplaylist.mbp]

This MusicBee sync error is the same regardless of file format and I'm sure is related to what is happening when the Full Rescan in Poweramp fails to load the playlists from the .m3u files moved over manually.
Haven't found much of anything online in terms of how to workaround that error within Linux + WINE.

Example MusicBee .m3u8 playlist file:

T:\iTunes\iTunes Music\Artist1\Album1\2-04 Song (Live).m4a
T:\iTunes\iTunes Media\Music\The Elders\Unknown Album\Song1.m4a
...

Does anyone know any other workarounds for Poweramp to move playlist files from Linx Mint(Ubuntu) WINE to Android?
Would be happy to build a bash job to run each time I want to update playlists if it's a directory or syntax issue in the files themselves, but for whatever reason every playlist I've tried is being rejected by Poweramp. 

Is there at least a way to filter some sort of 'tag' or 'label' within Poweramp so I can theoretically simulate playlist creation that way?

Any help would be really appreciated on this.

[Absinthequ]

The T:\ and P:\ are PC Drive paths. That looks like your problem.

So make sure your playlists folder is in the root folder of your music.

Then open a playlist in a text editor and use the "Find and Replace" tool to remove the Drive path "T:\" or "P:\" and replace all with "..\"

EXAMPLE:

T:\iTunes\iTunes Media\Music\The Elders\Unknown Album\Song1.m4a

Becomes

..\iTunes\iTunes Media\Music\The Elders\Unknown Album\Song1.m4a

This will keep the playlists compatible with your PC and android. When you click on a playlist, the "..\" tells the player to back out of the current (playlist) folder and start looking for music there. This also seems to fix it so Poweramp can find it.

In this example above, your playlist folder will be on your drive "T:\Playlists" or "P:\Playlists". Those letters are uniquely assigned by each PC so they may vary and is why android gets confused.

[andrewilley]

Do you see the playlists in the Library > Playlists category but with no song contents, or do the playlist names not even show up? 

Poweramp actually ignores most of the path information in .M3U or .M3U8 files, to avoid exactly the problems described above where root paths may vary from device to device. All that needs to be matched are the exact filename and the first level of foldername that it is stored within. So for example to match the snippet you quoted, the two music files must be on your local device in a scannable location and thus present in Poweramp's library, and the file 2-04 Song (Live).m4a needs to be inside a folder called Album1, while the file Song1.m4a needs to be inside a folder called Unknown Album. The rest of the path info is irrelevant to PA. Then make sure that the playlist .M3U file is also in a scannable location, and PA should find and load the playlist and find its contents from the library (try a Full Rescan if this does not happen).

Andre

[Absinthequ]

16 minutes ago, andrewilley said:

Do you see the playlists in the Library > Playlists category but with no song contents, or do the playlist names not even show up? 

Poweramp actually ignores most of the path information in .M3U or .M3U8 files, to avoid exactly the problems described above where root paths may vary from device to device. All that needs to be matched are the exact filename and the first level of foldername that it is stored within. So for example to match the snippet you quoted, the two music files must be on your local device in a scannable location and thus present in Poweramp's library, and the file 2-04 Song (Live).m4a needs to be inside a folder called Album1, while the file Song1.m4a needs to be inside a folder called Unknown Album. The rest of the path info is irrelevant to PA. Then make sure that the playlist .M3U file is also in a scannable location, and PA should find and load the playlist and find its contents from the library (try a Full Rescan if this does not happen).

Andre

If Poweramp does not recognize something in the path line it will not find the song(s). It struggles with Drive letters and Unicode symbols.

I make a playlist every week using Winamp on my PC and I also use Unicode symbols like ⚡ ♒⛔❌ in some of my folders, so I've stumbled onto this a hundred times. The files scan fine to the library but Poweramp will not read them in my external m3u3 playlists. Every now and again I download a song off a website and it will have this annoying dash - that looks almost identical to a normal keyboard dash, but it's apparently a Unicode Dash and Poweramp will not recognize a song in a playlists with this unique dash in the filename. That one actually just got me again last week. 

[andrewilley]

7 hours ago, Absinthequ said:

If Poweramp does not recognize something in the path line it will not find the song(s). It struggles with Drive letters and Unicode symbols.

Drive letters - in fact all path elements prior to the final foldername - are ignored, you don't need to worry about them at all.

Unicode symbols are not supported in plain ASCII files (which is the official spec for the M3U format) but are fine as long as the playlist file is marked as being UTF-8 format. This can be done by using a Unicode-compatible editor, and ideally for neatness-sake naming the file with an .M3U8 extender. However this does not appear to be the issue in this case as the paths and filenames referred to seem to be plain ASCII text, and the playlist is M3U8 format anyway. PA can be forced to read M3U files as Unicode too, in Settings > Library > Scanner, otherwise the Tag Encoding setting is used for M3U files. My own preference is to properly save Unicode files with BOM (Byte order Mark) enabled, to let PA know the exact format that's in use, but this often doesn't matter and the default usually works fine.

Andre

[Absinthequ]

4 hours ago, andrewilley said:

Drive letters - in fact all path elements prior to the final foldername - are ignored, you don't need to worry about them at all.

Unicode symbols are not supported in plain ASCII files (which is the official spec for the M3U format) but are fine as long as the playlist file is marked as being UTF-8 format. This can be done by using a Unicode-compatible editor, and ideally for neatness-sake naming the file with an .M3U8 extender. However this does not appear to be the issue in this case as the paths and filenames referred to seem to be plain ASCII text, and the playlist is M3U8 format anyway. PA can be forced to read M3U files as Unicode too, in Settings > Library > Scanner, otherwise the Tag Encoding setting is used for M3U files. My own preference is to properly save Unicode files with BOM (Byte order Mark) enabled, to let PA know the exact format that's in use, but this often doesn't matter and the default usually works fine.

Andre

I'm sure you're right, that this has more to do with the playlist creator you are using choosing a proper format Poweramp can read when saving the playlist. This still means Poweramp will struggle with something in the paths if the playlist is not Poweramp friendly..

Here is an example:

Artist – Track 1.mp3
Artist - Track 2.mp3

...notice the slightly longer dash in Track 1. This is an "En Dash" and for some reason some websites like to use it.

I Save this as a m3u using winamp and I even tried saving just what you see above with a text editor using UTF-8 encoding and Poweramp simply will not recognize that first song unless this is saved as a m3u8. With or without "Always use UTF-8 for .m3u" enabled. I'm not sure if any other formats are affected but this the one I primarily use. Maybe changing my language in Poweramp fixes this problem, but then I create many other problems.

[andrewilley]

Dashes, and quotation-marks/apostrophes, exist in multiple forms in typesetting and thus website/HTML/computer code too. And for a song in a playlist to match with a filename the characters must match exactly not just visually. These are just some of the more common dashes (and only the first can be represented in regular 7-bit ASCII):

- (hyphen, or minus sign, ASCII 45)
‐ (HTML code ‐)
‒ (figure dash, U+2012) (approx width of a monospaced number, for tabular use)
– (en dash, U+2013) (approx width of letter N, suggested for normal use in documents as a separator between clauses in a sentence)
— (em dash, U+2014 (approx width of letter M)
― (horizontal bar, U+2015)

And for single-quotes you can have a regular keyboard apostrophe ('), plain single quote ("), left-single-quote (‘), right-single-quote (&rsquo), and even a grave accent (` ASCII 96) or acute accent (´  ASCII 239).

This is why 7-bit ASCII's basic 95 characters, and even extended 8-bit ASCII, got superseded by Unicode-8 or Unicode-16. But whatever you call them, the entry in a playlist must use the same character as the filename. If you are using Unicode, it's best to name the file with a .M3U8 extender so it can't be ambiguous. Or should that be can`t? Or can’t? or can‘t?

Andre

[baconneggs]

Quote

Do you see the playlists in the Library > Playlists category but with no song contents, or do the playlist names not even show up? 

@andrewilley I do see them, no matter what format I can always confirm Poweramp 'receives' them but doesn't recognize the contents (they're empty) even after full rescan and device reboot. Even the cleanly converted to .M3U8 files were not being read. I'll try to dig deeper into any differences I notice between the 2. Just cannot figure out what is being 'rejected/ignored' by PA within the playlist files.

Quote

Then open a playlist in a text editor and use the "Find and Replace" tool to remove the Drive path "T:\" or "P:\" and replace all with "..\"

@Absinthequ, anything is worth a shot at this point.

Fwiw, I've been using PlaylistSync in Linux for .m3u/.m3u8 file conversion. https://playlistsync.app/

I really appreciate the help from both of you either way. I'll continue working through the issue.

[andrewilley]

Could you upload a copy of one of your playlist files here? Directly from your phone ideally, not the computer's copy.

Andre

[Absinthequ]

I'm not sure where you misunderstood to think there is a mismatch.  Simply put a file with the en dash – in any file and Poweramp will not recognize it even with Utf-8 encoding. All million plus Unicode characters should work in this format.

Obviously if you're purposely using Unicode characters you should prefer m3u8 as it's better supported. But most people have no idea there's a difference in dashes or unicode characters and that an unsuspecting dash that was already in place when they downloaded the file, will cause problems in their playlists.

There's always a logical reason and solution for every bug. No amount of explanation will take away the fact It's still a bug. 

[maxmp]

@baconneggs please share one of such playlists (here or via gpmaxmpz@gmail.com) for tests. Thanks!

[andrewilley]

@Absinthequ We are drifting a bit off topic here, but on my PC I renamed two MP3 files to contain both an endash (Alt+0150) and an emdash (Alt+0151). I then created a simple .M3U8 playlist file (UTF-8 character encoding, with BOM) which pointed to both of these files. I then copied them all over to my phone's music folder (used FTP transfer, via wi-fi). Everything scanned correctly into PA, and the two files played correctly either from the Folders list or the Playlist.

Filename with – en-dash.mp3
Filename with – — 0150 en and 0151 em dashes.mp3

So Poweramp itself works fine with extended Unicode characters in filenames and playlists - as long as they 100% match each other of course.

Andre

[Absinthequ]

This topic is about playlists not reading in Poweramp for whatever reason. I have been trying to shed light on an example of this...

I already said I can get the en dash to work in Poweramp with a UTF-8 encoded playlist. I have been talking about a standard m3u playlist not working with an en dash. My Sony Music app on my phone has no problem reading a standard m3u with the en dash. Only Poweramp has a problem.

Anyways I figured out what the bug is. It turns out En Dash is one of the standard 256 ANSI characters. It is not UTF-8 but is available in UTF-8 as is all of the ANSI characters. It appears in Poweramp for some reason, that some standard ANSI characters (like en dash) are set to only work in UTF-8 encoded playlists. This is odd because by default, most playlists creators save m3u as ANSI and would not flag this character as needing to go into a UTF-8 Encoded format. An m3u with UTF-8 encoding is an m3u8. The 8 is just for show and is not necessary for the file to work the same. 

[andrewilley]

@Absinthequ This thread is about @baconneggs specific issues with syncing Linux/WINE playlist files, and the examples he has given have plain text filenames with no en-dashes, so yes this is getting off-topic and may need moving to its own thread.

That said... M3U files should contain plain printable text content only, which historically means ASCII 32-126. You may find some Extended ASCII (128-255) codes work in PA playlists, but personally I've never found them safely reliable. e.g. my own correct name - André - does not work in a plain ASCII M3U file as it uses code 130, so I need to use Unicode/UTF-8 for any playlists that contain my accented name (or any other accents). ANSI is not the same as Extended ASCII by the way, it uses a different mapping table and can vary by regional setting too - my own accented é is code 233 in Latin Windows (codepage 1252) for example.

Of course many editors actually save in Unicode by default anyway, and even if you give such a file an .M3U extender it is still generally recognised and read correctly - with or without the Force option being enabled in Settings > Library > Scanner.

In short, don't rely on plain ASCII beyond 126, as results can be unpredictable. Use Unicode.

Andre

[maxmp]

Note that Windows and Linux (which Android is variation of) differently handle unicode file names. Linux doesn’t interpret file name in any way and just uses the series of bytes as is, meaning filename should match exactly byte to byte.
 

Windows may reinterpret some unicode symbols to another (for case insensitivity mostly, but also some other substitutions happen, especially everything related to unbreakable spaces and other “control” unicode symbols, separate umlauts, etc.).

This potentially may make the playlist which works fine on Windows to fail with Poweramp, this is why I would like to test such playlist (and preferable the track which fails to be found).

Thanks!

[baconneggs]

Found out MusicBee is defaulting to built-in appending of every song file with a Album Track # and exact Title as well as exact Album (song's parent folder).
This leads me to think (as @andrewilley mentioned earlier) it's simply the directory mapping that is breaking the playlists, specifically the filenames. (The .m3u files obviously all contain the WINE/Linux song file directories)

I'm going to run the tests starting from scratch disabling the pre-formatted sync options in MusicBee, re-uploading song files then trying the .m3u's then.
The other option if that also fails is to just bypass the music player and drop the Linux audio file directories straight into the Pixel via MTP but would really rather this process be sustainable through software sync rather than manually.

If both of these options still fail I'll post the .m3u's here and continue drinking heavily. Thanks a ton again for all the help. 

[andrewilley]

2 hours ago, baconneggs said:

Found out MusicBee is defaulting to built-in appending of every song file with a Album Track # and exact Title as well as exact Album (song's parent folder).
This leads me to think (as @andrewilley mentioned earlier) it's simply the directory mapping that is breaking the playlists, specifically the filenames.

As I said earlier in the thread, the root path details are ignored as they will vary from device to device. However, in order to create a playlist match for a specific audio file, the audio filename itself must be quoted identically in the playlist, and the first level of folder that it is contained within must match exactly too.

So in your original example playlist

T:\iTunes\iTunes Music\Artist1\Album1\2-04 Song (Live).m4a
T:\iTunes\iTunes Media\Music\The Elders\Unknown Album\Song1.m4a
...

it will only work if the file 2-04 Song (Live).m4a is inside a folder called Album1, while the file Song1.m4a needs to be inside a folder called Unknown Album. Any variation, or renaming of the folder or filenames, will break the link.

Andre

[baconneggs]

Yep, that's indeed all it was @andrewilley...Poweramp's now seeing every song in all +30 playlists after reverting to original Linux/WINE song filenames and directories.  The only other thing I did was convert to Unix format ('\' to '/' in the directories).
Thank you all again for the help!

Interestingly, my PC completely locks up when transferring some of the longer .m3u's via USB cable, Linux throws me some generic MTP file transfer error and freezes the Nemo file system. Will look into that later.

libmtp error: could not send object

Luckily I don't need to transfer anything manually it's just reading the Unix .m3u's from my shared Android NextCloud folder fine.

I'll still maintain my playlists through WINE though, so will build a quick job to handle the tasks below: 

1. Copy WINE .m3u's to shared Nextcloud folder (replacing if exists) 
2. Find & replace '\' with '/' in all Nextcloud folder .m3u's

Not sure if there's any better recommendations for more-or-less automating this current setup. Either way, I really appreciate all the help here 🍻

[andrewilley]

Glad you've got it sorted. Yes, if the exact filenames, or the first containing folder names, do not exactly match with the physical contents of your file system then your playlists could never work.

PA itself doesn't care about differentiating Linux/UNIX/Android "/" path separators vs. Windows/DOS "\" separators, it handles them both interchangeably, so no need to go to any bother editing them. I'm not sure why a UNIX/Linux system would be using Windows "\" in the first place anyway - although if you originally created the files in WINE then those would have the Windows variant and might not work in UNIX. PA would be happy either way though.

Copying files manually via an OS shouldn't care what the contents are, for safely they should always be treated as pure binary content and if you can copy big MP3 files you should be able to copy comparatively small M3U files too. Some FTP transfer systems allow specific file types to be treated as containing ASCII text content, which might then convert Windows-style CR/LF ("\r\n") line-ends to UNIX LF ("\n") or Mac CR ("\r") for example, but that would never be an OS's copying default. Again, I believe PA would be happy with any of the three common line-end variants anyway.

Andre

[baconneggs]

Thanks for the clarity around the Unix vs. Win formatting.
Oddly, when I tried keeping Win .m3u format '\' (exported from WINE in Linux) PA actually missed ~.5% of the songs in the 2 playlists it picked up. I didn't dig deep enough to see exactly why those lines in the .m3u file were being rejected but converting to Unix immediately resolved the issue.

It's a really simple terminal sequence so I'm not bothered too much by having to convert that way for now. (combination of "cp" to copy the WINE files to Nextcloud and "sed" to replace '\' in their content)

[andrewilley]

It certainly won't do any harm to convert Windows' "\" to Linux/Android's "/", I was just saying that you shouldn't really need to if it's any hassle. In fact I keep all of my playlists in Windows format, so I can freely use and test the same files on my PC and just copy them directly over to my phone's file system.

Andre