# of scannable songs limit?

[unix_fan]

Let
share=/share/hdd/data

I’m trying to stream my existing Networked iTunes Music folder.
The structure is
${share}/itunes/iTunes Music///

If I have
mp3_dir /share/hdd/data/iTunes/iTunes Music/
in the config, the scan seg faults at startup. javascript:emoticon(‘:(‘)
Sad

If I narrow down to :
/share/hdd/data/iTunes/iTunes Music/
then it works just fine.

It doesn’t matter if I have more than one Album and then mp3s under that. So there seems to be a “# of songs” limit that I couldn’t find in the documentation.

Any clue how to either change the max # of songs (I’m willing to edit a binary or compile everything) or is this a reason to fire up a nightly? 🙁

[unix_fan]

It must be late.

I forgot to add that this is on an uNSLUng NSLU2

ipkg status mt-daapd | grep Version
Version: 0.2.4-1

ipkg status libid3tag | grep Version
Version: 0.15.1b-1

ipkg status gdbm | grep Version
Version: 1.8.3-2

[rpedde]

@unix_fan wrote:

It must be late.

I forgot to add that this is on an uNSLUng NSLU2

ipkg status mt-daapd | grep Version
Version: 0.2.4-1

ipkg status libid3tag | grep Version
Version: 0.15.1b-1

ipkg status gdbm | grep Version
Version: 1.8.3-2

Probably not a max # of files thing, probably a file scanning badly. You can configure a logfile in the config, and start it with a -d5. that will tell you every song it scans before it scans it. Then you can see what file is crashing it.

If it really is a number of files thing (probably won’t see it unless you are over 20K songs or so), then nightlies could help, but I don’t think that’s the case.

— Ron

[unix_fan]

I woke up at 3am and debugged this. With a loose binary search, I narrowed it down to one song that is the source of the problem:
Uncle Salty by Aerosmith (from Toys in the Attic)

Nothing unusual about this song file (I’m listening to it as I type) especially relative to it’s brethren:
MPEG, 192 kbps, 44.1 kHz, -5.3db volume, MPEG Layer 3, ID3 tag v2.3

Would debug -d9 give us anything useful beyond the name of the file? I’ll be happy to do whatever it takes to debug if it helps advance mt-daapd.

I can also suggest some changes to the documentation (e.g., spaces in mp3_dir directory path elements are OK).

[fizze]

weird.
a couple of suggestions:

slug doesnt run out of memory ?
slug das sufficient db space ?
mt-daapd’s DB has been erased and fully rebuilt from scratch ?
mt-daapd’s nightlies might work better (different DB backend)

mp3s normally work fine. big vorbis files (nudge nudge, ron ;)) can cause trouble, though.

[rpedde]

@unix_fan wrote:

Nothing unusual about this song file (I’m listening to it as I type) especially relative to it’s brethren:
MPEG, 192 kbps, 44.1 kHz, -5.3db volume, MPEG Layer 3, ID3 tag v2.3

Would debug -d9 give us anything useful beyond the name of the file? I’ll be happy to do whatever it takes to debug if it helps advance mt-daapd.

Almost certainly a libid3tag thing… can you email it to me at [email protected]?

I wouldn’t mind throwing it at libid3tag without the rest of mt-daapd to see what it does.

— Ron

[Author]

Posts