At the same time, when capturing screenshots and recording, on_dvr cannot obtain the parameter, and the IP address also becomes 127.0.0.1.

[tadliu]

Description
When both screenshot and recording are enabled, on_dvr cannot obtain the param, and the IP address becomes 127.0.0.1. Everything works fine when screenshot is not enabled. It seems like the TCP connection is being reused incorrectly.

Please describe the issue you are facing.

1. SRS version: SRS/3.0.121(OuXuli)
   https://github.com/ossrs/srs, licensed under The MIT License (MIT), built at 2020-02-19 13:34:57, configured by --x86-x64 , which means --prefix=/usr/local/srs --with-hls --with-hds --with-dvr --with-ssl --with-transcode --with-ingest --with-stat --with-http-callback --with-http-server --with-stream-caster --with-http-api --with-librtmp --without-research --with-utest --without-gperf --without-gmc --without-gmd --without-gmp --without-gcp --without-gprof --log-trace --cc=gcc --cxx=g++ --ar=ar --ld=ld --randlib=randlib
2. SRS log:

[2020-02-20 11:28:40.747][Warn][90723][532][11] ignore task failed code=3008 : callback on_dvr http://xxx/auth.php : 
http post on_dvr uri failed, client_id=532, url=http://xxxx/auth.php, request=
{"action":"on_dvr","client_id":532,"ip":"127.0.0.1","vhost":"__defaultVhost__",
"app":"live","stream":"457556","param":"","cwd":"/root/srs/trunk",
"file":"./objs/nginx/html/live/2020-02/457556-1582169235680.flv"}, 
response=1, code=200 : http: response number code 1

1. SRS configuration:

listen 1935;
max_connections 1000;
srs_log_tank file;
srs_log_file ./objs/srs.log;
http_api {
    enabled on;
    listen 1985;
    raw_api {
        enabled on;
        allow_update on;
    }
}
http_server {
    enabled on;
    listen 8080;
    dir ./objs/nginx/html;
}
stats {
    network 0;
    disk sda sdb xvda xvdb;
}
vhost __defaultVhost__ {
    dvr {
        enabled on;
        dvr_path ./objs/nginx/html/live/[2006]-[01]/[stream]-[timestamp].flv;
        dvr_plan session;
        dvr_apply live/xxx;
        dvr_wait_keyframe on;
    }
    http_remux {
        enabled on;
        mount [vhost]/[app]/[stream].flv;
    }
    http_hooks {
        enabled on;
        on_publish http://127.0.0.1:8085/api/v1/snapshots http://xxx/auth.php;
        on_unpublish http://127.0.0.1:8085/api/v1/snapshots http://xxx/auth.php;
        on_dvr http://xxx/auth.php;
    }
}

Replay

How to replay bug?

Steps to reproduce the bug

1. objs/srs -c conf/srs.conf
2. nohup python research/api-server/server.py 8085 &>/dev/null &
   1. Push stream

Expected Behavior (Expect)
Not affected by screenshots

TRANS_BY_GPT3

[tadliu]

Temporary solution:
Modify line 1018 and line 1031 of research/api-server/server.py.

url = "rtmp://127.0.0.1/%s...vhost...%s/%s%s"%(req['app'], req['vhost'], req['stream'], req['param'])

TRANS_BY_GPT3

[winlinvip]

Check it.

TRANS_BY_GPT3

[duiniuluantanqin]

Premise: The content of the HTTP callback comes from the request (req), so if the callback encounters an exception, it is almost certain that the request has been modified.

The root cause of the problem is that the DVR's request (req) comes from the source, but the source's request changes with each request (play/publish) due to the update_auth. Previously, the last request was used (passing a pointer), which had issues. Later, it was changed to use the first request (making a copy), as seen in #1380. Now it seems that this also has issues.

In reality, there are many possible timelines.

1. publish->play->unpublish->dvr
2. play->publish->unpublish->dvr
3. play->publish->play->unpublish->dvr

We want to use the req in the publish.

It is necessary to carefully consider how to make modifications.

TRANS_BY_GPT3

[duiniuluantanqin]

Because the logic of the DVR is only related to publishing and not related to playing. The solution that is currently being considered is to copy the req in on_publish.

TRANS_BY_GPT3

[NodeBoy2]

In the cases of 2. play->publish->unpublish->dvr and 3. play->publish->play->unpublish->dvr, the DVR actually uses the req from the first play request, which causes the client IP in the DVR callbacks and on_publish/on_unpublish callbacks to be inconsistent.

I feel that what is needed in the initialize function is not the req information (including the client IP), but the metadata information of the request (tcurl, streamid, app, vhost, etc.). Can we store the req as the current streaming client information and pass it in on_publish? Can we add a new UrlRequest in SrsSource, which only includes the request metadata information, and pass it in initialize?

TRANS_BY_GPT3

[duiniuluantanqin]

@NodeBoy2

The new version has been fixed.
The DVR uses the published information.
You can try updating it.

TRANS_BY_GPT3

[NodeBoy2]

Testing verification is normal. The IP information in the req will be updated in update_auth. Like👍🏻.

TRANS_BY_GPT3