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