You are here: Home » Topic » Another stupid question

Another stupid question

Viewing 15 posts - 1 through 15 (of 16 total)
  • Author
    Posts
  • #238
    Anonymous
    Guest

    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

    #4245
    rpedde
    Participant

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

    — Ron

    #4246
    zemanel
    Guest

    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

    #4247
    rpedde
    Participant

    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?

    #4248
    zemanel
    Guest

    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 “õ”.

    #4249
    velociped
    Participant

    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

    #4250
    zemanel
    Guest

    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

    #4251
    ZeManel
    Guest

    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

    #4252
    rpedde
    Participant

    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

    #4253
    zemanel
    Guest

    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.

    #4254
    rpedde
    Participant

    This is again the same problem. The fact that when you move the files off one file system into another, it might change the names of the files.

    I know, for example, that ntfs stores filenames in utf-16. iTunes xml stores it in utf-8. I’ve been talking with someone else about trying both utf-8 and utf-16 when trying to locate files, and that might solve this specific problem.

    I guess we’ll see next nightly.

    — Ron

    #4255
    zemanel
    Guest

    Thanks for your help.

    On a different subject, it’s very cool that the Roku people picked you and your program up for their Soundbridge. Have you heard anything from the Lynksis people about what I posted in another thread – that they’re rumoured to bundle mt-daapd with their upcoming firmware?
    If they worked with you that would also be great. Probably for you (unless they want slave work) and for the end user, since for instance someone with NSLU2+ROKU Soundbridge (like myself) would be covered at both ends of the music stream.

    cheers

    #4256
    fizze
    Participant

    wow, where did you get that rumor from ?
    certainly not a bad idea.

    anyway, I’d still prefer to run (enter yourfavorite nslu2 *IX here) on my slug, since its just nicer to have all the possibilities.

    #4257
    zemanel
    Guest

    fizze wrote:

    wow, where did you get that rumor from ?

    For example, go here:

    http://www.linksysinfo.org/modules.php?name=Forums&file=viewtopic&t=14537

    and read the 7th post.

    #4258
    fizze
    Participant

    wow, looks cool.

    way to go, ron & mt-daapd 🙂
    B)

Viewing 15 posts - 1 through 15 (of 16 total)
  • The forum ‘Setup Issues’ is closed to new topics and replies.