Feature: strikethrough and/or green bkgnd when song is "played"

[mpogue2]

Probably need

• a button to reset/clear the strikethroughs
• if a song is played more than X seconds, mark it played with a strikethrough, where X = say 30 sec

Note that this is different than "Age", which is in days, and changes to zero instantly when a song is played even for 1 second.

[mpogue2]

For comparison, here's what SquareView does (the green color is 0c00FF00):

[mpogue2]

This is a dup of #958.

[mpogue2]

In SqView 9.18.3:

• left double click loads the song AND marks it green (even before playback)
• right click moves the song to the queue AND marks it green (even before playback)
• the red X will clear the green for songs in that slot
• green markings are persistent (on disk) within a slot, but if I load the same songs into a separate slot, they are NOT colored green (so, each slot has its own "played" dictionary)
• text is always black (or as set in the preferences panel)

[mpogue2]

I'm inclined to do something like this:

• New Preference: Song is marked "played" when: -- song is loaded for playback -- song is played for 0 seconds -- song is played for 5 seconds -- song is played for 15 seconds (GEMA compliance) -- song is played for 30 seconds
• In each case played for N seconds means "played continuously for N seconds, where we check for playback approx once per second".
  -- Playback that jumps because of a cursor movement will still count as "continuously". -- Playback that stops because the user hit PAUSE or STOP will stop the clock, and will not count as "continuously". The counter will start anew when playback resumes. -- Playback that loops from End Loop Point to Start Loop Point will count as "continuously". It will NOT restart the counter.
• This affects when songs are marked played in the "played_on" table in the DB. No entry in the DB until the event selected in Preferences occurs.
• The equivalent of the "X" button, aka "reset played" just sets a timestamp that persists in the Preferences db. Anything AFTER that time that was marked "played" will show up as green background (or something equivalent).
• There will be no way to go backwards in time to set that timestamp to some earlier datetime (which would potentially unclear multiple songs).
• There will be no way to reset the played flag on an individual song.
• A song marked "played" will be marked so in the darkSongTable AND in any of the palette slots in which that song appears. The key will be the MP3 Pathname (before traversing symbolic links), so a singer soft-linked as a patter will be considered to be two separate songs for "played" purposes.
• File > Export Song History will use the "played_on" table for the exported date times (as today). So, if the preference is set to 15 seconds, the output CSV file should (in theory) be usable for GEMA compliance.

[mpogue2]

Hmmm...in thinking about this more, I kinda like strikethrough more than I like green background (or both), because then I don't have to worry that somebody will set the patter or singer color to 0x00FF00, making the text invisible.

[mpogue2]

NOTE: The Session > Clear Recent menu item and the "recent" column in the songTable are almost exactly what I described above, except:

• it uses a "*" instead of strike thru/green background
• it uses "played for any amount of time" as the criteria for played, and I really want it to be something more like 15 or 30 seconds of continuous playback (which would be more typical of usage during a real dance).

So, updated idea:

• SHORT TERM: change definition of "played" to user preference above (loaded/played for {0,5,15,30} secs). Then the "Recent" column can be used for exactly the "song was played since the last time I selected "Clear Recent", which was the original intent. But now it works better, because if I preview a song by playing it for 10 seconds, or jumping around (which I do often during development), it wouldn't count as "played" (better I think) [DONE]
• SHORT/MEDIUM TERM: get rid of Recent column, and express this just with strikethrough instead.
• SHORT/MEDIUM TERM: apply that strikethrough to all loaded playlist slots (right now it's just the darkSongTable)
• LONGER TERM: implement the automatic session detection as described in #961 [DONE]

[mpogue2]

Changing the definition of "played" to N seconds (I think I'll make it NON-contiguous, but contained within a session). So, we are discussing #961 in a bit more detail now... :-)

So, I think this works:

• Once a minute, check to see what session we are in using currentSessionIDByTime(), and update the current_session_id. This is a change from before, where the current_session_id was only ever set once. This will make sessions dynamic (a Good Idea, I think).
• When a song is loaded, clear the "SessionIDtoSecondsPlayed" array, which has one int for each valid session_id.
• Once a second, as a song is playing, if the SessionIDtoSecondsPlayed[current_session_id] != -1, increment the SessionIDtoSecondsPlayed[current_session_id]. If that value reaches N seconds, report using markSongPlayed() and set SessionIDtoSecondsPlayed[current_session_id] to -1 (meaning, it's been recorded as "played" already since the time when the song was loaded).

Implications:

• In a session, if (for N seconds each time) I play a song A, then a song B, then song A again, it counts as song A played TWICE, song B played ONCE.
• If I am near the end of a session S, and I play (for >N seconds) song A over the session boundary into session T (for >N seconds), then it counts as song A played once in Session S, and once in Session T.
• Playing a song with a loop (for >N seconds) counts as one play, unless it runs over a session boundary as above.
• Jumping around in a song, and playing for more than N seconds TOTAL (in a single session) will count as one play of that song in that session, even if each of the individual playback segments is less than N seconds. My guess is that's more in the spirit of GEMA compliance (although Gero might want to weigh in here).

[mpogue2]

Now that #961 is complete, we can use the session_id from songSettings to know what session we are currently in. So, I can now move on to implementing the above N seconds method for determining "played".

I'm gonna start out by defaulting it to 15 seconds to match GEMA reporting, I can always put in a preference for N later. In the short term, this will also allow me to preview songs without causing them to be marked as "played", which is what I wanted, so as to eliminate my manual tracking.

I will probably need a button or OPTION-Menu Item to be able to remap all the sessions the DB to the new session definitions, which will look like (for me):

• Practice: 12:01AM (so everything will low-priority default match to here)
• Jokers: 6:00PM (we don't have end datetime's yet, club starts at 6PM)
• ECR: 7:00PM (we don't have end datetime's yet, club starts at 7PM)

If I do this, then in theory the Recent and Age columns will give me what I have been tracking by hand. If I start a test playback before Jokers starts at 6PM, it will count as Practice until 6PM at which time it will count as Jokers. That's exactly what I wanted...

[mpogue2]

Commit: 270101a3e0dc83b89034ed237c73ffbe0dc38329

A song now needs to play for 15 seconds in a session, before it is marked as "played". If a song plays over a session boundary, it could be marked "played" in the earlier session (if it had more than 15 seconds of playback there), and also in the later session (if it had more than 15 seconds of playback there).

It will also be handled correctly if the user is in Manual mode, and manually changes the session from the Session menu. It will also be handled correctly if the user is switching between Manual and Automatic modes while a song is playing.

NOTE: right now the threshold, N, is fixed at 15 seconds, which should be compatible with GEMA reporting requirements. We can put in a pulldown menu preference later to change this to, for example, {0, 1, 5, 15, 30} seconds, where 0 means "played when loaded".

The current GUI affordance associated with this feature is the Recent column.

[mpogue2]

Commit: 01ac44bc93946b77ad80d2639a626a861cf21108

Fixed a couple of bugs when updating the session manually.

The Recent and Age columns seem to be working correctly now, for Manual and Automatic session setting.

[mpogue2]

TODOs left:

• change background to green strikethrough (would avoid clash of foreground and background colors) when a song has been "played". The green is reminiscent of the color that SquareView uses, so it should be obvious what this strikethrough means, for existing SquareView users. [DONE]
• Change menu item "Clear Recent" to
• • Set Recent To >
• • • now
• • • 1 month ago
• • • 3 months ago
• • • 6 months ago
• Some code factoring, see below.

The "Set Recent To..." is really needed, because it's super obnoxious when the green strikethrough strikes through a bunch of songs because I switched over to the Jokers Session to see what I had called already, and previewed a couple of songs, and found them marked already. Might need a preference or a toggle to turn off the green strikethrough, too...

The idea is good, but the execution is not complete yet, so it's not really usable yet, IMHO.

[mpogue2]

Strikethrough is: "text-decoration: line-through;"

[mpogue2]

Examples of line-through and background-color:

[mpogue2]

And with the "other" shown:

[mpogue2]

Commit: a799b197cd161e06e36f7d2f14acd24436beeb3d

When a song has played in the current session for >=15 seconds, we'll overlay a green strikethrough, both in the darkSongTable and in the palette slots, to indicate that the song has been "played". Use "Clear Recent" to reset the fence to "now()", thereby removing the strikethroughs. Use "Don't Save Plays" to disable strikethrough (and, I think, recording plays to the current session).

I think we might want a user preference to View/Not View the strikethroughs. There's probably a valid use case where we want songs to be recorded against the session when played, but we don't want to see any green strikethroughs.

TODO: There is some duplicated code that I want to factor out when I have time, something like updateStrikethroughInPaletteSlots().

[mpogue2]

There needs to be a way to disable this, because it's annoying when it's there and I am just poking around.

[sharmanr]

This maybe a bit off topic, but I've wanted for a long time is when in "practise" mode see what songs have not been played recently in a particular session. In other words, I'm getting ready for my Tuesday session and working on a playlist and would like to filter out songs "recently" played there.

I don't see an easy way of implement it.

[mpogue2]

I think the basic idea has been implemented, so closing. Adding Richard's suggestion as a feature. Yeah, I want that feature too!