Play counts

How do play counts work? Is it counted as soon as someone hits play? I know spotify does not count a play unless it's been played for 30 seconds. The idea is that someone trying to boost their play count is going to be constrained by having to listen at least 30 seconds for it to get counted. Is there a way to configure the amount of time something needs to play before it gets counted?

The idea is to:
Avoid counting fraudulent plays (someone hitting play a bunch of times on same song)
Avoid counting people just jumping around and increasing total play count accross multiple songs.

Not sure if these are use cases you've encountered, but my customers are concerned about how we prevent fraud.
updated by @dannya: 06/30/17 07:11:28PM

I'm pretty sure its as soon as the streaming is started, but if the same user or visitor repeatedly hits the same play button, its only counted once, so for most sites, this isn't an issue.
Hope this helps


--
Paul Asher - JR Developer and System Import Specialist

That actually wouldn't work for a streaming service. It is expected that a user would listen to a song more than once; and the owner of the song is supposed to get paid for every play. You would be short changing the artist.

You can play fast and loose with metrics when they are informational, but when money is involved, you have to be more careful.
updated by @dannya: 03/30/17 12:58:53PM

YouTube does something similar
The way the YouTube algorithm calculates views can never be completely transparent, but here are the most important things we do know for a fact:

YouTube counts a view after a person has watched a video for over 30 seconds.
Your video will freeze at 300 views, so that the algorithm can establish whether the views are real or not.

So in your model, if the song owner is being paid per play, and multiple plays by the same user are counted, what is to stop him from gaming the system?


--
Paul Asher - JR Developer and System Import Specialist

They do. All the time. There's crazy stories around it. Here's a great thread on it.
https://news.ycombinator.com/item?id=11037806
Fraudsters will create bots to inflate play counts and and even create fake songs. This is an inherent problem when you get paid on plays. But nobody buys downloads any more and the world has moved on to streaming where this is the status quo.

I'd like to be able to take incremental steps.
First limit plays to after playing for 30seconds.
Then, some algorithm to identify "out of the ordinary" volume. You can weed out the bots if you have the right analytics. However, JR's analytics may not provide enough data to do so. Thus my question.

If we can log play time, ipaddress, and useragent, we can apply some analytics.

There's a few things going on here that are going to make play counting like this more difficult.

In a web application like JR, when a media file is streamed, what that means is that JR sends the media file to the web server's buffer as fast as it can (usually in under a second). It is then up to the web server to send the media file to the player at the speed the player can accept it. While this is happening the process is busy, and cannot service other requests. So from JR's point of view, the media file has been "played" as soon as it is done dumping it to the buffer. To change it so the media play is only counted after X seconds, means the file has to be read and sent at the data rate that equates to X bytes per second (varies depending on the media) + some small amount to prevent buffering, as well as an initial "boost" amount. After X seconds is up, the process can then "dump" the rest of the media file and move on to the next. What this means is the PHP process is tied up for X seconds (the duration of the "count"), so your infrastructure has to be ready to handle that - i.e. larger or more boxes with more front end processes to handle X simultaneous users streaming at once - each listener will tie up a process for at least 30 seconds (or whatever you set the play length to).

Also - this method would not work with your media being on Amazon S3, since the media is streamed from S3 and not through a JR view function, so it cannot be properly tracked. Your media would have to stream from the box it is served from (or from attached storage). I know you use S3 so this is important to know.

This type of tracking is actually what JR4 did, and it caused issues on larger sites, so with JR5 we went for a much simpler approach. User plays are tracked by user and IP, and only 1 stream per day per user/ip is counted.

Let me know if that helps.


--
Brian Johnson
Founder and Lead Developer - Jamroom
https://www.jamroom.net

I was thinking more of a player side tracking beacon: the same way they you do analytics for other types of events. Basically, as the player plays, it fires off a tracking beacon at given time intervals back to a log server. That beacon sends back the songid, ipaddress, and any other session information. The point is, you're not tracking based on delivery, you're tracking based on playback.

That's client side, so can be gamed - that's not how we would do it.


--
Brian Johnson
Founder and Lead Developer - Jamroom
https://www.jamroom.net