Post by maddoug on May 19, 2021 8:58:23 GMT -5
Recently I created a new playlist using mp3tag and decided to see if I could import it to GMMP. I maintain a folder structure for all my music like,
...\Music\<ARTIST>\<ALBUM>\(<DISC>)\<SONG>
This folder structure is replicated on all devices I play and store music on to keep my world simple.
However, after copying the playlist to the "Music" directory on my phone's microSD card, I discovered that things weren't working at all. With some help from the developer and some legwork of my own, I managed to resolve all the issues and I can now copy and use m3u playlists created by mp3tag and they work with GMMP flawlessly!
PROBLEM: Newly copied m3u playlist not visible in "Playlist" menu in GMMP
TL; DR SOLUTION: Run a manual scan from GMMP, e.g. Settings -> Scanner -> Start Scan.
FULL SOLUTION: GMMP depends on Android to indicate when the media library has updated and it looks like m3u files don't trigger this. Typically I pull the card and use FreeFileSync to update the music library (doesn't work with Windohs MTP) so when I initially copied the file manually it appeared automatically when I re-mounted the card in my phone. Most likely that event caused a full media library refresh in Android to occur (or maybe GMMP rescanned.) But in future iterations when I copied the file via Windohs MTP (USB connection to phone with card inserted) I always had to rescan in GMMP to get the playlist to be detected.
PROBLEM: Playlist menu actions (play, shuffle, queue, etc.) fail to take any action, or
selecting files from list to play works sporadically and with large delay, or
files listed in queue are incomplete with many missing
TL; DR SOLUTION: Make sure the (root) path that contains all music is explicitly listed in scanner paths (and remove others which are subdirs or unused.)
FULL SOLUTION: This was the main cause of my playlist issues. It turns out this was largely a pathing problem. After a significant amount of fiddling around with the file content, location, and format, I noticed my GMMP scan paths were like,
/storage/0000-0000
/storage/emulated/0
/storage/emulated/0/Music
HOWEVER, the playlist m3u file was contained in the following path on my microSD card (per my standard folder structure above):
/storage/0000-00000/Music
As it turns out, GMMP will try to find files listed in playlists which aren't directly listed in any of the configured paths. So that's why some actions like selecting a file and playing it right from the list worked to some degree, just really slowly. Because my "Music" folder was a subdirectory of the first path above, GMMP was able to eventually find some files. With over 2500 files not where they should be I'm sure this explains some of the behavior I saw with things taking a long time (missing files should be the exception, not the rule.)
I honestly can't remember if I populated all those paths above when trying to locate my microSD card storage years back or if they maybe carried over from my previous phone, or possibly even GMMP just adds the "emulated" ones on its own.
I decided I didn't need the emulated paths (which are an Android legacy format that actually point to the phone internal storage which I never use for media) so I removed them. Then I added a new scanner path to the "Music" directory above (/storage/0000-00000/Music) and removed the entry to its parent path /storage/0000-00000.
Now with only a single valid path to the root of my music directory structure, all began working flawlessly!
PROBLEM: Some files are not populated in the play queue.
TL;DR SOLUTION: Make sure filenames and playlist entries are completely consistent (i.e. no missing/extra chars.) and make sure playlists are encoded as UTF-8
FULL SOLUTION: After fixing things above I noticed that when I added the playlist entries to the queue, the count was short by a few files. There were a couple reasons for this:
1) After diff'ing (with Meld) the original directory structure against what was on the microSD card I discovered a few files that had extra or missing spaces in the names, mostly around dashes used to separate medley titles and/or various artists. To check this, I printed the complete directory listing of each location in Windohs cmd (using `dir /b /s <path>`) and then opened the files in a text editor (emacs) where I used search/replace to get rid of the different parent paths so what remained in each file was from the same "Music" root directory reference. Then just load these two files into Meld (or the diff tool of your choice) and any differences will be readily apparent and easily resolved.
2) With filename issues resolved I noted that one file was still missing from the queue. Since I knew all the filenames and playlist entries were consistent, my hunch was that some non-ASCII character in a filename might be causing the problem. Searching for non-ASCII characters in emacs is trivial by using a regexp search for pattern [[:nonascii:]] and when I did this I found a single file with an accented "e" character (e.g. "é") in the filename. It appeared properly in the playlist and in the filename so I didn't understand why it didn't work. And native playlists made in GMMP which contained the same file worked fine. I coped a few of GMMPs playlists to my PC and loaded them in emacs and noticed these extended chars didn't display properly so immediately I knew it was a coding problem (emacs in Windohs defaults to opening files as iso-latin-1). When I loaded playlists that were created with GMMP they only appeared properly if I loaded them as UTF-8. So I saved my ANSI/iso-latin-1 formatted playlist as UTF-8, re-copied it to the microSD card, and now that file with the extended character properly showed its properties and played/added to the queue.
TIP: to determine what encoding your playlist is using in Windohs, open it in regular old Notepad and do a "Save as..." then check the "Encoding:" field at the bottom of the save window to see what encoding it currently has (yeah, I know its a "guess".) If it's not UTF-8, select that and save it to reencode it that format for GMMP.
TIP: if you don't have any non-ANSI characters in a playlist then it might "just work" but in general always make sure its saved/encoded as UTF-8 before importing to GMMP
PROBLEM: I made my playlist in Windohs which uses a different file system path format, will it work in GMMP?
SOLUTION: GMMP handles this and automatically translates DOS path backslashes ("\") as slashes ("/") to normalize the path so it "just works".
PROBLEM: Compared to native GMMP playlists, my imported playlist has tons of "extra" lines that start with "#EXT", will it work in GMMP?
SOLUTION: Applications like mp3tag generate m3u files with full metadata descriptor support (i.e. lines that start with "#EXT") for use by some players. While these lines can be safely removed, they're ignored by GMMP.
Hope this helps those having issues importing playlists for use with GMMP and please do add on anything I may not have covered above.
...\Music\<ARTIST>\<ALBUM>\(<DISC>)\<SONG>
This folder structure is replicated on all devices I play and store music on to keep my world simple.
However, after copying the playlist to the "Music" directory on my phone's microSD card, I discovered that things weren't working at all. With some help from the developer and some legwork of my own, I managed to resolve all the issues and I can now copy and use m3u playlists created by mp3tag and they work with GMMP flawlessly!
PROBLEM: Newly copied m3u playlist not visible in "Playlist" menu in GMMP
TL; DR SOLUTION: Run a manual scan from GMMP, e.g. Settings -> Scanner -> Start Scan.
FULL SOLUTION: GMMP depends on Android to indicate when the media library has updated and it looks like m3u files don't trigger this. Typically I pull the card and use FreeFileSync to update the music library (doesn't work with Windohs MTP) so when I initially copied the file manually it appeared automatically when I re-mounted the card in my phone. Most likely that event caused a full media library refresh in Android to occur (or maybe GMMP rescanned.) But in future iterations when I copied the file via Windohs MTP (USB connection to phone with card inserted) I always had to rescan in GMMP to get the playlist to be detected.
PROBLEM: Playlist menu actions (play, shuffle, queue, etc.) fail to take any action, or
selecting files from list to play works sporadically and with large delay, or
files listed in queue are incomplete with many missing
TL; DR SOLUTION: Make sure the (root) path that contains all music is explicitly listed in scanner paths (and remove others which are subdirs or unused.)
FULL SOLUTION: This was the main cause of my playlist issues. It turns out this was largely a pathing problem. After a significant amount of fiddling around with the file content, location, and format, I noticed my GMMP scan paths were like,
/storage/0000-0000
/storage/emulated/0
/storage/emulated/0/Music
HOWEVER, the playlist m3u file was contained in the following path on my microSD card (per my standard folder structure above):
/storage/0000-00000/Music
As it turns out, GMMP will try to find files listed in playlists which aren't directly listed in any of the configured paths. So that's why some actions like selecting a file and playing it right from the list worked to some degree, just really slowly. Because my "Music" folder was a subdirectory of the first path above, GMMP was able to eventually find some files. With over 2500 files not where they should be I'm sure this explains some of the behavior I saw with things taking a long time (missing files should be the exception, not the rule.)
I honestly can't remember if I populated all those paths above when trying to locate my microSD card storage years back or if they maybe carried over from my previous phone, or possibly even GMMP just adds the "emulated" ones on its own.
I decided I didn't need the emulated paths (which are an Android legacy format that actually point to the phone internal storage which I never use for media) so I removed them. Then I added a new scanner path to the "Music" directory above (/storage/0000-00000/Music) and removed the entry to its parent path /storage/0000-00000.
Now with only a single valid path to the root of my music directory structure, all began working flawlessly!
PROBLEM: Some files are not populated in the play queue.
TL;DR SOLUTION: Make sure filenames and playlist entries are completely consistent (i.e. no missing/extra chars.) and make sure playlists are encoded as UTF-8
FULL SOLUTION: After fixing things above I noticed that when I added the playlist entries to the queue, the count was short by a few files. There were a couple reasons for this:
1) After diff'ing (with Meld) the original directory structure against what was on the microSD card I discovered a few files that had extra or missing spaces in the names, mostly around dashes used to separate medley titles and/or various artists. To check this, I printed the complete directory listing of each location in Windohs cmd (using `dir /b /s <path>`) and then opened the files in a text editor (emacs) where I used search/replace to get rid of the different parent paths so what remained in each file was from the same "Music" root directory reference. Then just load these two files into Meld (or the diff tool of your choice) and any differences will be readily apparent and easily resolved.
2) With filename issues resolved I noted that one file was still missing from the queue. Since I knew all the filenames and playlist entries were consistent, my hunch was that some non-ASCII character in a filename might be causing the problem. Searching for non-ASCII characters in emacs is trivial by using a regexp search for pattern [[:nonascii:]] and when I did this I found a single file with an accented "e" character (e.g. "é") in the filename. It appeared properly in the playlist and in the filename so I didn't understand why it didn't work. And native playlists made in GMMP which contained the same file worked fine. I coped a few of GMMPs playlists to my PC and loaded them in emacs and noticed these extended chars didn't display properly so immediately I knew it was a coding problem (emacs in Windohs defaults to opening files as iso-latin-1). When I loaded playlists that were created with GMMP they only appeared properly if I loaded them as UTF-8. So I saved my ANSI/iso-latin-1 formatted playlist as UTF-8, re-copied it to the microSD card, and now that file with the extended character properly showed its properties and played/added to the queue.
TIP: to determine what encoding your playlist is using in Windohs, open it in regular old Notepad and do a "Save as..." then check the "Encoding:" field at the bottom of the save window to see what encoding it currently has (yeah, I know its a "guess".) If it's not UTF-8, select that and save it to reencode it that format for GMMP.
TIP: if you don't have any non-ANSI characters in a playlist then it might "just work" but in general always make sure its saved/encoded as UTF-8 before importing to GMMP
PROBLEM: I made my playlist in Windohs which uses a different file system path format, will it work in GMMP?
SOLUTION: GMMP handles this and automatically translates DOS path backslashes ("\") as slashes ("/") to normalize the path so it "just works".
PROBLEM: Compared to native GMMP playlists, my imported playlist has tons of "extra" lines that start with "#EXT", will it work in GMMP?
SOLUTION: Applications like mp3tag generate m3u files with full metadata descriptor support (i.e. lines that start with "#EXT") for use by some players. While these lines can be safely removed, they're ignored by GMMP.
Hope this helps those having issues importing playlists for use with GMMP and please do add on anything I may not have covered above.