Trackman log on/off times should trigger show recordings

[echarlie]

From @telnoratti on March 2, 2015 5:30

This is a potential better way to link to shows on the archive.org site.

Copied from original issue: wuvt/wuvt-site#26

[echarlie]

From @matthazinski on March 2, 2015 5:38

So I assume the way this would function is:

• A DJ logs in, which triggers a streamrip to begin
• A DJ logs out, and the streamrip is stopped
• The streamrip is uploaded to IA and linked on the DJ's page. Trackman will need to know which item name is associated with each DJ. (That is, assuming each DJ has one item per show, which is easiest)

Some things to consider are:

• Why is the web server doing the stream rip? Why not have the stream server just provide an API to start/stop arecord? I'm concerned about icecast's buffering issues.
• Why bother passing through the Optimod in the first place? A computer in FM could provide uncompressed audio.

[echarlie]

From @telnoratti on March 2, 2015 5:43

Trackman itself should not be doing the stream rip, but instead control the process. You're right though it should definitely not be run on the same machine as the webserver. Transcoding could be problematic as my bench-marking of the site's performance hasn't been promising.

There's a nasty edge case where DJs often log out before they're done, so we should keep recording until there's a song change or a new DJ logs in, not sure exactly.

[echarlie]

From @matthazinski on March 4, 2015 6:57

Another thing: this should also send appropriate metadata (especially DJ name) to the IA as well so it's easier for people to find things. Ideally a playlist would be included too but I'm worried this would make it too attractive a target for DMCAs.

[echarlie]

From @mutantmonkey on March 11, 2015 6:10

Dude, either it's a copyright violation or it's not. It makes no difference how hard it is to find.

[echarlie]

From @matthazinski on March 11, 2015 18:4

it's harder for bots to find this way

[mutantmonkey]

To be honest, I'm quite partial to the current setup. It has fewer moving parts and has proven itself after several years in production. Does anyone have any thoughts?

[echarlie]

Current setup is bulletproof, but does have issues with tracks and DJ talking running over the top of the hour. I'm not sure going to whole-show recordings would be better, though; we need a fallback mechanism to prevent fragility which increases complexity substantially.

Perhaps it would be useful to have a websocket that alerts on arbitrary events, including DJ changing, or support configurable webhooks?

[mutantmonkey]

What is the issue exactly? The recordings should be seamless if you play them back to back.

The SSE endpoint already provides what you're requesting, so it seems like there's nothing left to be done here. I'll go ahead and close this.