separate recordings from input.harbor getting mixed up

[mcfiredrill]

Describe the bug

I have different DJs connect to the same harbour input, often times at very close intervals according to our radio schedule. Often times dj2's recording contains the end of dj1's set, or vice versa.

Has anyone else ever run into this problem with different DJs connecting to the harbor at pretty close intervals? I run into this situation testing locally.

dj1                                dj1
connect                           disconnect
   ^                                  ^
--------------------------------------------------> output.file("dj1.mp3")  (dj.mp3 will not be complete, missing last 1 sec or so)
                                           dj2                       dj2
                                         connect                 disconnect
                                           ^                          ^
                                          -----------------------------------------> output.file("dj2.mp3 contains last 1 second of dj1's set")

To Reproduce I've tried using reopen_when to try to solve this issue to no avail: https://github.com/datafruits/radio/blob/b49e5ad14c43925eafe983c8e7f040e4316e7fe4/liquidsoap/radio.liq#L172

I've tried another solution where I create new output.file sources for each harbor connect, and shut them down on disconnect, but I run into the exact same issue. https://github.com/datafruits/radio/blob/a3cb0974c8aa872d6b6f12fecc2698cf32584857/liquidsoap/radio.liq#L167

Let me know what other kind of information I can provide to solve this!

Expected behavior It would be great to have the recordings clean and separated, saving me time from having to edit them manually. :sweat_smile:

Version details

• OS: linux
• Version 1.4

Install method opam

[dtcooper]

Heya! Here's my 2 cents about what's happening from my testing with Crazy Arms.

In terms of arguments to input.harbor for your DJs,

• on_connect=<on_connect_func>,calls back immediately when the DJ connects but before the buffer is full and the source "comes up" (buffer=12.34 argument of input.harbor(), then after 12.34 seconds); and similarly
• on_disconnect=<on_disonnect_func calls back immediately when the DJ disconnects but before the buffer is drained and the source "goes down" (12.34 seconds before the end, in the example above)

Not sure about a recommendation here, but find a better hook that accurately starts recording when the source comes up and down.

[toots]

Hi all! I think @dtcooper is on the right track here. Most likely, the harbor still has an old buffered data in it when the new DJ disconnects. This shouldn't happen this way so I'll be looking at a fix for it.

Meanwhile, you should be able to wrap your harbor in a dummy output to make sure that all pending data is always consumed:

output.dummy(fallible=true, <harbor source>)

That should hopefully solve your issue short term.

[mcfiredrill]

Hello , I finally had some time to try to fix this again. I tried adding an output.dummy for my harbor input, per your advice. It doesn't seem to have any effect in solving the issue however.

Does it look like I'm doing it in the way you were talking about? https://github.com/datafruits/radio/pull/16/files#diff-5f3d2df10ed633699d35ae31c87d01247dd03fcf082261e8881dc18179df7ed3R227

[mcfiredrill]

@dtcooper gave me some advice to use the on_start/on_stop hooks of output.dummy to start/stop the recording source.

I have some more testing to do but this is very promising so far. :) https://github.com/datafruits/radio/pull/16/commits/8da1f97e3439fd6962515c8744bca4dac6fc5ed6#diff-5f3d2df10ed633699d35ae31c87d01247dd03fcf082261e8881dc18179df7ed3R69

[dtcooper]

Looks great! I'll end up stealing something like for Crazy Arms, so let me know how it goes. :)

[toots]

Hey! Curious: how does it goes if you remove the pipe operator? It might be caused by a buffer from stereotool and, unfortunately, we do not control that one.

If that is the case, I'd recommend to pipe to stereotool after the recording and optionally post-process the recording with stereotool offline.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[toots]

Any update on this issue? Does removing stereotool help?

[mcfiredrill]

I'm finally on the latest version 2.2.4, and I'm still seeing this issue with my setup. I'm using the builtin stereotool operator, not sure if that makes a difference.

If that is the case, I'd recommend to pipe to stereotool after the recording and optionally post-process the recording with stereotool offline.

I could still try this though