• 1. You need a kernel compiled with Multicast support. Either roll your own or grap this one from me which includes hijack, multicast, and ext3 support.
  
• 2. Reserve some memory for mt-daapd by adding a ReserveCache line to the appropriate spot in your config.ini. A value of 40 seems to work well enough for my empeg with 62 gigs of music running v3a11 (I made some changes to mt-daapd to cut down a lot on it's memory requirements so it shouldn't require a memory upgraded player). If you don't give it enough memory your empeg will probably still show up under iTunes, but when you click on it you will never get a list of mp3s.
  
• 3. While you're in config.ini you might want to add a menuexec line as well, something like:
  Code:

  ---

  ;@AC ;@MENUEXEC daapd exec /drive0/bin/mt-daapd/mt-daapd -c /drive0/bin/mt-daapd/mt-daapd.conf
  
  

  ---

  
  
• 4. Grab this tar file and copy it to your player.
  
• 5. Extract it like so
  Code:

  ---

  tar -xf empeg-daapd.tar /

  ---

  
  This will extract to /drive0/bin/mt-daapd
  
• 6. mt-daapd needs to build a database of your mp3s, this takes a long time the first time so don't do it with the player software running. Run
  Code:

  ---

  /drive0/bin/mt-daapd/mt-daapd -c /drive0/bin/mt-daapd/mt-daapd.conf

  ---

  
  After the first time it just updates the existing database so it is much faster.
  
• 7. This will run in the background and you'll know it is done when "empeg" pops up under iTunes as a shared drive.
  

• 1. This will remount your /drive0 as read/write automatically for a few minutes every time you start it. It has to in order to update it's database. On my empeg with 62 gigs of music this takes about 5 minutes with the player running. Do not unplug your empeg until it shows up under iTunes or you risk file system corruption and will have to do an fsck the next time you want to load music. It will go back to read only when it is complete.
  
• 2. I'm not sure if this works on players that haven't been fid sifted. I don't have one here to try.
  
• 3. I'm not sure what will happen if this hits an audio file that isn't an mp3. I think it will skip it and if it doesn't it is unlikely iTunes will play it.
  
• 4. The empeg is slow when the player is running. Don't be surprised if it takes a few minutes for tracks to show up in iTunes after you click on the shared playlist.
  
• 5. This keeps it's database which is on /drive0 open at all times so you won't be able to sync with it running. I may fix this at some point.
  
• 6. Don't futz with the location of the files, just leave everything where it is as some of the paths are hardcoded.
  

Quote:
Caveats

• 1. This will remount your /drive0 as read/write automatically for a few minutes every time you start it. It has to in order to update it's database. On my empeg with 62 gigs of music this takes about 5 minutes with the player running. Do not unplug your empeg until it shows up under iTunes or you risk file system corruption and will have to do an fsck the next time you want to load music. It will go back to read only when it is complete.

Quote:
Wow.

Wow, wow, wow.

How much to do the same for the Rio Central?

How much does a Central cost?

Quote:
It would be really cool if mt-daapd had a --readonly flag which would not scan for new files and not update any data on the harddrive, just take its database as gospel.

Quote:
How much to do the same for the Rio Central?

Quote:
#1 on the to do list, and actually I can do it without the --readonly flag. All I need to do is see if the empeg's database has a newer modification time then daapd's.

Now that just makes sense, nice one

Quote:
The first question would be if the central has multicast support enabled in it's kernel and if not has anybody figured out how to get a replacement kernel on it?

Quote:
From what I can tell, it is not possible to delete files.

Yeah, what he said. iTunes won't let you make changes to a remote share even if the empeg would. It doesn't give you the ability to delete, edit, or even download files, just stream them. Of course when Paul feeds daapd 200 Gigs of mp3s I'm not sure it will work anyway

-Mike

#!/bin/sh
(/bin/sleep 30; /drive0/bin/mt-daapd/mt-daapd -c /drive0/bin/mt-daapd/mt-daapd.conf) &

;@AC ;@EXEC_ONCE /drive0/bin/mt-daapd.sh
;@AC ;@MENUEXEC Kill_dappd kill -9 `cat /drive0/bin/mt-daapd/mt-daapd.pid`

Quote:
And Hijack wise, I added an option to kill the server.

Quote:
Code:

---

;@AC ;@MENUEXEC Kill_dappd kill -9 `cat /drive0/bin/mt-daapd/mt-daapd.pid`

---

Quote:
There's a serious application problem if you need to kill -9 / SIGKILL it instead of the default kill -15 / SIGTERM.

Quote:
And that is actually working?

Quote:
In my testing a regular SIGTERM would terminate that thread, but neither SIGTERM or SIGKILL would kill all threads belonging to md-daapd. That is probably a bug, not sure if it is one I introduced or if it was already there. Never had a chance to look into it farther, but that is why I mentioned it to Drakino.

-Mike

Quote:
Well, if you didn't give it a SIGKILL (that is, signal 9), it might have the opportunity to do that.

Quote:

Quote:
Well, if you didn't give it a SIGKILL (that is, signal 9), it might have the opportunity to do that.

I forgot to confirm I was seeing the same issues as Mike was. Anything other then a SIGKILL doesn't work, at least not from the hijack menu. I haven't sat down to see exactly why, as to me, this doesn't bother me. Sure, the empeg is a Linux running box, but I see it more as an appliance. As long as the empeg recovers properly from this, and does what I expect when I say stop the process, I'm happy. And thus far doing a SIGKILL is not showing any problems.

Quote:
Are the timestamps accurate? Weren't there a lot of people for whom the clock was not?

Quote:
Yeah, but I thought I remembered people's clocks resetting, and, if that's the case, they wouldn't be accurate relative to each other. I could be completely making stuff up, though.

Quote:
Yeah, but I thought I remembered people's clocks resetting...