You can look into your [install-dir]/logs directory and you'll notice the _access.log and _error.log files. They should contain play and stop events along with any corresponding errors that occur with disk i/o issues and/or derivatives thereof. Many times the error received will be based on the context and workflow involved.
I don't have anything specific, but the place to start with logging and accounting is the /conf/log4j.properties file, where you can modify or create new logging Appenders. A simple approach is to make sure you collect the data you need to look back case by case. A log row with x-event "destroy" for a c-client-id has cumulative totals: sc-bytes (server to client bytes, for playback clients), cs-bytes (client to server bytes, for publishing clients) and x-duration. It looks like you already have a way of
associating users with client-id.
I was just wanting to post almost an identical thread, instead I will bump this one for David :) I operate a subscription based service and need to be able to identify users that have legitimate streaming issues. Like David, it would be awesome to know what the reason is, but more important is to at least see that they do have trouble so we can offer them subscription extensions or refunds depending on how bad it is. I would rather not just take their word for it, but have actual data guidelines we can go off of.
I have an administrative page that ties in our users info with the log file like below. Ideally, I would like to see a single line from a user that starts a stream and completes the stream without issues, but see more data when user is having trouble buffering, switching servers and such. Is there a way to reconfigure the log engine to do that, or parse the data looking for something specific so I can combine all the non-issues?