Loading Firefly in iTunes takes a while is my setup correct?

[Anonymous]

I’m not complaining at all, I just want to make sure everything is set up correctly. My database file is 25MB (37000 songs). When I load up Firefly in iTunes it takes 50 seconds to load over an 802.11G connection. I even enabled gzip in the conf. Is this normal? 25MB should take 10-12 seconds to transfer. Is there any way to make it faster?

[Anonymous]

My firefly is running on a dns 323. While I can access the server instantly on my soundbridge it takes some minutes for Itunes to access the server.

[EVILRipper]

iTunes uses the DAAP protocol to list the songs.
The DAAP protocol assembles a ‘file’ to send. The first 8 bytes mention the size of the file being sent. This means the file has to be complete.
f.e.
When listing for songtitle and artist, the file is assembled. When done, the size is known, and the file can be sent. So it first has to index all music before being able to start sending the file to list all songs using DAAP.

The soundbridge uses the RSP (Roku Server(?) Protocol) protocol. This is a new protocol implemented from around 1400, where the file to list all songs does not need to know the size. So as soon as a listing is requested, the first indexed songs are sent, while in the background, the rest of the songs are being indexed.

In short:
DAAP has to index all files, then send the list.
RSP can index and send the list at the same time, being more faster as the database gets bigger.

Hope this clarifies the situation. 🙂

[Anonymous]

Thanks for explaining how the list gets transferred. I wish there was a way for iTunes to cache the list, and have it manually update when you ask it to, but I guess thats too much to ask.

Anyway, so do you think that my situation is within normal time range ?

[stretch]

If all your doing is playing music then try the Java Firefly client in the 3rd party software section.
It stores a copy of the db on your local hard drive and only downloads a new copy when the db is updated.

It can also create playlists.

[grommet]

Actually, you can do the same exact thing with DAAP as you can with RSP. The difference is the client, and not the protocol. SoundBridge doesn’t load a full index via either protocol. (RSP is, however, more efficient.)

The problem is iTunes as a client is not “search based” like the Roku SoundBridge… and it wasn’t really designed to scale up.

[Anonymous]

@EVILRipper wrote:

In short:
DAAP has to index all files, then send the list.

I hope I’m not asking stupid things, but maybe there is an option to make Firefly cache this list instead of building it every time a client connects?
This list should only be rebuilt when a (re)scan was executed, right?

Please correct me when I’m wrong.

[fizze]

No, since only iTunes is so stupid and requests everyhing at once.
The client firefly was created for (RoKu soundbridges) don’t do that.

The advantage is that if you add make changes to a smart playlist the changes are reflected immediatley, whereas with iTunes you have to disconnect and reconnect.

[EVILRipper]

I’m sorry. I don’t think I’ve been clear.
When firefly “scans”, it indexes all files into a database.

When using the DAAP protocol, you specify the values you want.
You don’t need info like pathname, or extra ID3 comment for every song everytime you request a list using DAAP.
It assembles the requested values into an indexed list from the database.
When the list is done, DAAP sends it over.

Actually the same with RSP. But RSP can create the indexed list in the background and send the ‘so-far-done’ list at the same time.

To get a little more technical, DAAP contains in the first 8 bytes how large the total list size will be. This forces DAAP to index everything first, and then send over the list.

[Anonymous]

@EVILRipper wrote:

It assembles the requested values into an indexed list from the database.
When the list is done, DAAP sends it over.

I guess that creating this list takes some time on slow hardware, even if all the data is coming from the database.
And this is done everytime a client connects to FireFly, right?
Maybe it could be an idea to store the list in a file, so the list can be sent rightaway when a new client connects. I guess this should have an impact on the “connecting …” time, especially in iTunes.

When a file scan is executed and the content of the database changes, this file should be removed (or updated as well).

I fact, I’m talking about a caching layer between the database and the clients.

Could this be a new feature request?

[fizze]

Erm, EvilRipper is right. But this isn’t rather a limitation in the DAAP protocol. Again, since firefly was developed for the soundbridges, this isn’t a problem because they act differently than iTunes.
The problem is that iTunes downloads THE WHOLE DATABASE upon connecting.

You can speed this delay up by removing all the playlists and smart playlists, then you effectively limit it to the Library itself. 😉

[EVILRipper]

@freek wrote:

I fact, I’m talking about a caching layer between the database and the clients.

It’s possible. But that would be way too much work for such a simple task. And it would be an extra process simply for caching firefly’s DAAP requests.
The next problem would be, how to cache different requested values.
DAAP returns assembled lists in the order values get requested.
f.e. a request only asks Title, Artist.
But iTunes requests multiple values, in a different order. This would result in a different list. All these different lists would have to be cached. Not quite efficient as you can imagine.

I can imagine the easiest way to crank up the performance on iTunes is hard-coding in firefly itself. There should be a way firefly can ‘determine’ the client application like iTunes. If this is the case, it can be filtered and sent the pre-cached iTunes DAAP list.

The problem this causes is difficult maintenance. If iTunes requests different values in future updates, the cached list will be wrong. You’d have to cache the different type of lists for each version of iTunes.

So I don’t think it will be do-able to actually cache a DAAP list or crank up the performance in iTunes.

(This performance issue actually made me write DaapPlaylistGenerator from the Add-On Software forum, to put the “cached list” into a .m3u and play using Winamp. :))

[Author]

Posts