home
products
contribute
download
documentation
forum
Home
Forums
New posts
Search forums
What's new
New posts
All posts
Latest activity
Members
Registered members
Current visitors
Donate
Log in
Register
What's new
Search
Search
Search titles only
By:
New posts
Search forums
Search titles only
By:
Menu
Log in
Register
Navigation
Install the app
Install
More options
Contact us
Close Menu
Forums
MediaPortal 2
General
Dynamic PMT not working with DD Octopus
Contact us
RSS
JavaScript is disabled. For a better experience, please enable JavaScript in your browser before proceeding.
You are using an out of date browser. It may not display this or other websites correctly.
You should upgrade or use an
alternative browser
.
Reply to thread
Message
<blockquote data-quote="mm1352000" data-source="post: 1260851" data-attributes="member: 82144"><p>Indeed.</p><p></p><p></p><p>Ahhh, now I understand.</p><p></p><p>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.</p><p></p><p>So you're right - the situation you've described is quite different and unrelated to the purpose of the patch.</p><p></p><p></p><p>Indeed.</p><p></p><p>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:</p><p>[2019-07-22 17:38:12,140] [2360306] [34 ] [DEBUG] - dvbip: Tune<img src="data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7" class="smilie smilie--sprite smilie--sprite8" alt=":D" title="Big Grin :D" loading="lazy" data-shortname=":D" />VBIP: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&<strong>pids=0,600,501,0,502,501,18,17,16</strong></p><p></p><p>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:</p><ul> <li data-xf-list-type="ul">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.</li> <li data-xf-list-type="ul">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.</li> </ul><p>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.</p><p></p><p>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.</p></blockquote><p></p>
[QUOTE="mm1352000, post: 1260851, member: 82144"] Indeed. 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. 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: Tune:DVBIP: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&[B]pids=0,600,501,0,502,501,18,17,16[/B] 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: [LIST] [*]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. [/LIST] 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. [/QUOTE]
Insert quotes…
Verification
Post reply
Forums
MediaPortal 2
General
Dynamic PMT not working with DD Octopus
Contact us
RSS
Top
Bottom