DESCRIBE command in 'virtual' tuners pauses the stream

[lars18th]

Hi @Barracuda09 ,

Some SAT>IP client doesn't work with the SATPI because this:

• After the PLAY command the client sends a DESCRIBE command, and then the stream is paused by the SATPI.

See the LOG:

[                          src/HttpcServer.cpp:150] RTSP Stream data from client None with IP 192.168.1.27 on Port 49850: DESCRIBE rtsp://192.168.1.27:8554/stream=3 RTSP/1.0
CSeq: 4
Session: 0278654538
Accept: application/sdp
--- LINE END ---
[                        src/StreamManager.cpp:189] Found StreamID 3 - SessionID 0278654538
[                               src/Stream.cpp:218] Stream: 3, StreamClient[0] with SessionID 0278654538
[                        src/mpegts/Filter.cpp:043] Stream: 3, Clearing PAT/PCR/PMT/SDT Tables...
[          src/output/StreamThreadRtcpBase.cpp:076] Stream: 3, Pause RTCP/UDP stream to 192.168.1.31:6505
[              src/output/StreamThreadBase.cpp:153] Stream: 3, Pause RTP/UDP stream to 192.168.1.31:6504 (Streamed 0.001 MBytes)
[                          src/HttpcServer.cpp:204] RTSP/1.0 200 OK
CSeq: 4
Content-Type: application/sdp
Content-Base: rtsp://192.168.1.27/
Content-Length: 202
Session: 0278654538
--- LINE END ---

So, the client continues sending the OPTIONS command for the keep-alive, but it doesn't receive anything.

Please, can you fix this problem? Thank you!

[Barracuda09]

Yes, I will look into this.

[lars18th]

Yes, I will look into this.

Hi @Barracuda09 ,

I found the problem! :smile: The problem appears when using the ChildPIPE input.

Check this: https://github.com/Barracuda09/SATPI/blob/b7fb3e50a549ba0e242c5dbd727888511cbb6102/src/input/childpipe/TSReader.cpp#L157 But I see this for the Streamer: https://github.com/Barracuda09/SATPI/blob/b7fb3e50a549ba0e242c5dbd727888511cbb6102/src/input/stream/Streamer.cpp#L130

So if I change in the code of the chilpipe to return false then it works!

Using inheritance some problems like this will appear time to time. :wink:

Regards.

[lars18th]

Hi @Barracuda09 ,

I'm not sure if the above solution solves the problem.

Now, when using the childPIPE and translation with this patch, when no other real frontend is enabled and no other virtual has translation enabled I will see this behaviour:

• When the client requests a frequency that has translation the SATPI starts the stream. Up to here no problem at all. However, if the client uses a PLAY command with a new frequency, and this new frequency is not translated, then the SATPI continues serving the same source.

Check it:

[                          src/HttpcServer.cpp:150] RTSP Stream data from client None with IP 192.168.1.27 on Port 49853: PLAY rtsp://192.168.1.27:8554/stream=3?src=1&freq=10744&msys=dvbs&mtype=qpsk&pol=h&sr=22000&fec=34&ro=0.35&plts=off&pids=0,17,16 RTSP/1.0
CSeq: 93
Session: 0251523542
--- LINE END ---
[                        src/StreamManager.cpp:189] Found StreamID 3 - SessionID 0251523542
[                               src/Stream.cpp:215] Stream: 3, StreamClient[0] with SessionID 0251523542 for dvbs

As the session 3 exists, even if the frequency changed the SATPI process continues serving the previous input. So, my suggestion has side effects.

I comment it only to help you to find the best solution. Thank you for your effort!

[Barracuda09]

Thanks @lars18th

Well I see the real problem, not only childpipe but file and streamer have this as well.

In update() there should be an call to _deviceData.resetDeviceDataChanged();

In all the logic should be reviewed also when changing 'channels'

[lars18th]

Hi @Barracuda09 ,

Testing last commit. I feel the problem is gone. After a deep test I'll close the issue if it's really solved.

Thank your for the upgrade!

[Barracuda09]

Hi @lars18th

This should be fixed with latest commit

[lars18th]

This should be fixed with latest commit

I'll try. I see already some problems. I need to do more debug.

[Barracuda09]

Yes it is not fully fixed yet. I only opens once and closed with a TEARDOWN

[lars18th]

Hi @Barracuda09 ,

I don't close this issue, but I feel it's related to #81. I write here only as reference.

Regards.

[lars18th]

Hi @Barracuda09 ,

This bug is more complex: The DESCRIBE command can be associated to a specific stream. And the current code allways sends the full description of all active streams. So you need to expand the code to restrict the command to just one stream if it's passed.

I hope you can do it. Regards.

[lars18th]

Hi @Barracuda09 ,

The PR #85 fixes the problem of the PAUSE. However, I leave the issue open to resolve the problem of complete stream description with a DESCRIBE command with stream parameter.

I hope you want to merge it!

[Barracuda09]

Hi @Barracuda09 ,

The PR #85 fixes the problem of the PAUSE. However, I leave the issue open to resolve the problem of complete stream description with a DESCRIBE command with stream parameter.

I hope you want to merge it!

Hi @lars18th,

I have fixed this. And the DESCRIBE command with stream parameter was already fixed before as well.

[lars18th]

:+1: