Record block seems to ingnore manual

[Fenrirthviti]

I've been using the arut/nginx-rtmp-module for several years now, and recently decided to try this fork out, as it seems much more active and contains dozens of explicit bug fixes that I've personally encountered as the origin is essentially a dead project at this point.

Most everything is working, however, my record blocks seem to be always active, regardless of setting manual or not. Am I missing something simple that was changed in this fork (I'm using the dev branch)?

Here is the record block I'm using: https://gist.github.com/Fenrirthviti/90e9e42dc961944d8507c8e9f7be0000

I can provide more of the config if necessary. Changing back to the arut/nginx-rtmp-module causes record blocks to function properly again.

[Fenrirthviti]

Forgot to note, I can stop the recording, and the exec_record_done is executed properly, but the recording starts again immediately with no interaction on my end.

[ethernetweb]

I had the same issue but I think there was a syntax change in this version.

Mine was: record all manual;

Changed to: record manual;

It hasn't been modified in the Control Module documentation however: https://github.com/sergey-dryabzhinsky/nginx-rtmp-module/blob/dev/doc/control_modul.md#record

[elogy]

I've experienced the same problem, however when I change the command to record manual, the output file is stuck at 0 bytes, even when I stop the recording.

[ethernetweb]

I tested this and have confirmed it.

record all manual; doesn't work on manual and starts recording no matter what, record manual; records 0 bytes.

[Fenrirthviti]

Confirmed as well. 0 byte recordings.

[ghost]

Yeap, same here. 0 byte recordings.

[elogy]

Once I get back to it this week, I'll try to include a debug output for the 0 byte problem. I've already built nginx with the debug flag, should I open that up as another issue?

[ocam-ua]

+1. Recording is always turned on if record directive present, regardless of its value

[Fenrirthviti]

@sergey-dryabzhinsky Any ideas on this?

[Fenrirthviti]

Any updates on this? Or does anyone have any idea where this bug was introduced so I can remove it from my local copy?

This is a pretty crippling bug...

[CkNoSFeRaTU]

Try uncommenting rctx->file.fd == NGX_INVALID_FILE block in ngx_rtmp_record_node_avd of ngx_rtmp_record_module.c

[Fenrirthviti]

Thanks @CkNoSFeRaTU

I've verified that reverting commit https://github.com/sergey-dryabzhinsky/nginx-rtmp-module/commit/d86287fe3cf443d02cda20df1795aa9d3ec6d673 corrects the issue, but I'm not exactly sure what the bug that commit is trying to fix is or how to test against it.

EDIT: May have spoken too soon. Reverting this fix corrects my "record all manual;" blocks, but the ones I have set up for automatic use (for taking live screenshots) do not work at all:

Works:

recorder rec {
  record all manual;
  record_suffix .flv;
  record_unique on;
  record_path /var/rachni/rec;
  record_notify on;
  record_lock on;

  exec_record_done /etc/nginx/conf.d/rtmp_convert.sh $dirname $basename;
}

Does not work:

 # make previews
recorder preview {
  record keyframes;
  record_max_frames 4;
  record_path /var/rachni/preview;
  record_interval 30s;

  exec_record_done ffmpeg -i $path -vcodec png -vframes 1 -an -f rawvideo -s 534x300 -ss 00:00:01 -y /var/www/html/img/thumbs/thumb_$name.png >>/var/log/rachni/previewsmall.log;
  exec_record_done ffmpeg -i $path -vcodec png -vframes 1 -an -f rawvideo -ss 00:00:01 -y /var/www/html/img/channel/channel_$name.png >>/var/log/rachni/previewfull.log;
  exec_record_done ffmpeg -i $path -vcodec png -vframes 1 -an -f rawvideo -s 534x300 -ss 00:00:01 -y /var/www/html-dev/img/thumbs/thumb_$name.png >>/var/log/rachni/previewsmall.log;
  exec_record_done ffmpeg -i $path -vcodec png -vframes 1 -an -f rawvideo -ss 00:00:01 -y /var/www/html-dev/img/channel/channel_$name.png >>/var/log/rachni/previewfull.log;
}

[sergey-dryabzhinsky]

@Fenrirthviti Seems like you're right about commit. I'll try to figure out whats wrong.

At first look there is logical issue with record flags processing. record keyframes may not work at all.

[sergey-dryabzhinsky]

Can anyone try latest code from issue-214-fix-record-flags-processing branch?

[ethernetweb]

@sergey-dryabzhinsky Attempted a compile

-o objs/addon/nginx-rtmp-module/ngx_rtmp_record_module.o \
../nginx-rtmp-module/ngx_rtmp_record_module.c

../nginx-rtmp-module/ngx_rtmp_record_module.c: In function ‘ngx_rtmp_record_write_frame’: ../nginx-rtmp-module/ngx_rtmp_record_module.c:1010:28: error: invalid type argument of ‘->’ (have ‘ngx_time_t’) next_t = rctx->last->sec 1000 + rctx->last->msec + rracf->interval; ^ ../nginx-rtmp-module/ngx_rtmp_record_module.c:1010:53: error: invalid type argument of ‘->’ (have ‘ngx_time_t’) next_t = rctx->last->sec 1000 + rctx->last->msec + rracf->interval; ^ objs/Makefile:1327: recipe for target 'objs/addon/nginx-rtmp-module/ngx_rtmp_record_module.o' failed make[1]: [objs/addon/nginx-rtmp-module/ngx_rtmp_record_module.o] Error 1 make[1]: Leaving directory '/root/compile-nginx/nginx-1.10.3' Makefile:8: recipe for target 'build' failed make: [build] Error 2

[sergey-dryabzhinsky]

@ethernetweb Fixed, please try again.

[Fenrirthviti]

I was able to build, but the issue where record manual blocks cannot be actually stopped (if you stop them, they do "stop" but restart immediately and automatically) is back, and none of my record keyframes blocks are working either.

Compiled with nginx 1.12.0

[Fenrirthviti]

Any further information I can provide to help move this along? I'm no C/C++ developer, but I can do any building and testing needed. I'd really love to start using this version, as it fixes quite a few other bugs I've been experiencing from the upstream master.

[Fenrirthviti]

@sergey-dryabzhinsky Any updates on this issue? Apologies for being a pest, please let me know if there's anything else I can do to help.

[olablt]

any updates? how to fix this?

[Fenrirthviti]

I would also love to know. Still ready any willing for any build testing that needs to happen.

[dogenius01]

This is so sad... still same.

[kanaldro]

I confirm this issue is still around.