Dynamic PMT not working with DD Octopus (1 Viewer)

[mm1352000]

Link back to the related thread in the German forum (logs etc.):
MP 2.2.1 April 2019 Neuerungen: Digital Devices Dynamisches PMT

Perhaps somebody could be so kind as to translate... ?

First: the previous patch is only effective for DD tuners that are directly connected to the PC (eg. Cine S2). It has no effect for SAT>IP (eg. OctopusNET) tuners.

Second: I don't see any attempt to view encrypted channels in the previously provided log files. All tuning details are marked as "FTA:True" = free-to-air = not encrypted/scrambled. For example:
[2019-07-22 17:38:12,140] [2360306] [34 ] [DEBUG] - dvbip: TuneVBIP:tv:ARD Test R Freq:0 ONID:1 TSID:1051 SID:28726 PMT:0x258 FTA:True LCN:0 Url:rtsp://@192.168.100.80/?src=1&freq=10744&pol=h&msys=dvbs&sr=22000&pids=0,600,501,0,502,501,18,17,16

Third: decrypting channels with SAT>IP tuners is not standardised. DD have their own mechanism for decrypting channels which involves extra URL parameters. I cannot see these parameters being used in the log files either.

In short: I'm confused. It would be good if @zorrokater could clarify the symptoms of the problem and the expected outcome.

 

[HTPCSourcer]

First: the previous patch is only effective for DD tuners that are directly connected to the PC (eg. Cine S2). It has no effect for SAT>IP (eg. OctopusNET) tuners.

That explains why it works for me but not for @zorrokater.

Second: I don't see any attempt to view encrypted channels in the previously provided log files. All tuning details are marked as "FTA:True" = free-to-air = not encrypted/scrambled.

It's not about decrypting. We have some channels here that are dynamically switching content, eg regional programming where the same channel may temporarily transmit different content depending where you are receiving it.

The feature is demonstrated on Astra on the channel "Test R" which switches every 60 from Arte to Phoenix and back. Both are FTA channels. This is working nicely on my Cine S2.

 

[KayDiefenthal]

hi @mm1352000

did you knowing what the trigger for an pmt change is? is there an descriptor for it?
in the etsi dvb spec had i currently nothing found

 

[mm1352000]

That explains why it works for me but not for @zorrokater.

Indeed.

It's not about decrypting. We have some channels here that are dynamically switching content, eg regional programming where the same channel may temporarily transmit different content depending where you are receiving it.

Ahhh, now I understand.

I was confused because the previous patch related directly to decryption. If I recall correctly, in the previous case new audio streams were appearing but could not be used because they were not being decrypted. The patch sent a new decrypt request to the CAM to make it decrypt the new audio streams.

So you're right - the situation you've described is quite different and unrelated to the purpose of the patch.

The feature is demonstrated on Astra on the channel "Test R" which switches every 60 from Arte to Phoenix and back. Both are FTA channels. This is working nicely on my Cine S2.

Indeed.

The reason it isn't working with the SAT>IP tuner is because all streams (PIDs) must be individually requested, as you can see in this example URL:
[2019-07-22 17:38:12,140] [2360306] [34 ] [DEBUG] - dvbip: TuneVBIP:tv:ARD Test R Freq:0 ONID:1 TSID:1051 SID:28726 PMT:0x258 FTA:True LCN:0 Url:rtsp://@192.168.100.80/?src=1&freq=10744&pol=h&msys=dvbs&sr=22000&pids=0,600,501,0,502,501,18,17,16

The TV library code assumes that all streams are always available (PID filtering not supported), and so the only thing that is done when a dynamic PMT change occurs is a new decrypt request (to ensure all the streams are decrypted). For the SAT>IP tuner to receive the new streams, an entire new tune request would need to be issued. This is not feasible with the current code for several reasons including:

• The code context where it is possible to retune is a long _long_ way from the dynamic PMT change context. Connecting these 2 in TVE 3 would be very hard.
• The code treats DVB-IP channel URLs as a black box. It doesn't know about SAT>IP and parameters such as freq, pids etc. Therefore even if the code could be modified to retune, it would retune with the same URL which is missing the new PIDs.

Really, the best solution to this issue is proper SAT>IP support. Obviously it's no comfort to say that I implemented this for TVE 3.5. Unfortunately nobody seems to be interested enough to spend the time backporting the TV library.

The best workaround I can suggest for TVE 3 is to modify the channel URLs to include all possible PIDs that may ever be sent. Of course these often may not be known in advance, but it's really the only thing I can think of that doesn't require a code change.

 

[mm1352000]

hi

Hi!

did you knowing what the trigger for an pmt change is?

The broadcaster triggers it. We (TsWriter) can detect the updates by looking for changes in the version field of the PMT:
MediaPortal/MediaPortal-1

is there an descriptor for it?

No.

in the etsi dvb spec had i currently nothing found

Yes, you won't find anything in the ETSI/DVB spec. This is an MPEG 2 transport stream (ISO/IEC 13818 part 1) concept. Refer to "Table 2-33 – Transport Stream program map section" (page 54) "version_number" field.
https://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC-H.222.0-201703-S!!PDF-E&type=items

version_number–This 5-bit field is the version number of the TS_program_map_section. The version number shall be incremented by 1 modulo 32 when a change in the information carried within the section occurs. Version number refers to the definition of a single program, and therefore to a single section. When the current_next_indicator is set to '1', then the version_number shall be that of the currently applicable TS_program_map_section. When the current_next_indicator is set to '0', then the version_number shall be that of the next applicable TS_program_map_section.

 

[KayDiefenthal]

ok if i understand it right so is an lookup for service id - pmt/pcr id needed to get tuning details
then send an play request with this data to the satip server

 

[KayDiefenthal]

ok had look where test-r ,pheonix and arte are located
all on the same transponder so is only an playrequest with pids for pmt video audio needed

but i think the problem is the way how mp supporting satip

tve had the tunerequest controlling and build an filtergraph for receiving the media
in the receiving path is the pmtgrabber and had so no way to report the pmt change back to the controlling path

 

[zorrokater]

Hello, thank you for your interest and effort in solving my Problem.
Best regards
Zorrokater

 

[mm1352000]

Hello, thank you for your interest and effort in solving my Problem.

You're very welcome.

Do you understand the workaround suggestion that I made?

As an example, for "Test R" you could change the channel URL from "rtsp://...pids=0,600,501,0,502,501,18,17,16" to "rtsp://...pids=0,16,17,18,401,402,501,502,600". Adding 401 and 402 is the important change. (I also removed unnecessary duplicates and reordered for clarity.)

• 0 = PAT (always needed)
• 16 = NIT (needed for scanning)
• 17 = SDT (needed for scanning)
• 18 = EIT (needed for EPG data)
• 401 = first video PID
• 402 = first audio PID
• 501 = second video PID
• 502 = second audio PID
• 600 = PMT (needed for tuning)

You can find these in the server log file.
(original tuned PIDs)
[collapse][2019-07-22 17:33:55,709] [2103875] [12 ] [DEBUG] - dvbip: TuneVBIP:tv:ARD Test R Freq:0 ONID:1 TSID:1051 SID:28726 PMT:0x258 FTA:True LCN:0 Url:rtsp://@192.168.100.80/?src=1&freq=10744&pol=h&msys=dvbs&sr=22000&pids=0,600,501,0,502,501,18,17,16
...
[2019-07-22 17:33:56,944] [2105111] [28 ] [DEBUG] - subch:0 OnPMTReceived() pmt:258 ran:True dynamic:False
[2019-07-22 17:33:56,945] [2105112] [12 ] [DEBUG] - WaitForPMT: Found PMT after 0.2141316 seconds.
[2019-07-22 17:33:56,946] [2105113] [12 ] [INFO ] - subch:0 SendPmt:7036 7036 FFFFFFFF 1D
[2019-07-22 17:33:56,946] [2105113] [12 ] [DEBUG] - Decode pmt
[2019-07-22 17:33:56,947] [2105114] [12 ] [DEBUG] - Set descriptor data with length 3
[2019-07-22 17:33:56,948] [2105115] [12 ] [DEBUG] - Set descriptor data with length 3
[2019-07-22 17:33:56,951] [2105118] [12 ] [DEBUG] - PROBLEM : descriptor lengths dont match 6 9
[2019-07-22 17:33:56,952] [2105119] [12 ] [INFO ] - subch:0 SendPMT: Channel is FTA, nothing to do.
[2019-07-22 17:33:56,953] [2105120] [12 ] [DEBUG] - subch:0 SetMpegPidMapping
[2019-07-22 17:33:56,953] [2105120] [12 ] [DEBUG] - subch:0 pid:191 pcr
[2019-07-22 17:33:56,954] [2105121] [12 ] [DEBUG] - subch:0 pid:258 pmt
[2019-07-22 17:33:56,955] [2105122] [12 ] [DEBUG] - subch:0 pid:191 video type:MPEG-2
[2019-07-22 17:33:56,955] [2105122] [12 ] [DEBUG] - subch:0 map pid:191 video type:MPEG-2
[2019-07-22 17:33:56,956] [2105123] [12 ] [DEBUG] - subch:0 pid:192 audio lang:deu type:MPEG-1
[2019-07-22 17:33:56,956] [2105123] [12 ] [DEBUG] - subch:0 map pid:192 audio lang:deu type:MPEG-1[/collapse]

(alternative PIDs)
[collapse][2019-07-22 17:34:00,095] [2108261] [28 ] [DEBUG] - subch:0 OnPMTReceived() pmt:258 ran:True dynamic:True
[2019-07-22 17:34:00,096] [2108262] [PMT update] [INFO ] - subch:0 SendPmt:7036 7036 1D 1C
[2019-07-22 17:34:00,097] [2108263] [PMT update] [DEBUG] - Decode pmt
[2019-07-22 17:34:00,098] [2108264] [PMT update] [DEBUG] - Set descriptor data with length 3
[2019-07-22 17:34:00,098] [2108264] [PMT update] [DEBUG] - Set descriptor data with length 3
[2019-07-22 17:34:00,099] [2108265] [PMT update] [DEBUG] - PROBLEM : descriptor lengths dont match 6 9
[2019-07-22 17:34:00,099] [2108265] [PMT update] [INFO ] - subch:0 SendPMT: Channel is FTA, nothing to do.
[2019-07-22 17:34:00,100] [2108266] [PMT update] [DEBUG] - subch:0 SetMpegPidMapping
[2019-07-22 17:34:00,100] [2108266] [PMT update] [DEBUG] - subch:0 pid:1F5 pcr
[2019-07-22 17:34:00,101] [2108267] [PMT update] [DEBUG] - subch:0 pid:258 pmt
[2019-07-22 17:34:00,101] [2108267] [PMT update] [DEBUG] - subch:0 pid:1F5 video type:MPEG-2
[2019-07-22 17:34:00,101] [2108267] [PMT update] [DEBUG] - subch:0 map pid:1F5 video type:MPEG-2
[2019-07-22 17:34:00,102] [2108268] [PMT update] [DEBUG] - subch:0 pid:1F6 audio lang:deu type:MPEG-1
[2019-07-22 17:34:00,102] [2108268] [PMT update] [DEBUG] - subch:0 map pid:1F6 audio type:MPEG-1
[/collapse]

Note these values are hexadecimal. Convert to decimal by Google [for example] "0x191 to decimal" => 401.

I hope this is clear.

Sorry again that I don't have a better suggestion.

 

[KayDiefenthal]

You're very welcome.

Do you understand the workaround suggestion that I made?

As an example, for "Test R" you could change the channel URL from "rtsp://...pids=0,600,501,0,502,501,18,17,16" to "rtsp://...pids=0,16,17,18,401,402,501,502,600". Adding 401 and 402 is the important change. (I also removed unnecessary duplicates and reordered for clarity.)

• 0 = PAT (always needed)
• 16 = NIT (needed for scanning)
• 17 = SDT (needed for scanning)
• 18 = EIT (needed for EPG data)
• 401 = first video PID
• 402 = first audio PID
• 501 = second video PID
• 502 = second audio PID
• 600 = PMT (needed for tuning)

You can find these in the server log file.
(original tuned PIDs)
[collapse][2019-07-22 17:33:55,709] [2103875] [12 ] [DEBUG] - dvbip: TuneVBIP:tv:ARD Test R Freq:0 ONID:1 TSID:1051 SID:28726 PMT:0x258 FTA:True LCN:0 Url:rtsp://@192.168.100.80/?src=1&freq=10744&pol=h&msys=dvbs&sr=22000&pids=0,600,501,0,502,501,18,17,16
...
[2019-07-22 17:33:56,944] [2105111] [28 ] [DEBUG] - subch:0 OnPMTReceived() pmt:258 ran:True dynamic:False
[2019-07-22 17:33:56,945] [2105112] [12 ] [DEBUG] - WaitForPMT: Found PMT after 0.2141316 seconds.
[2019-07-22 17:33:56,946] [2105113] [12 ] [INFO ] - subch:0 SendPmt:7036 7036 FFFFFFFF 1D
[2019-07-22 17:33:56,946] [2105113] [12 ] [DEBUG] - Decode pmt
[2019-07-22 17:33:56,947] [2105114] [12 ] [DEBUG] - Set descriptor data with length 3
[2019-07-22 17:33:56,948] [2105115] [12 ] [DEBUG] - Set descriptor data with length 3
[2019-07-22 17:33:56,951] [2105118] [12 ] [DEBUG] - PROBLEM : descriptor lengths dont match 6 9
[2019-07-22 17:33:56,952] [2105119] [12 ] [INFO ] - subch:0 SendPMT: Channel is FTA, nothing to do.
[2019-07-22 17:33:56,953] [2105120] [12 ] [DEBUG] - subch:0 SetMpegPidMapping
[2019-07-22 17:33:56,953] [2105120] [12 ] [DEBUG] - subch:0 pid:191 pcr
[2019-07-22 17:33:56,954] [2105121] [12 ] [DEBUG] - subch:0 pid:258 pmt
[2019-07-22 17:33:56,955] [2105122] [12 ] [DEBUG] - subch:0 pid:191 video type:MPEG-2
[2019-07-22 17:33:56,955] [2105122] [12 ] [DEBUG] - subch:0 map pid:191 video type:MPEG-2
[2019-07-22 17:33:56,956] [2105123] [12 ] [DEBUG] - subch:0 pid:192 audio lang:deu type:MPEG-1
[2019-07-22 17:33:56,956] [2105123] [12 ] [DEBUG] - subch:0 map pid:192 audio lang:deu type:MPEG-1[/collapse]

(alternative PIDs)
[collapse][2019-07-22 17:34:00,095] [2108261] [28 ] [DEBUG] - subch:0 OnPMTReceived() pmt:258 ran:True dynamic:True
[2019-07-22 17:34:00,096] [2108262] [PMT update] [INFO ] - subch:0 SendPmt:7036 7036 1D 1C
[2019-07-22 17:34:00,097] [2108263] [PMT update] [DEBUG] - Decode pmt
[2019-07-22 17:34:00,098] [2108264] [PMT update] [DEBUG] - Set descriptor data with length 3
[2019-07-22 17:34:00,098] [2108264] [PMT update] [DEBUG] - Set descriptor data with length 3
[2019-07-22 17:34:00,099] [2108265] [PMT update] [DEBUG] - PROBLEM : descriptor lengths dont match 6 9
[2019-07-22 17:34:00,099] [2108265] [PMT update] [INFO ] - subch:0 SendPMT: Channel is FTA, nothing to do.
[2019-07-22 17:34:00,100] [2108266] [PMT update] [DEBUG] - subch:0 SetMpegPidMapping
[2019-07-22 17:34:00,100] [2108266] [PMT update] [DEBUG] - subch:0 pid:1F5 pcr
[2019-07-22 17:34:00,101] [2108267] [PMT update] [DEBUG] - subch:0 pid:258 pmt
[2019-07-22 17:34:00,101] [2108267] [PMT update] [DEBUG] - subch:0 pid:1F5 video type:MPEG-2
[2019-07-22 17:34:00,101] [2108267] [PMT update] [DEBUG] - subch:0 map pid:1F5 video type:MPEG-2
[2019-07-22 17:34:00,102] [2108268] [PMT update] [DEBUG] - subch:0 pid:1F6 audio lang:deu type:MPEG-1
[2019-07-22 17:34:00,102] [2108268] [PMT update] [DEBUG] - subch:0 map pid:1F6 audio type:MPEG-1
[/collapse]

Note these values are hexadecimal. Convert to decimal by Google [for example] "0x191 to decimal" => 401.

I hope this is clear.

Sorry again that I don't have a better suggestion.

this special case only working for test-r

but not if one/two service had similar and no one knowing the pids for video audio