Dean,

I'll try to make one. Unfortunately I fixed all the
tags before I thought to save one off for future
debugging.

When I get home from the holidays I am pretty sure I
know how to reproduce the faulty tag though.

Happy holidays,
Victor
--- dean blackketter <dean (AT) slimdevices (DOT) com> wrote:
> Good find, Victor.
>
> The MP3::Info had been updated to handle some
> obscure ID3 options that
> some folks had found.
>
> Can you pick one MP3 file that exhibits this problem
> and send it to me?
>
> -dean
>
> On Nov 26, 2003, at 7:27 AM, Victor Brilon wrote:
>
> > Dean,
> > More analysis on this, and I *think* I have the
> problem solved.
> >
> > Obviously what's happening is that perl itself is
> running out of
> > memory for some reason, not the system itself. I
> am guessing this is
> > caused by reading in some weird data structure
> that unexpectedly takes
> > up too much memory.
> >
> > I wrote some code to go through all my mp3s
> looking for any tags that
> > didn't look right since I suspected they're the
> culprit. Sure enough,
> > I have one album where it looks like the ID3 tags
> got written as UTF-8
> > encoded. Interestingly enough, MP3::Info could not
> read them properly,
> > but in Windows they're seen ok.
> >
> > I moved that one album out of my hierarchy and the
> server completed
> > its scan just fine. Memory still grew (as to be
> expected) but it
> > stabilized at ~30 MBs and seems to be running just
> fine.
> >
> > Any idea why this is so with v5 and not with v4?
> >
> > Victor
> >
> > Victor Brilon wrote:
> >> Dean,
> >> This is a little tough to do since I don't have a
> whole lot of free
> >> disk space to copy mp3s to for testing
> unfortunately.
> >> I was able to free up about 13 gigs and point the
> server at that. It
> >> scanned the entire thing just fine and the memory
> usage, while
> >> increasing during the scan, never got above 20
> MBs or so.
> >> Was there anything in the log I posted that
> looked unusual to you
> >> that would be a lead for debugging? I am just not
> familiar enough
> >> w/the changes between v4 and v5 of the server to
> know what would
> >> cause it to break this way.
> >> Victor
> >> dean blackketter wrote:
> >>> Ok, so add in your music in batches until you
> find what breaks it.
> >>>
> >>> On Nov 25, 2003, at 7:31 PM, Victor Brilon
> wrote:
> >>>
> >>>> Then everything works great and the server
> stabilizes at using just
> >>>> under 20MB of RAM.
> >>>>
> >>>> dean blackketter wrote:
> >>>>
> >>>>> Can you make a small library of one album and
> just scan that and
> >>>>> see what happens?
> >>>>> -dean
> >>>>> On Nov 25, 2003, at 7:52 AM, Victor Brilon
> wrote:
> >>>>>
> >>>>>> No web connection, no player running, and the
> scan never finishes
> >>>>>> since it runs out of memory.
> >>>>>>
> >>>>>> Victor
> >>>>>>
> >>>>>> dean blackketter wrote:
> >>>>>>
> >>>>>>> Does the memory keep growing if there is no
> player connected, no
> >>>>>>> web connected and the scan has completed?
> >>>>>>> -dean
> >>>>>>> On Nov 24, 2003, at 9:02 PM, Victor Brilon
> wrote:
> >>>>>>>
> >>>>>>>> Yes, same prefs file,
> >>>>>>>> No, no recursive links.
> >>>>>>>>
> >>>>>>>> See my next email about the misread on the
> command line
> >>>>>>>> difference
> >>>>>>>>
> >>>>>>>> dean blackketter wrote:
> >>>>>>>>
> >>>>>>>> > Are they both using the same prefs file?
> >>>>>>>> >
> >>>>>>>> > Might you have a music folder that's got
> a recursive link in
> >>>>>>>> it or something?
> >>>>>>>> >
> >>>>>>>> >
> >>>>>>>> > On Nov 24, 2003, at 8:42 PM, Victor
> Brilon wrote:
> >>>>>>>> >
> >>>>>>>> >> This got interesting real quick....
> >>>>>>>> >>
> >>>>>>>> >> If I run the server from the command
> line, i.e.,
> >>>>>>>> >> /usr/local/slimserver/slimserver
> --d_info
> >>>>>>>> >>
> >>>>>>>> >> then the memory doesn't grow at all. It
> stays right around
> >>>>>>>> 19MB or so and fluctuates very little while
> the file scan is
> >>>>>>>> going on.
> >>>>>>>> >>
> >>>>>>>> >> If I start the service via the rc
> script, then immediately I
> >>>>>>>> can see the memory grow to over 26MB within
> a minute or two and
> >>>>>>>> just progress from there. While this was
> going on, I went in
> >>>>>>>> the web interface and turned on d_info on
> the debug screen.
> >>>>>>>> >>
> >>>>>>>> >> Looking at the output log, I can't see
> anything going wrong.
> >>>>>>>> I uploaded the entire thing for you to look
> at if you'd like.
> >>>>>>>> It's about 13MBs uncompressed, and about
> 500K compressed. You
> >>>>>>>> can find it at
> http://victorland.com/slimserver.log.gz
> >>>>>>>> >>
> >>>>>>>> >> Any suggestions on what else to try and
> why the daemonized
> >>>>>>>> version is different from the command line
> version? I haven't
> >>>>>>>> changed any of the options in
> /etc/sysconfig/slimserver, and
> >>>>>>>> that seems to be the only thing that the rc
> script version
> >>>>>>>> looks at, that the command line doesn't.
> >>>>>>>> >>
> >>>>>>>> >> Victor
> >>>>>>>> >>
> >>>>>>>> >> dean blackketter wrote:
> >>>>>>>> >>
> >>>>>>>> >>> Try starting it from the command line
> and turn on --d_info
> >>>>>>>> >>> Have your SLIMP3 unplugged and don't
> use the web interface,
> >>>>>>>> just to keep it simple.
> >>>>>>>> >>> It will spew out a lot of debug
> information, but if it's
> >>>>>>>> really growing infinitely, we'll see what's
> going on
> >>>>>>>> eventually.
> >>>>>>>> >>> -dean
> >>>>>>>> >>> On Nov 24, 2003, at 7:02 PM, Victor
> Brilon wrote:
> >>>>>>>> >>>
> >>>>>>>> >>>> Sorry...meant to include that in the
> last email but got
> >>>>>>>> too happy with the send button.
> >>>>>>>> >>>>
> >>>>>>>> >>>> System is a Linux box with RH9.
> >>>>>>>> >>>> /proc/cpuinfo shows this is:
> >>>>>>>> >>>> model name : AMD-K7(tm) Processor
> >>>>>>>> >>>> cpu MHz : 548.952
> >>>>>>>> >>>>
> >>>>>>>> >>>> Running 'free' shows:
> >>>>>>>> >>>> total used
> free shared
> >>>>>>>> buffers cached
> >>>>>>>> >>>> Mem: 255284 214328
> 40956 0
> >>>>>>>> 13488 107136
> >>>>>>>> >>>> -/+ buffers/cache: 93704
> 161580
> >>>>>>>> >>>> Swap: 525120 95044
> 430076
> >>>>>>>> >>>>
> >>>>>>>> >>>>
>
=== message truncated ===