Home of the Squeezebox™ & Transporter® network music players.
Page 7 of 7 FirstFirst ... 567
Results 61 to 63 of 63
  1. #61
    Senior Member Michaelwagner's Avatar
    Join Date
    Apr 2005
    Location
    Oakville, Ontario, Canada
    Posts
    2,024
    Quote Originally Posted by dean
    I asked Dan how hard it would be to rewrite the portion of the MP3::Info module in C that accounts for 90% of the time in scanning a given set of MP3 files.
    It's been a while since I looked at that code (about 2 months, I think), but I seem to recall the problem wasn't CPU it was I/O. It seeks about a lot. Not sure if C would help (or help enough) but it might be worth a try.

    A better thing yet to consider is whether it needs to be done ahead of time and stored in the database. Slim is going to read every byte as it dribbles it out to the device ... at which point the bytes will already all be in memory ... isn't that soon enough?

    Michael

  2. #62
    Gadfly, Former Founder Slim Devices dean's Avatar
    Join Date
    Apr 2005
    Location
    San Francisco, CA
    Posts
    4,427

    Re: Slimserver footprint, time and space,and an architectural suggestion

    On Oct 11, 2005, at 3:17 PM, Michaelwagner wrote:
    > dean Wrote:
    >
    >> I asked Dan how hard it would be to rewrite the portion of the
    >> MP3::Info
    >> module in C that accounts for 90% of the time in scanning a given
    >> set of
    >> MP3 files.
    >>

    > It's been a while since I looked at that code (about 2 months, I
    > think), but I seem to recall the problem wasn't CPU it was I/O. It
    > seeks about a lot. Not sure if C would help (or help enough) but it
    > might be worth a try.
    >
    > A better thing yet to consider is whether it needs to be done ahead of
    > time and stored in the database.

    It already is in the form of offset and length, but to get that
    information, we have to parse the MP3 data to find the frames when a
    song is scanned.



  3. #63
    Senior Member Michaelwagner's Avatar
    Join Date
    Apr 2005
    Location
    Oakville, Ontario, Canada
    Posts
    2,024
    I wrote:
    A better thing yet to consider is whether it needs to be done ahead of time and stored in the database.

    Quote Originally Posted by dean
    It already is in the form of offset and length, but to get that information, we have to parse the MP3 data to find the frames when a song is scanned.
    Sorry, Dean. I was doing too many things at once and wrote something that could be interpreted ambiguously.

    So let me try again.

    I am suggesting that we NOT parse the MP3 data at song scan time to find the starting and ending frame, but rather only do that as we are actually playing the song. When playing the song, we already have it in storage. It might be easier and less costly to hunt around in it then.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •