more likely a cpu overuse from mmm and slimserver running at the same time.  mmm
slimply uses the cli to tell slimserver what to play.  there is effectively NO
difference between that and the remote telling slimserver what to play, or even
the web UI.

are these mp3 files, or transcoded files?

Kdf,
These are all FLAC file. As ar as I know no transcoding is occuring... FLAC is
set to <built in>

Additional note:
Sending files one at a time from the MMM ap works perfectly (double clicking on
a song). This used to cause MMM to stop responding in 1.1.5, apperently fixed in
1.1.6. The issue described above (halting and stuttering first track) only
occurs when a playlist of 10-30 tracks is sent to Slimserver. Still haven't had
a chance to check out CPU usage... will try to do so this eve.

Note: I'm running a 2.5Ghz Intel P4 with hyperthreading enabled and a Gig of RAM.

kdf: could it be that mmm is somehow blocking the process via the cli?

I suppose its possible.  MMM could be using the HTML CLI, which would be
problematic.  I know they used to, and I had suggested using the direct CLI on
port 9090.  Wendell said he'd investigate. maybe they haven't changed over yet.

Okay tried it again this eve. While the halting/stuttering was occuring slim.exe
CPU usage =did= spike up to 40% usage, and jumped around (from 10% to 40%) for
awhile (20-30 seconds or so) before  settling down to a stable (and stutter
free) 1%-3% usage. MMM usage was consistently 1-2% usage throughout. Memory
usage for Slim.exe stayed at 60,336k and MMM at 894k throughout.

if you want to find out really what is going on, I suggest turning on d_command,
d_source, d_musicmagic, d_remotestream

and what happens if you play the same tracks using the remote control, or the
web UI for slimserver?

Created attachment 863 [details]
log file

No problem when played from web or player UI once the playlist is loaded.

Tested on my setup, 1.4G P4 512MRam, MMM 1.1.6 and Softsqueeze.  I'm not seeing
any stuttering with plain mp3 fies, nor the few flac that I have on hand.
Softsqueeze has been reported as suffering from stuttering on its own, and does
so on web refreshes. Is the stuttering occurring on the hardware players, or in
time wiht web activity?

What is clear is that MMM is stull using the HTTP command access, via status.xml.

I have not tested for stuttering in SoftSqueeze... only with my hardware player
(sb2).

Just noticed something which may be critical. The peroid of stuttering equals
the time it takes for Slimserver to "load" the playlist sent to it from MMM...
as soon as all songs are loaded in the play queue... the tuutering stops (as
well as the Slim.exe CPU spike.)

The method that MMM uses to send commands to slimserver (status.xml) is not the
most efficient option as far as controlling slimserver.  Since each song is
added with a command through status.xml, a long list will flood the server with
requests.  I'm not sure if MMM is pacing the commands or just bursting.  A long
playlist could effectively be a DOS

So, is the general consensus that the halting and stuttering is due to the
inefficient method by which the MMM app sends playlists to Slimserver via status
.xml? Is there a solution or recommended alternative method? Has this info been
communicated to Whicken?

1. One theory from one person does not a general consensus make.
2. I suggested the CLI to whicken before 1.1.5, and he said that he'd look into it.
3. even the http method might not be so bad if it was a shorter playlist.  feel free to test and report.

What is odd (in my "ignorant of the inner workings" perspective) is that the
same exact playlist (say 30 tracks in size) will load and play without a hitch
when geberated within the Player UI and Web UI... but the same playlist
generated directly from MMM and sent to Slimserver (by pressing the "play
button" in the app) will cause slim.exe CPU use to spike and playback to
halt/stutter as the playlist =slowly= loads over.  

This is not odd at all, since player and web UI issue a single play command.  MMM 'Get's status.xml 
once for each song.  This is the equivalent to reloading the 'now playing' section of the web ui several 
times in quick sucession.  The theory was a good one, as far as playing the first song quickly and 
loading eacf of the rest.  I dont know if the web server can be made light enough to handle this, or if 
that is even worth trying given the plan to move to apache.  I will re-iterate to Whicken re using the CLI.

I have emailled whicken, suggesting CLI, and also scheduling the playlist load.  Since the first song 
starts playing right away, the other songs don't have to be loaded immediately.  They could be added 
every second or so, letting the web server process each playlist command.

I seem to recall seeing that MMM will have this fixed in their version 1.1.7?

kdf? Update?

from wendell:

Thanks for the info - I made a note of this, although our dev schedule
for 1.1.7 is very tightly compressed right now, so I'm not sure what I
can fit in.  I've got a couple other slim related issues in progress
(a bug with multiple boxes, and the moods addition to the api),
so hopefully those will be able to make it in.

so, I'd call that a maybe.  I responded to this with a suggestion to maybe stagger the timing if they can't 
change the API in time.  at least that will allow time for the audio routines to pipe a bit more music 
through.  short term workaround, shorter playlists.

Ok - Since this is really in their court right now - I'm going to move the bug out of 6.2

Fixed since MMM 1.5+

This bug appears to have been fixed in the latest release!

If you are still experiencing this problem, feel free to reopen the bug with your new comments and we'll have another look.

Make sure to include the version number of the software you are seeing the error with.