Bug #4207

SAT>IP with IPTV input: "pids=all" only sends "pids=0"

Added by Mono Polimorph 9 months ago. Updated 8 months ago.

Status:FixedStart date:2017-01-30
Priority:NormalDue date:
Assignee:-% Done:

0%

Category:SAT>IP
Target version:-
Found in version:last version Affected Versions:

Description

Hi,

I'm using one SAT>IP client that tries to receive the full transport stream.
It sends these commands:

  • OPTIONS rtsp://192.168.1.40:554/ RTSP/1.0
  • SETUP rtsp://192.168.1.40:554/?...
  • PLAY rtsp://192.168.1.40:554/stream=1?pids=all RTSP/1.0
  • TEARDOWN rtsp://192.168.1.40:554/stream=1 RTSP/1.0

And it receives over the RTP stream only packets for pid=0.
The key point is that the source is a IPTV multicast input, with a MPTS full a lot of pids.

Please, can you fix this error?

History

#1 Updated by Jaroslav Kysela 9 months ago

last version = v4.1-2418-g8e2b583 ?

#2 Updated by Mono Polimorph 8 months ago

Jaroslav Kysela wrote:

last version = v4.1-2418-g8e2b583 ?

Hi,

I check it today with the last version in the repository. And yes, the current version works with "pids=all". Thanks a lot!

However, I found an annoying problem: When I receive the full TS and the channel saturates (less bandwith in the network than the full TS), in this specific case my client hangs... and then the Tvheadend server goes wrong... some parts of the UI doesn't work and I can't check the status.

It seems the server enters in an finite loop. In the log the last messages are:

- [ DEBUG]:satips: 0/6BE9F04E/11: SETUP from ...
- [ INFO]:subscription: 000B: "SAT>IP" subscribing to mux ...

And no more messages. You know what happens?

#3 Updated by Mono Polimorph 8 months ago

Hi Jaroslav,

Please, close this issue. The "pids=all" trouble is fixed now, and the other trouble is described in the issue #4226.

Thank you!

#4 Updated by Jaroslav Kysela 8 months ago

  • Status changed from New to Fixed

Also available in: Atom PDF