Page 1 of 1

SubDaap V2.0.0

PostPosted: Mon Sep 07, 2015 7:11 am
by basilfx
Hi all,

In this topic, integration of a DAAP server in Subsonic was requested. Since this request was never fulfilled, I started working on an alternative.

Yesterday I released SubDaap v2.0.0, which provides a DAAP server that connects Subsonic with iTunes. Features include full-catalog browsing, playlists and local file caching. I have tested this version under OS X 10.10 and Ubuntu 15.04 in combination with iTunes 12.

The installation instructions can be found in the file. Note that this is a background service and does not provide a graphical interface (except a web interface page). It is designed to run on the same machine as iTunes, so you have offline access to your music. However, it can also run on a remote network server.

At this moment only a few users make use SubDaap, and more testing is needed. Please let me know if you find any bugs.

Re: SubDaap V2.0.0

PostPosted: Thu Oct 15, 2015 12:10 am
by mwgilbert2
Thanks for your program. It took a bit of work on OS X 10.11, notably workarounds for gevent and greenlet (I used alternates to the supplied builds).

So it builds and runs OK, with one exception. I have a large library; ~ 58,000 tracks. The application throws an error:

Traceback (most recent call last):
File "/Library/Python/2.7/site-packages/gevent/", line 175, in _do_read
File "/Library/Python/2.7/site-packages/gevent/", line 114, in do_read
File "/Library/Python/2.7/site-packages/gevent/", line 161, in accept
error: [Errno 24] Too many open files
<WSGIServer at 0x10ae00590 fileno=10 address=> failed with error

This manifests in the iTunes instance that connects to it as a good number of albums that have incomplete metadata and no artwork.

I am happy to test any revisions.

Re: SubDaap V2.0.0

PostPosted: Thu Oct 15, 2015 7:39 am
by basilfx
Thanks for your bug report.

I will take a look at it, and will come back to you when I figured this out.

Re: SubDaap V2.0.0

PostPosted: Tue Nov 10, 2015 7:28 pm
by basilfx
I have tried to replicate the issue, but I think my library is not large enough :-)

Anyway, I have added an option to show and change the open files limit. It is currently available in the development branch for testing, but will be released soon if stable enough.