Another stupid question

[Anonymous]

Before upgrading to unslung 6.8 I had the latest nightlies working just fine. All my files were WAV. I imported/ripped them with iTunes to my PC and then copied all the WAV files and XML+Playlist files to the NSLU2 attached hdd.

After changing the mt-daapd .conf file, mt-daapd could find all the information for the WAVs, like album name, artist, etc (which I believe is contained in the XML file).

Now I reinstalled everything, the latest build of mt-daapd can find the files but it cannot find the “metadata” contained in the XML file. Exactly which entry should I change in the .conf file to tell mt-daapd where to look for this and the Playlist info?

Sorry for the lame question.

cheers

[rpedde]

probably process_m3u. WIthout process_m3u, it won’t scan playlists (including itunes xml)

— Ron

[zemanel]

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

[rpedde]

The problem is that when you copy the files from one file system to another, the file names change. One file system might accept unicode of utf-8 filename, and the other might not, so it might convert it to codepage, or mangle the filenames in some way.

Unfortunately, the iTunes xml file doesn’t get mangled… it still has the “old” file names, so it can’t match up the “old” path to the “new” path.

That’s the root of the problem.

Really, the thing is that I don’t have a fix for it, really. Not for the ones with international characters. Clearly something isn’t right on the latest build, with not being able to find the files from the .xml file, but I’d have to have more details to be able to replicate that.

What kind of system was it coming from? What was the location of the .xml file, and where where the music files? What kind of file system was it on? When you moved it to your linux box, where did you put the music files? Where did you put the .xml file? And what type of file system is the destination system?

[zemanel]

iTunes (6.0.4) is installed in WinXP, the WAV files were all ripped and “deposited” into the hdd while it was connected to the WinXP machine via USB.
Then I unplugged the hdd and connected it to the NSLU2 (Unslung 6.8).

Now for iTunes to be able to find the files, I told it where they were located. To this end, simply told it that the files were no longer in M:/Music (the drive had the letter M when attached to the PC) but rather N:/Music (N: was the letter that I mapped the networked drive to). Then iTunes found all the files again and updated its XML and playlist files (actually, it only updates it after closing down iTunes).

Finally, copied and pasted the XML and playlist files (they were in the My Documents/My Music/iTunes folder) to N:/Music

So, to answer your questions:

rpedde wrote:

What kind of system was it coming from?

WinXP SP2 (UK English). iTunes in C:/Program Files/iTunes and music files in M:/Music/

rpedde wrote:

What was the location of the .xml file

C:/Documents and Settings/Username/My Documents/My Music/iTunes

this is the default location for iTunes’ XML and playlist files

rpedde wrote:

…and where where the music files?

The music files were initially located in M:/Music/

rpedde wrote:

What kind of file system was it on?

NTFS

rpedde wrote:

When you moved it to your linux box, where did you put the music files?

Simply moved the hdd to the Slug, where it is recognized as HDD_1_1_1 (which as you know simply means it’s the first -and only- partition of disk 1 plugged to port 1)

So, they stayed in the same hdd, but their path changed.

rpedde wrote:

Where did you put the .xml file?

From the Slug’s perspective: inside /share/hdd/data/HDD_1_1_1/Music/

From Windows perspective //Lanstorage/HDD_1_1_1/Music/
or the mapped drive N, i.e. N:/Music/

rpedde wrote:

And what type of file system is the
destination system?

Still NTFS, since it’s the same drive. The only real difference is that the NSLU2 firmware only seems to recognize/handle files whose name don’t contain “~”, such as “ã”, or “õ”.

[velociped]

Two of your statements are at odds with one another.

rpedde wrote:
What was the location of the .xml file

C:/Documents and Settings/Username/My Documents/My Music/iTunes

this is the default location for iTunes’ XML and playlist files

and

rpedde wrote:
Where did you put the .xml file?

From the Slug’s perspective: inside /share/hdd/data/HDD_1_1_1/Music/

From Windows perspective //Lanstorage/HDD_1_1_1/Music/
or the mapped drive N, i.e. N:/Music/

I think this is the root of your problem with respect to the playlist issue. The location of the iTunes .XML file may be in /share/hdd/data/HDD_1_1_1/Music/ from the SLUg’s perspective, but, as far as mt-daapd understands, the files to which the .XML points are all located on a mounted drive — not in a subordinate directory.

The paths in the iTunes .XML file are relative to its location with respect to the the actual music files. If the library directory is located on a mounted drive when generated and the .XML file later moved to a location in the direct path of the music, then it will lose track of the files’ location.

-Herman

[zemanel]

well, yes and no…
forgot to mention that I told iTunes to “consolidate” the library.

Also since first writing my post mt-daapd has also found the Playlists (it took a few hours). So my point is that everything works fine with the nightly I’m using (01 March), but the exact same configuration doesn’t seem to work with the latest build.

cheers

[ZeManel]

In order to solve the problem I need two pieces of information:

First, bear in mind that the XML file (as produced by iTunes in Windows) is in the same folder “Music” as all the WAV files.

For instance, the XML entry for Massive Attack’s “Better Things” is:

Locationfile://localhost/F:/Music/Massive%20Attack/The%20Best%20Of%20Everything%20But%20The%20Girl/14%20Better%20Things%20(Massive%20Atack%20With.wav

In this notation, the XML file would be located here:

//localhost/F:/Music/iTunes%20Music%20Library.XML

Now for the questions:

1- how do I change the above paths so that the latest mt-daapd builds can find the metadata for my files. I.e. what should I replace “…file://localhost/F:/Music/…” with?

2- Exactly how do I force mt-daapd to process this info.
Should I just replace

#process_m3u 0

in the config file with

process_m3u = 1

(removing the # and placing =1 instead of 0)

Any help would be greatly appreciated.

Cheers

[rpedde]

Actually, I’ve been working on that the last day or so. I’m trying to make sure that you can read windows xml files from unix and vice versa.

I think it should be better behaved now. If you can check out the subversion version, it might be worthwhile, otherwise, I’ll make another nightly probably tomorrow.

— Ron

[zemanel]

thanks for your reply.
By subversion, do you mean the iTunes version? If yes, then it’s 6.0.3, as for mt-daapd it’s the latest svn-1018.

Also, while you’re at it, do you think it’s possible for you to find a way to make mt-daapd read international characters?

For instance, because of the funny dots on the “o” in “Björk”, previous versions of mt-daapd weren’t able to process it’s info/songs (these older versions of mt-daapd however were able to locate all the files and retrieve XML info, except for files and folders with special/international characters). Other examples are: “Sinéad O’Connor” – special “é”, etc.

Here’s the complete list of special latin chars:

ã,â,á,à,ê,é,í,õ,ô,ó,ú,ç

And of course their uppercase counterparts
Ã,Â,Á,À,Ê,É,Í,Õ,Ô,Ó,Ú,Ç

If you want, I can give you examples of how each of these characters appear in the XML file.

[Author]

Posts