> Two down, alot of segfaults to go....
> I have seen a number of additional segfaults, but I have not been able
> to reliably reproduce one yet, so I am temporarily stalled (that and I
> had no free time this last weekend). Mostly I am mucking about in the
> music browser when freeamp dies. Is there any clear documentation
> anywhere about what is running in what thread? Just a paragraph or so
> of explanation would do. If one of the segfaults comes from
> dereference a NULL, then I may just have to add strict checking of
> pointers in each function to catch it in the act. By the way, are we
> all creating different debugging macros to help trace the code? If
> so, couldn't we just check in a version with macros for the strict
> pointer checks (setup to compile to nothing by default) ? Also, I did
> not notice any standard for handling errors/exceptions. Is there any?
The primary standard WRT errors has appeared to be to hide them is non
fatal, and to pass them as response codes in other cases. I believe there is
an enum in there somewhere with most of the error codes define. Also, in
terms of debugging macros, etc, I tend to just drop some asserts around any
functions which I'm trying to fix things up. Additionally, there is the
always useful printf ;)
> Enough talk, tomorrow I'll hammer on freeamp till I get a lead on one
> of these crashes.
> When I have more than a few songs loaded in the music browser or the
> playlist, I want to be able to say "Find all the songs matching foo"
> as a quick navigation system. I actually wrote a simple helper
> application that does this with xmms. ( see xmms-gtk-playlist at
> http://web.mit.edu/chrisk/www/index.html ). Is there any plan to add
> a search feature? If not, then I could design and implement it.
As always, any coding of useful features will be happily accepted ;). I
don't believe such a feature was planned in the immediate future, so you
won't be replicating anyone elses work with that.
> I noticed the memory footprint was about 27MB (which includes shared
> libs). The footprint of xmms with the same playlist was about
> 8MB. These are rough numbers, but the difference is large enough to
> prompt me to ask on the mailing list. Any comments on how possible or
> desirable a smaller size would be?
Yep, freeamp as a whole is a lot more bloated than say, winamp or XMMS. The
primary size difference comes from the musicbrowser, because it loads all
the metadata entries at startup, so has a memory footprint proportional to
the number of tracks in your collection. Additionally, there are a bit too
many internal copies which go on, which are part of the general musicbrowser
issue ;). In essence, updating this system is one of the top priorities for
the next FreeAmp rev (outside of the 2.1 beta series) since it requires a
fairly significant rewrite to the entire musiccatalog and browser code. In
the interim, just consider the fact that freeamp will load all the metadata
for a playlist faster than XMMS, and can recommend playlists for ya, so you
get something extra for the memory usage ;)
-Sean
As always, Rob or Isaac please correct me if I'm in error, especially about
error handling ;)
_______________________________________________
[EMAIL PROTECTED]
http://www.freeamp.org/mailman/listinfo/freeamp-dev
