# of scannable songs limit?

  • Post date

FireFly Media Server › Firefly Media Server Forums › Firefly Media Server › Setup Issues › # of scannable songs limit?

Viewing 6 posts - 1 through 6 (of 6 total)
  • Author
    Posts
  • 19/09/2006 at 4:24 AM #602
    unix_fan
    Guest

    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? 🙁

    19/09/2006 at 4:29 AM #6482
    unix_fan
    Guest

    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

    20/09/2006 at 1:42 AM #6483
    rpedde
    Participant

    @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

    20/09/2006 at 4:44 AM #6484
    unix_fan
    Guest

    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).

    20/09/2006 at 6:37 AM #6485
    fizze
    Participant

    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.

    20/09/2006 at 11:29 PM #6486
    rpedde
    Participant

    @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
Viewing 6 posts - 1 through 6 (of 6 total)
  • The forum ‘Setup Issues’ is closed to new topics and replies.