No the play count is not the same because the songs were added at different times. Thus a different pla count. But the "fuzzy math" analogy is still apropriate. And the question still is valid.
Which song would SAM pick? No offense... at all. ----- Original Message ----- From: "Loran Partigianoni" <[email protected]> To: <[email protected]> Sent: Sunday, January 04, 2009 1:06 PM Subject: Re: [General-discussion] LRP Rotation Question > Michael: > > NOTE: Please don't take any offense from the candor of my remarks! But > like the ad says, "Inquiring minds want to know." > > This has been a source of debate every year since I starting using SAM2 > thru SAM4 (2003 & following). The problem is that Louis received a > "classic education" in the South African school system established by > British colonists whereas the majority of the SAM users were educated in > the much inferior American schools. Hence, "smLRP et al" means the exact > opposite in the minds of those with a classic education versus an American > education. (or at least that's what I've been able to deduce, others may > be better able to explain the matter.) Hhowever, IMHO, there will never > be any agreed upon definition of terms, so it's just easier to accept it > for what it is, and go on. You have the honor of being the first to raise > the question in 2009 by using a well defined or precise scenario that > will not be easily dodged. But, if Louis even bothers to respond, I > predict the answer will not be the one you are anticipating. > > My own question which is a corollary of yours is "why if all variables > were equal from the start did Song A play 46 times and Song E only play 5 > times? Is this an example of "fuzzy math" that's been taught to kids in > schools for the last generation or two? If your premise is based upon all > five songs starting out with equal terms from the beginning ... wouldn't > all songs have nearly the same number of plays? That's why I use a PAL > script named "oldest" that roots out songs that will NEVER get played > otherwise. > > PAL.Loop := True; > PAL.WaitForPlayCount(50); > // PAL To Select Oldest Song in the database > var D : TDataSet; > // Oldest Song > D := Query('SELECT * FROM songlist where songtype = ''S'' ORDER BY > date_played ASC LIMIT 1', [], True); > //Check if file actually exists > if FileExists(D['filename']) then > Queue.AddFile(D['filename'],ipBottom); > D.Free; > PAL.WaitForTime(T['+00:02:00']); > > I don't remember who wrote it otherwise I'd happily give attribution, > because it works. My only wish is that it would 'follow the rules" > Thus, I only let it add a song to the queue once every 50 songs, so as to > not drastically violate the DMCA rules. Without this PAL script very good > songs will never be heard by the listeners, since NONE of the rotation > choices does anything to insure that all songs of equal weight, equal > category, etc. would be chosen by the built-in clockwheel program. > Otherwise how could one song get nine times more play than another if all > variables were equal? Unless you believe that SAM has favorite artists and > ignores other artists. > > Anyway, my premise is that you started out with everything being equal on > a new installation with all songs being added at the same time. if that's > a different premise, I'd like Louis to work with both your premise and > mine. I really think this deserves a serious answer. And, I'm happy to > address the issue for a sixth year, because IMHO the "least recently > played" song is the same as the "oldest" song in the database addressed > by this PAL script. Another way of saying ... the song that has NOT been > played for the longest span of time. Louis has suggested that the > solution is to never add the tracks on an album at the same time and date. > However, if you've ever had a hard drive crash, you know that all files > taken from a back up will NOT have the original creation date/time but > will be dated the same date of the restoration. And, the same thing > happens when you move from one server to another. But SAM creates a last > date played listing that is a better date to use than the creation date. > If that "date_played" is the variable that smLRP is using why does the > above script get a different result? > Thanks for your question! > > Loran > > > > > > ----- Original Message ----- > From: "Michael Hughes" <[email protected]> > To: <[email protected]> > Sent: Sunday, January 04, 2009 10:38 AM > Subject: [General-discussion] LRP Rotation Question > > > Ok, let me see if I can explain the question with enough clarity to get a > good answer. > > Let us assume that there are 5 songs in a SAM category. All have the same > weight. All are different artists. All are different albums. None of these > clarifiers are being used to select the smLRP (least recently played). > With me? > > Song A - played 46 times > Song B - played 35 times > Song C - played 15 times > Song D - played 10 times > Song E - played 5 times > > Which track will SAM choose to play with all variables being the same and > I am using smLRP? > > What brings this question about is this: If I were to add a bunch of new > tracks to a category. They would be added with the default category > weight. But it appears that SAM will neglect all existing songs in that > category until some of these new tracks catch up with the play count. Is > this the case? When I add a bunch of new tracks do I need to reset the > playcount? > > > Michael Hughes > Christian Mix Inet > www.christianmixinet.net > 785-209-3249 > _______________________________________________ > General-discussion mailing list > [email protected] > http://mailman.spacialaudio.com/mailman/listinfo/general-discussion > > TO unsubscribe to this list, simply send a blank email to > [email protected] > > with the subject > 'unsubscribe' > _______________________________________________ > General-discussion mailing list > [email protected] > http://mailman.spacialaudio.com/mailman/listinfo/general-discussion > > TO unsubscribe to this list, simply send a blank email to > [email protected] > > with the subject 'unsubscribe' >
