You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently there is no way for minisatip to distinguish "unimportant" adapter usage (such as EPG scanning, mux scanning) from actual adapter usage (streaming a channel). tvheadend has an option to send a "weight" parameter to the SAT>IP server, which can be used to distinguish the nature of the stream.
Currently I have to "proxy" minisatip instances with a tvheadend instance just to get this feature. It would be great if we could implement it in minisatip even though it's not part of the SAT>IP specification.
The text was updated successfully, but these errors were encountered:
Please, could you explain more about this? What's the paremeter and how it works. Perhaps I'll try to implement it.
Perhaps the same could be used for my request #908
The idea comes from tvheadend, where each "subscription" has a "weight". This means a new subscription can take presedence over an existing one if its weight is higher. This is useful to de-prioritize e.g. EPG scans.
I've since worked around this in a different way so this is in no way critical anymore.
Thank you for the explanation. Perhaps this could be supported using my proposal described in #1052 ?
Anyway, could you please share a request with the subscription weight using TVHE? I want to see how it pases the data over the SAT>IP request. Or it is only supported using other protocols?
Currently there is no way for minisatip to distinguish "unimportant" adapter usage (such as EPG scanning, mux scanning) from actual adapter usage (streaming a channel). tvheadend has an option to send a "weight" parameter to the SAT>IP server, which can be used to distinguish the nature of the stream.
Currently I have to "proxy" minisatip instances with a tvheadend instance just to get this feature. It would be great if we could implement it in minisatip even though it's not part of the SAT>IP specification.
The text was updated successfully, but these errors were encountered: