Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

recording lost/overwritten when reconnecting to stream #141

Open
jelko opened this issue Jan 14, 2019 · 3 comments · May be fixed by #200
Open

recording lost/overwritten when reconnecting to stream #141

jelko opened this issue Jan 14, 2019 · 3 comments · May be fixed by #200

Comments

@jelko
Copy link

jelko commented Jan 14, 2019

When we use Darkice to stream to Liquidsoap → Icecast2 and record to a localDumpFile we encounter the following issue: When Liquidsoap is restarted, Darkice successfully reconnects, but the dumpFile is overwritten and therefore the old recording is lost. We do use fileAddDate = yes. Nonetheless the file is written to the timestamped filename when Darkice was originally started, and not to the moment of reconnection, what could be the expected behaviour.

How to reproduce?

  1. Stream and Dump to Liquidsoap
  2. Restart or Reload Liquidsoap sudo service airtime-liquidsoap restart
  3. Recorded file start from zero

Setup: Ubuntu 18.04 with Liquidsoap 1.1.1, Icecast 2.4.3 and Darkice 1.3
@neingeist
Copy link

This is a ten year old bug, I think. I fixed it here:

darkice-proposed-fileAddDate-SIGUSR1-change-20120824.patch.txt

I've been using the attached patch on Darkice 1.1 for years. It just came up with the handover of an old project of mine. The patch may need work for Darkice 1.3.

To reproduce one can use fileAddDate and killall -USR1 darkice - darkice 1.1 just overwrote the old file. Same thing happens when reconnecting.

Perhaps someone using Darkice 1.3 can update/review the patch and submit a PR.

@bjacke
Copy link

bjacke commented Mar 14, 2023

This patch works fine for me, thank you, neingeist!

Is there anything to help to get this upstream?

@bjacke
Copy link

bjacke commented May 30, 2023

ping. Looking at this and other reported issues without feedback, I'm wondering if darkice is still actively maintained (?)

bjacke pushed a commit to bjacke/darkice that referenced this issue Oct 28, 2024
fix fileAddDate with SIGUSR1
9c9435e 
If fileAddDate = yes is set and if we send darkice the USR1 signal, it should
write the data into the file with the up-to-date date, not override the initial
one.

My patch is based on the patch from neingeist.

This fixes rafael2k#141
@bjacke bjacke linked a pull request Oct 28, 2024 that will close this issue
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

fix fileAddDate with SIGUSR1 bjacke/darkice
3 participants
@neingeist @jelko @bjacke