Please support directories in .m3u files
Audacious currently doesn't handle directories in .m3u files, giving the error:
File format not recognized
Expected behaviour: audacious should play the files contained in the directory, as it currently happens when running
#2 Updated by Cristian Rigamonti over 1 year ago
Absolute (full) or relative directories or both? Windows or Linux/Unix? Can you provide example?
Audacios 3.7.2 on Linux. I've tried both absolute and relative paths, none works.
Example: just put the name of a directory that contains media files in a test.m3u file, then run audacious test.m3u
#4 Updated by Jim Turner over 1 year ago
Thanks for clarifying. I checked and indeed, it doesn't work. It doesn't look like it's part of the basic m3u format, but the wiki indicates that it's an "extended" feature. The m3u plugin code looks similar to that of audacious/main.cc which can load a list of entries from the command line (which DOES handle directories), so it seems like it should work but doesn't. I'll look into it myself, but for now, you'll pbly have to wait and see what, if anything, John wants to do a/b it as I not part of the Audacious team myself, but have contributed patches and have worked a bit with that particular (m3u plugin) code before. What's your email?
#5 Updated by John Lindgren over 1 year ago
- Description updated (diff)
- Category set to libaudcore
- Status changed from New to Closed
- Target version set to 3.9
- % Done changed from 0 to 100
Jim, the m3u plugin is very simple and doesn't know (nor need to know) anything about folders. The relevant code is in libaudcore/adder.cc.
This is actually trivial to implement; in fact, a net removal of code. My concern was that it could lead to infinite recursion (think of an .m3u file containing the single relative path "."), but actually we wouldn't try to add the .m3u file again in that case, so we're okay.
#6 Updated by Jim Turner over 1 year ago
Thanks John for the quick fix on this - savin' me some research / work! I didn't know nor care a/b the issue until someone complained, and it looked like it was a pretty logical and pbly. somewhat easy feature to implement / contribute. I tried it out & it seems to work fine here!
I'm assuming the OP's not looking for some wildcard stuff like: "/path/*.mp3", etc. as that does NOT work (wildcard chars are translated to stuff like %21, etc. whereas the command line wildcards do work, I presume b/c they are expanded by the shell). Besides, that's not even in the "extended m3u" spec.