iTunes Library Problems

[duttonst]

First of all, thank you for an excellent product – I’m already very impressed and I haven’t even got it working how I want yet! Also, apologies if this query has been covered before: I have looked, honestly, but I still seem to be missing one or two key bits of information.

All I’m trying to do is set up mt-daapd on a Linkstation and use a Mac to manage my iTunes library and playlists (via an SMB share on the Linkstation). Unfortunately I seem to be having a few problems getting everything in sync the way I want it.

My main issue is this:

– If I use the 0.2.3 stable release, it all runs very nicely and I can get mt-daapd to see all my music files (approx. 5000 of them). However there’s no sign of my iTunes playlists, nor much of the iTunes metadata (e.g. Compilations), despite the fact that it claims to be seeing my Music Library Xml file when I run it with the -d9 option. It’s getting normal (not smart) playlists working that’s most important to me.

– If I use the nightlies build, I see my playlists & data but it’s basically unusable: when I try to browse some categories mt-daapd max’s my Linkstation out for minutes on end and my SoundBridge eventually gives up on it.

I’ve been focusing on getting the 0.2.3 build working and have tried to make the iTunes directory tree look as “standard” as possible using sym-links so that the paths from the Mac look just like the paths locally on the Linkstation.

Question is, am I wasting my time with 0.2.3? Or is it just a case of persevering (e.g. arrange things so that I don’t need to use sym-links)? Should I just wait for a lighter version of the nightly?

Many thanks in advance.

Andy

[velociped]

Addressing your question first, yes, you are wasting your time if trying to get your iTunes generated playlist file to present its content within mt-daapd when using 0.2.3. The current stable release (in this instance defined as 0.2.3) does not have the ability to make use of the iTunes generated XML file. Its support of playlists is limited to mt-daapd.playlist and .m3u files containing explicit path data.

So, 0.2.3 is not an option if you wish to use your iTunes playlists and that should cover your question and your first “main issue”.

I am a little lost on the specifics of your second “main issue”. Do you mean to say that the SoundBridge times out when trying to access/browse the mt-daapd share or that this occurs when making use of a playlist?

If you are referring to a general sluggishness, this is a recognized issue with the most recent nightlies tarballs and itsy packages. The last couple of posts to this thread touch on the issue. My experience has been that library pulls went from a load time of less than a minute to something approximating five minutes. Ron mentioned that he thinks it has something to do with the new playlist stuff and will work on a fix shortly. If you cannot wait, you may consider going back a nightly or two and see if your performance improves.

–Herman

[rpedde]

Yeah, it’s a problem with latest nightly. You can try compiling it with “–enable-nslu2”, and seeing what that gets you — that takes out the newer playlist stuff.

[duttonst]

Many thanks for the advice – I’ll try one of the earlier nightlies and report back.

The problem I was seeing from the soundbridge was that after a couple of successful attempts I lost the ability to browse or play songs. It just gave me error messages whatever I did (can’t remember the exact messages). Meanwhile on the linkstation mt-daapd would go to ~100% cpu for several minutes.

[duttonst]

Looking good. Just tried compiling the nightly with the –enable-nslu2 option and I’m back to 0.2.3-like performance AND I can see my playlists!

Thanks for your help.

[duttonst]

By the way, I’m currently using the 20051101 nightly without the –enable-nslu2 switch and it’s running nicely. I think it’s this switch that forces the binary to look for the config file in /opt/etc/mt-daapd/ instead of /etc/.

[rpedde]

Yeah, the –enable-nslu2 turns on a few nslu2-specific things — trades memory-intensive queries for slower queries that require less memory, default config location, default disableing background scan unless someone is connected to the server (to avoid spinning up the drive), etc.

But with the latest nightly, you should get the anti-hang behavior without –enable-nslu2.

An alternative to making an /opt/etc would be running it with -c /etc/mt-daapd.conf, btw.

— Ron

[Author]

Posts