- This topic has 11 replies, 7 voices, and was last updated 16 years, 1 month ago by
.
-
Posts
-
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?
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.
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. 🙂
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 ?
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.
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.
@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.
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.
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.
@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?
- The forum ‘General Discussion’ is closed to new topics and replies.