Prevent Now Playing Observable announcements until it's actually on-air

[VxJasonxV]

I'm using the Now Playing Observer to write out a file containing stream data, which is used by Nicecast in order to provide song metadata to our Icecast server. However, the metadata is written out as soon as the song is loaded. So when I'm shuffling through songs, a lot of erroneous data goes out.

I was watching the history pane in Serato DJ, and the data about the current song doesn't include a start time until the track actually goes on air, determined explicitly via both the crossfader, and the channel fader.

It seems to me that the underlying data provides a mechanism for knowing when a track is actually playing, but the reader naively treats a new song in the session file as being played.

The accuracy of the Now Playing observer would be dramatically improved if it evaluated this data (start time) before actually sending the announcements to the rest of the stack.

[ben-xo]

That's interesting. I don't think Serato used to do this, so currently it treats loading a track as equivalent to playing. What sort of control are you using (one of the Rane mixers, or regular Vinyl / CD control?)

I need to write a number of unit test scenarios and then fix the engine, really, to better model what's going on.

[VxJasonxV]

I wouldn't imagine that this is a difference between the Serato apps, because they all use the _Serato_ directory, and share settings, history files, track database, etc.

I'm using a DDJ-SX with Serato DJ.

[ben-xo]

Having seen the various forks people have been making to fix this bug: I only have vinyl / CD controls, but it looks like when you have a digital controller it more accurately writes the start time into the log. (With vinyl / CD control, it seems to treat loading the track as equivalent to starting the track). I have no way to test this at the moment, but it might be worth investing in.

[VxJasonxV]

FWIW, @Ayiga is a friend of mine who's help I enlisted. I've tried to come up with a solution that will never announce songs if they never go on-air. So far I haven't been successful. The logic for this should be really straightforward (no start time, no played increment, don't announce it), but whether the library/history logic has changed in SSL/SDJ since the parser was first written, or something else entirely, I'm unsure of why I'm not able to get the desired result.

I could really figure this out by recording video with timecode, but that just seems like a bit of overkill.

At any rate, like you don't have a controller, I don't have an SL interface to compare my findings with SSL.

Considering Serato's recent announcement ( http://serato.com/latest/blog/16301/scratch-live-users-whats-in-serato-dj-for-you ), if this behavior does differ, soon it should be much more consistent :).

[ben-xo]

When I was developing, I ended up making multiple copies of the history file "in flight" before and after doing certain operations in order to see what changes get written. You can then dump the structure of a file with something like

php historyreader.php --dump file

and it will help you figure out which fields are written when. (It writes multiple copies of the same thing as you perform certain actions - and then tidies the file up when you End Session).

(As I say, I found that the 'start time' was always written the moment i dropped the track on the deck, when using control vinyl and an external mixer, so that assumption has been built in - possibly in places it shouldn't have been)

[VxJasonxV]

Since Serato DJ supports secondary MIDI, I think I can wire something up with ControllerMate or OSCulator, and take snapshots of the current session file 5 seconds after doing something significant on my DDJ-SX (e.g. a load button, or moving the x-fader or up-fader).

Aside from the actual implementation itself, let me ask you something first. Now that I finally attended a live broadcast/recording, what are your feelings on the fact that in your case, the next song is spoiled? While I was listening, it was always a hassle to tell what the current song was, because the next one showed up within 10 seconds of the transition to the active song finishing. As you said, on Vinyl it's written as soon as the song is loaded.

My primary goal when I found this project was to be able to read the song data and dump it into Nicecast (surprise). My secondary goal it to integrate it with CamTwist or Quartz Composer in order to be able to have a "current song" overlay on video streams. Having the current title be out of sync by a full song is a bit of a bummer.

FWIW, this is an issue with Traktor-using co-workers of mine at work, because Traktor announces the song in stream metadata as soon as it's playing as well. We have a system in place that generates tracklists for recordings automatically that happen on our icecast server; And if someone picks a song, hits play, syncs it up, and then decided against using the song, it still shows up in the tracklist.

I think there's enough data in the session file (playTime, startTime, played, etc.) that we should be able to find a system that works for both Vinyl and Controllers (SSL and SDJ), it's just a matter of finding the appropriate events and data.

[ben-xo]

I feel criminal for not replying to this sooner. Hi @VxJasonxV , sorry it's been 8 years!

The current version of SSLScrobbler shouldn't really show a song as now playing until all of the following conditions are met:

• the previous song is no longer "playing" OR there is no previous song; and
• the current song has been "playing" for more than ScrobblerTrackModel::NOW_PLAYING_MIN seconds.

NOW_PLAYING_MIN is currently set to 30 seconds, but you can adjust it. (This mainly avoids triggering loads of events during track-selection, but it also gives us a bit of mixing time / grace period for spoilers).

The previous song is considered to be no longer playing when it has been loaded for and therefore has "finished" playing. In practise that means it "finishes" from our model's perspective a bit before its natural end, due to not knowing how long it was cued up for before you really started to play it.

"There is no previous song" is triggered when you eject the previous song, so in general use, this is the condition which triggers a Now Playing event most often.

However, I'd love to use events based on audibility, if they were available. I don't use a controller, I still go oldschool with my Technics and DJM 800.

I had a dream last night that it was time to upgrade that DJM 800…

[ben-xo]

(it would be easy to make NOW_PLAYING_MIN configurable at run time. It would probably break the few unit tests I wrote, though).

[kyds3k]

OK! The behavior I had noticed now makes sense, due to your previous song "no longer playing" criteria. I wish there was a more accurate way to tell - I often load the next track and have it sitting there for awhile before playing it, so I'm wondering if that throws it off.

Would it be possible to make the song "no longer playing" if it's been ejected from the deck? That sounds like something I could remember to do and give more accuracy . . .

[ben-xo]

Would it be possible to make the song "no longer playing" if it's been ejected from the deck? That sounds like something I could remember to do and give more accuracy . . .

It already does that; that's how I use it :)

[kyds3k]

Would it be possible to make the song "no longer playing" if it's been ejected from the deck? That sounds like something I could remember to do and give more accuracy . . .

It already does that; that's how I use it :)

I just loaded these 2 tracks:

the track on the right was at 2:20 or so, with over 2 minutes left . . . I loaded the left hand track in and started cueing it up to mix and the Now Playing changed to the left hand track after about 20 seconds, even though the currently playing track hadn't ended yet.

Terminal output (I started the whole thing with php ./historyreader.php -J 8080):

2: PLAYING    [--:--] [Xmal Deutschland - Mondlicht] [prev: The Cure - The Hanging Garden]
Date: 2021-04-29 11:30:38 Memory Usage: 2,854,336 bytes
2021-04-29 11:30:38 WARNING: SSLTrack - Guessed MP3 length 236 seconds from file.
2021-04-29 11:30:38 INFO: NowPlayingModel - enqueued track Love and Rockets - Mirror People '88 ((Single Edit))
2021-04-29 11:30:38 INFO: DmcaAlerter - Checking if track would break any Mixcloud DMCA limits
2021-04-29 11:30:38 INFO: DmcaAlerter - Nah, we're fine!
2021-04-29 11:31:07 INFO: ScrobblerTrackModel - Love and Rockets - Mirror People '88 ((Single Edit)) passed now playing point
2021-04-29 11:32:35 INFO: ScrobblerTrackModel - Love and Rockets - Mirror People '88 ((Single Edit)) passed scrobble point
2021-04-29 11:32:46 INFO: ScrobblerTrackModel - Xmal Deutschland - Mondlicht passed end point
2021-04-29 11:34:34 INFO: ScrobblerTrackModel - Love and Rockets - Mirror People '88 ((Single Edit)) passed end point
2021-04-29 11:35:25 INFO: DiffMonitor - Ignoring update to older session file /Users/adamdarby/Music/_Serato_/History/Sessions/5961.session```


Any ideas?

[ben-xo]

Sure so 2021-04-29 11:32:46 INFO: ScrobblerTrackModel - Xmal Deutschland - Mondlicht passed end point means you must have had that track loaded onto that deck for more than the length of the entire length of the song, so it assumes you must have listened to the whole thing by now. Do you load your tracks onto the deck minutes in advance? I tend to only load a track I'm going to play about a minute before I play it, so I haven't had problems with SSLScrobbler thinking the song has ended when it's only half way through. (It usually thinks its ended about 80% of the way through if i don't eject it first).

Without any code changes, the solution would be to keep the track off the deck a bit longer until you are ready to play it. But I could also change the code to make it wait longer e.g. song length x1.5 before treating it as ended, or make that configurable to your taste.

[kyds3k]

IIRC, I had the Xmal song loaded in there for only 20 seconds, and then it switched over. I kind of do a fly by the seat of my pants style of DJing, so I'll load in like 3-4 tracks before settling on one, and then it sits there for awhile. A configurable wait period would be awesome!

[ben-xo]

IIRC, I had the Xmal song loaded in there for only 20 seconds, and then it switched over. I kind of do a fly by the seat of my pants style of DJing, so I'll load in like 3-4 tracks before settling on one, and then it sits there for awhile. A configurable wait period would be awesome!

Yeah that's how I do it too. But it's actually probably that the song before was loaded for so long that it thought it must have finished by now, which is quite common if you load your first track a lot earlier than subsequent tracks. It might just be that, although I've got some things in the works to try to help with that situation too. I'll keep you updated