Amberlamps
Formerly known as Phuca
Your post raised a nagging thought in my mind, that some 'golden rules' had been posted a few months ago.
I searched using the .m3u search term, and a few links do appear.
One example link is https://www.head-fi.org/threads/chord-electronics-☆-poly-☆-wireless-microsd-module-for-mojo-☆★►useful-info-on-1st-page-◄★☆.831347/page-573#post-14160218
I know that is not the same as your issue, but I am sure that factors like where the folder is located, can affect how the Poly used to treat the files a few months ago.
In an ideal world, the latest Poly firmware should handle .m3u files intuitively, but maybe we are not 100% there yet.
I suggest search the thread, because I am sure that there were other posts relating to Poly changing the m3u file name that was displayed.
The m3u problem is caused by poly indexing, either by removing and reinserting the sd card, which triggers an automatic index refresh or by refreshing the dlna database manually. Both ways causes it to happen.
When using quick play you have to make atleast 1 playlist before it will open, once you have made it and opened quick play, you can then, using cantata, make more playlists that can be seen in realtime as quickplay recognises a new playlist and adds it to the list.
Once the playlists have been made, never take the sd card out of poly or refresh the dlna database, if you do, it causes poly to re-index the sd cards contents, which now contain playlists with the m3u suffix. They were not there when the sd card was first inserted into poly and indexed for the very first time. Try it and see.
I was testing it today and it is repeatable, m3u at the end of playlists is solely caused by poly reindexing, either automatically by reimserting the sd card or manually by dlna refresh.
The good thing is, it is a very easy fix for chord to implement, hide known filetype extensions.
Boom headshot.
Last edited by a moderator: