如何跟踪文件下载

Is the play link a link to the actual mp3 file or to some javascript code that pops up a player?

If the latter, you can easily add your own logging code in there to track the number of hits to it.

If the former, you'll need something that can track the web server log itself and make that distinction. My hosting plan comes with webalizer, which does this nicely.

The funny thing is I wrote a php media gallery for all my musics 2 days ago. I had a similar problem. I'm using http://musicplayer.sourceforge.net/ for the player. And the playlist is built via php. All music requests go to a script called xfer.php?file=WHATEVER

$filename = base64_url_decode($_REQUEST['file']);
header("Cache-Control: public");
header('Content-disposition: attachment; filename='.basename($filename));
header("Content-Transfer-Encoding: binary");
header('Content-Length: '. filesize($filename));


//  Put either file counting code here, either a db or static files
//
readfile($filename);  //and spit the user the file


function base64_url_decode($input) {
return base64_decode(strtr($input, '-_,', '+/='));
}

And when you call files use something like:

function base64_url_encode($input) {
return strtr(base64_encode($input), '+/=', '-_,');
}

http://us.php.net/manual/en/function.base64-encode.php

If you are using some JavaScript or a flash player (JW player for example) that requires the actual link of an mp3 file or whatever, you can append the text "&type=.mp3" so the final link becomes something like: "www.example.com/xfer.php?file=34842ffjfjxfh&type=.mp3". That way it looks like it ends with an mp3 extension without affecting the file link.

You could even set up an Apache .htaccess directive that converts *.mp3 requests into the querystring dubayou is working with. It might be an elegant way to keep the direct request and still be able to slipstream log function into the response.

Use your httpd log files. Install http://awstats.sourceforge.net/

Is there a database for your music library? If there is any server code that runs when downloading the mp3 then you can add extra code there to increment the play count. You could also have javascript make a second request to increment the play count, but this could lead to people/robots falsely incrementing counts.

I used to work for an internet-radio site and we used separate tables to track the time every song was played. Our streams were powered by a perl script running icecast, so we triggered a database request every time a new track started playing. Then to compute the play count we would run a query to count how many times a song's id was in the play log.

If your song / binary file was served by apache, you can easily grep the access_log to find out the number of downloads. A simple post-logrotate script can grep the logs and maintain your count statistics in a db. This has the performance advantage by not being in your live request code path. Doing non-critical things like stats offline is a good idea to scale your website to large number of users.

Use bash:

grep mp3 /var/log/httpd/access_log | wc

The problem I had with things like AWStats / reading through web server logs is that large downloads can often be split in data chunks within the logs. This makes reconciling the exact number of downloads quite hard.

I'd suggest the Google Analytics Event Tracking, as this will register once per click on a download link.