As you flip through the UI, when you get within 5 results of the end of your data, you send a new query for the next 20 results. You could do this using a sort of ping-pong list scheme, so that if the UI was on track 30 overall, list a would have tracks 1-20, and list b would have tracks 21-40; when you got to track 35, list a would have tracks 41-60, and list b tracks 21-40. Assuming the device can gracefully query in the background (which it should be able to do), this lets you greatly reduce the memory footprint. I dont remember how the query stuff works in rioplay, but it seems like you could just pass off whichever list you aren't browsing to the query engine for it to populate...
Making the lists static/fixed length strings would be way better than using malloc, STL, or any of the other options available here. Chances are the server software has a limit of sorts to start out with, and even if you set up 256 bytes per entry, with 40 entries that is only 10k of fixed memory.
-----Original Message-----
From: []On Behalf Of lee
Sent: Thursday, July 22, 2004 8:49 AM
To: Wim Lewis
Subject: Re: [Rioplay-devel] Rioplay and memory usage

Certainly working with the server is easier than the client.

One theortical way is:
The server watches how long its reply is getting.  Limits it and adds "next and prev links".

The problem is the client which is far from a generic web browser.  >From the Songs/Titles/Artist lists it is easy to send next/prev request - evenit is only sending a dummy "title" or id.  Getting the server to do the right thing is easy.   But how the client handles this 2nd reply is the problem.

Wim Lewis wrote:

> > Out of curiosity, how big is big? Tens of thousands of tracks? Millions?
> Only 820 tracks.

Right, I'd forgotten that the player really doesn't have much RAM (and no
swap :-) ).

I modified rioplay's status webpage to report some memory information
(/proc/meminfo and the results of a mallinfo() call) so that I can watch
it as I run the program. The rioplay process starts out with about 50k of
heap, and the kernel reports ~700k of free memory according to meminfo.

Interestingly the rioplay memory usage goes up by a few pages (4-12 kB)
each time I look at a listing, but this eventually levels off so I
assume it's fragmentation rather than an actual memory leak.

I then modified the perl scripts I use on the server to return a number of
extra entries on each query. At around 600 (total) entries the player's UI
started to get noticeably slow, but it didn't actually crash until after
10,000 entries (it succeeded with 10150 or so, and the next number I tried
was 15150, which reliably causes the rioplay process to spew some malloc
warnings and then exit. It is gracefully restarted by init, though, which
is nice.)

The difference between this number and 871 is probably partly due to the
fact that my extra tracks have pretty short names (10 characters or so).
I'm guessing that the memory use can be accounted for by:
   - a few copies of each track name in different lists here and
     there (the input source, the menu screen...)
   - memory fragmentation
   - malloc overhead

Looking through the code, I notice that it uses a mixture of C-style
char*-and-malloc strings and C++ STL strings. It seems to me that a lot of
memory could be saved by using immutable STL strings throughout, since
copies of strings can share their storage behind-the-scenes, but only if
they don't go through a char* stage in between. Changing some of the
vectors and arrays to lists or ropes (also available in the g++ STL) ought
to reduce the heap fragmentation a bit, as well. I'll give this a try the
next time I have a few days to tinker with it.

Dan Conti writes:
> Personally i use[d] a perl package called mserve for serving content. It
> should be easy to modify this to support query ranges, such that you do:

I'm also using a perl script loosely based on Jeff Mock's perl server
script and I've noticed it already has the beginning of support for begin=
and end= parameters on queries. Do you know if this is in there to support
the original player software, or if it's an unfinished experimental

Of course, since at this point both the client and the server are
open-source and under my control, there's no real reason I can't add
another InputSource subclass and move to a different protocol entirely. I
wonder if there's an existing protocol that would fit the bill, maybe
Apple's (officially-undocumented) DAAP protocol?

> Makes me wish i had more time to work on such things. Best of luck with your
> projects :)

Yes, I'm hoping I'll actually get this to an interesting point before
getting distracted by the rest of my life again :-)


This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
Rioplay-devel mailing list