end of recordings getting cut off

[mcfiredrill]

No description provided.

[dudethatbe]

User story:

The tail end of recordings from streampusher appear to be missing when they are downloaded. This does not include the processing that sox takes care of (trimming, silence-removal, merging,...). During my last session I left maybe < 5 seconds of intentionally deadair. After disconnecting I monitored the livestream on datafruits. It never reached the deadair and cut off seemingly right before it. I think I could have waited longer to get the rest of the audio to go through to datafruits. The next day I downloaded the recording without processing it and even less of the audio than I remembered from the ending was there (it cut off earlier than from what the stream had played back). Here's a graph that I hope explains what was experienced if the story was hard to follow:

I'll try it out again and see how much is getting removed. Maybe its a client side issue with altacast? Maybe the sleep timer has to be increased? https://github.com/streampusher/radio/blob/master/liquidsoap/radio.liq#L177
Is everyone else experiencing this or just a few? 🤔

[mcfiredrill]

I've definitely seen it on other recordings as well, so I don't think its just you.
I don't think it was happening before I made those changes to how recordings work, so I don't think its a client issue either.

[mcfiredrill]

Maybe I should bump up the sleep time to 120 or more? Worse case, we end up with extra silence in the recording I guess? Which should be taken care of by processing anyway.

[mcfiredrill]

toots gave me an idea in the liquidsoap slack.

Hi @freedrull I think the best would be to use reopen_when and a string getter. You could do something like:
current_file = ref "some-file-name"
next_file = ref "some-file-name"
def reopen_when () =
  if !current_file != !next_file then
    current_file := !next_file
    true
  else
    false
  end
end
output.file(..., {"/path/to/#{!current_file}.mp3"}, ...)
(edited)





7:48
Then you should be able to trigger a re-open simply by setting next_file and waiting for the output to pick it up through reopen_when.





7:49
(code not tested but that should give you an idea..)

[bradwbradw]

i wonder what would happen if you wrote an automated test that makes a 5 second recording, or a 2 minute long recording, then verifies the length of the resulting file ?

[mcfiredrill]

There is another issue now, where recording files do not seem to get closed properly, and several DJs recordings get mixed together into often very large files. I'm not sure if using the new technique will solve this as well but it may be a start.