- This topic has 6 replies, 2 voices, and was last updated 18 years, 6 months ago by
.
-
Posts
-
I’m running Mt-Daapd 0.2.3 on Debian Sarge 2.4.27-2-386
When the number of files exceeds somewhere between 14031 and 14149 mt-daapd no longer works. There are no errors in the log, it shows up fine in iTunes, however when i click on the music share it load a for a second or two and then drops back to my library.
Is there a maximum number of files mt-daapd can handle ?
No, shouldn’t be. The limit would be available memory, I’d think.
Can you run it with -d9, and a log file specified? That would probably shed some light on what’s going on.
You could gzip that and email it to me at ron at pedde.com, and I could give you a better idea what’s up.
I’m having a problem similar to this, it’ll index till a point and mt-daapd dies w/:
2006-02-02 00:14:29: Found music file: foo.mp3
2006-02-02 00:14:29: Codec type: mpeg
2006-02-02 00:14:29: mDNS_Execute
2006-02-02 00:14:29: select(6, 1.899414)
2006-02-02 00:14:30: mDNS_Execute
2006-02-02 00:14:30: Announcing eduardo.local. (Addr) 7
2006-02-02 00:14:30: Announcing 31.0.0.10.in-addr.arpa. (PTR) 7
2006-02-02 00:14:30: SendResponses: Sending 0 Deregistrations, 2 Announcements, 0 Answers, 0 Additionals on 0054B130
2006-02-02 00:14:30: SendResponses: Next in 4096 ticks
2006-02-02 00:14:30: select(6, 0.100585)
2006-02-02 00:14:30: SocketDataReady got a packet from 10.0.0.31 to 224.0.0.251 on interface 10.0.0.31/eth0/2
2006-02-02 00:14:30: Received Response from 10.0.0.31 addressed to 224.0.0.251 on 0054B130 TTL 255 with 0 Questions, 2 Answers, 0 Authorities, 0 Addi
2006-02-02 00:14:30: select(6, 0.100585)
2006-02-02 00:14:30: Processing rendezvous message
2006-02-02 00:14:30: Rendezvous socket closed (daap server crashed?) Aborting.
2006-02-02 00:14:30: AbortingLook like the song foo.mp3. If you make it unreadable, does it work?
If so, email me at ron at pedde.com — I’d like to get that mp3 file.
— Ron
I’ve been planning on setting up large mt-daapd server for awhile now, and the max number of files has been a concern for me as well. Can you elaborate on the memory limitation? Is there a formula or rule of thumb for figuring out how many tracks can be handled by however much memory?
I am looking at about 60,000 songs.
I’ve had the same experience as the original poster. There’s just a file count where things break. I’ve not had any luck overcoming this on several instances that i’ve set up
With 0.2.x, it holds the whole database in memory while it builds the dmap tree. That’s the limit on 0.2.x — the size of the metadata.
With nightlies, it doesn’t hold anything in memory. It might be slow, because it has to do two database traversals to send the database information, but it shouldn’t be memory limited.
I can’t imagine that there are any memory limits on nightlies.
What version were you experiencing problems with?
- The forum ‘General Discussion’ is closed to new topics and replies.