These ones work, in that the closure passed to webrtcbin.connect()
gets called -
notify::connection-state
notify::signaling-state
but these ones seem not to
notify::ice-connection-state
notify::sctp-transport
…bug?
These ones work, in that the closure passed to webrtcbin.connect()
gets called -
notify::connection-state
notify::signaling-state
but these ones seem not to
notify::ice-connection-state
notify::sctp-transport
…bug?
ice-connection-state
should also be notified. If that’s not the case then you found a bug that should be reported in GitLab, together with a full debug log and ideally a testcase to reproduce the problem.
sctp-transport
is not notified but when/why do you expect it to be notified? Maybe that’s just a missing feature that could be added, or there’s another way for doing what you’re trying to do.
Will do, I think I need to make a minimal system for test cases…
With sctp-transport
I was hoping to watch any change to its state
field to see if that would shed any light on the SCTP connection going into an error state.
You should be able to get the sctp-transport
once it’s created and then connect to its notify::state
signal. Is the problem that you don’t know when it would be created?
Thanks, no I just didn’t realise it had a notify::state
signal
…so, should all readable properties of a struct that implements ObjectExt
be notifiable?
Theoretically all readable GObject properties should be notified whenever they change, yes. That includes sctp-transport
too.
Some are not notified because it’s forgotten (which would be a bug), or because doing so would be too expensive (they’re changing too often).