[slinkelist] Suggestion for not replaying tracks already played

[Jeff Schaffer]

Another thought occurred to me

Why not build the bit array I described below (4 bytes per slot could 
represent 32 tracks per slot, 10KB could represent 2500 slots) 
whenever a random play session starts? In other words, evaluate the 
query, store 1 bits for all the tracks that match, and turn them off 
as you play them? When there are no 1-bits left, evaluate the query 
again. rebuild the bit-array, and start over?

This guarantees no false replays.

Jeff

>Date: Fri, 29 Sep 2000 19:25:42 -0400
>To: Michael Holopainen <michael@laserle.fi>, "slinkelist@nirvis.com" 
><slinkelist@nirvis.com>
>From: Jeff Schaffer <j.schaffer@snet.net>
>Subject: Re: Fwd: RE: [slinkelist] Random play in newest version
>Cc:
>Bcc:
>X-Attachments:
>
>1. That part I understood. If you perform a query, tracks are 
>selected from the list of results from the query. My point was that 
>a played track eventually falls off of the playlist. Does this make 
>it eligible to be selected again during the same session?
>
>If so, the only guaranteed way would be to keep a list of all tracks 
>played in the current session and never select anything already in 
>the list. If that leaves nothing to select, clear the list and start 
>over. Using 1 bit to record whether a track has been played, I'd 
>allocate 4 bytes per slot (up to 32 tracks per disk, still have to 
>handle exceptions for disks that have more than 32 tracks) so you 
>could track the play history of over 2500 slots in just 10KB. Or 
>just implement a hack to play nothing played in the last 24 hours. 
>;-)
>
>2. If you show, say, two additional tracks after the currently 
>playing track, I wanted to make sure that "aren't from the same 
>player" doesn't refer to the track just played, but refers instead 
>to the player of the last track queued ahead in the playlist.
>
>3. If the track selected is already not from the player of the last 
>track in the playlist, what does "have a short queue time" mean? 
>From experience it doesn't mean the same disk in the same player 
>already queued ahead of the current track. For example if p1d1t1 is 
>playing, p2d1t1, p1d100t1, and p2d100t1 are queued, I'm curious how 
>"short queue time" is evaluated.
>
>Jeff
>
>At 9:13 AM +0300 9/29/00, Michael Holopainen wrote:
>>I'm not Colby, but here is how I understood it :
>>
>>1. random play = picks items from LIBRARY and creates RANDOM playlist on
>>the fly
>>2. yes
>>3. alternate players so there is no silence while CDP-CX???
>>unload/search/load disks
>>
>>P.S. I haven't yet found time to try the newest CDJ version, but I look
>>frward doing so over the weekend.
>>
>>Jeff Schaffer wrote:
>>>
>>>  [I sent this in reply to a note sent by Colby and omitted the distlist.]
>>>
>>>  Colby,
>>>
>>>  On the priorities, some comments, questions:
>>>
>>>  1. aren't already in the playlist (items can fall off the list)
>>>  2. aren't from the same player (as the last track in the playlist?)
>>>  3. have a short queue time (what's the definition of this?)
>>
>>
>>_______________________________________________
>>slinkelist maillist  -  slinkelist@nirvis.com
>>http://www.nirvis.com/mailman/listinfo/slinkelist