rpedde wrote:
probably process_m3u. WIthout process_m3u, it won’t scan playlists (including itunes xml)
— Ron
Ok, I tried that (with the latest nightly). Tried all of the following possibilities (since I wasn’t sure of the correct syntax):
#process_m3u=1
#process_m3u 1
process_m3u=1
process_m3u 1
none of them worked. As I said, I pasted the XML and playlist files from my windows machine to the folder (on the NSLU2) which contains the WAV files.
Mt-daapd can find all the files but it cannot read the meatadata contained in the XML file, so with over 4200 files it’s not feasible to browse for songs on the Roku Soundbridge, as all I get is a file name, no artist, album, etc.
So I tried going back to a previous build (01 March). Chose this one because apparently some major changes to the database handling/searching were implemented after this build, am I correct?
This time, the only changes made to the configuration file were
1- the path to the WAV files parent folder
2- included ,.wav in the list of extensions to scan for.
(no changes to the process_m3u)
This build found all the songs like the other, but it was also able to read the associated info for all files except those containing latin characters, like “á”, “ã”, “â” and the like. It hasn’t found the playlists yet, but that’s probably because I still haven’t turned process_m3u on, right?
So, my question is twofold:
1- Is it feasible for you to implement a feature/option whereby one specifies a folder where mt-daapd searches for XML and playlist files, and then associates that info with the existing WAV files, even if the paths aren’t “UNIXy” as you mention.
2- is mt-daapd incapable of handling files with special characters?
cheers