I have multiple monitors connected to my main monitor, if any of the connected monitor goes off(power off state). It should be notified. I have tried with several messages like WM_DEVICECHANGE, WM_POWERBROADCAST and WM_DEVMODECHANGE. But nothing seemed to work, because WM_DEVICECHANGE notifies when the connection is removed/connected and WM_POWERBROADCAST also didn't seem to work, when my second monitor goes to power off state.
Related
Steps:
Connected wired headset and Bluetooth headset.
Receive an incoming call to the device where WHS and BTHS are connected.
Accept the call. Switch to different output devices like Speaker, WHS, BTHS.
I am using android 11. When call in progress, we can select different output devices such as Speaker, WHS, and BTHS. Is there any intent or callback to notify voice call routed to speaker/wired headset/Bluetooth headset?
On hot plug connection/disconnection, events will have listened. Based on the connection/disconnection event, we can perform our operation. But on the soft switch(selecting output devices from call application when call in progress), do we get any indication that output device for voice call stream got changed, so other applications can listen to intent/callback to carry out my customized operation.
Working on USB Modem, Used RAS interface for dial/hangup.
For connection used RASDial() and for disconnection used RASHangUp() API's.
After successful connection waiting for the disconnect event using function RasConnectionNotification(rasHandle, event, RASCN_Disconnection), event notifies successfully when disconnect happens.
I need to find out the reason of disconnection, if it disconnect due to lost network signal then put my application on auto reconnect.
Is there any method or API which provides the reason for disconnection like LINK_FAILED, USER_SWITCH, USER_LOGOFF ... etc.
RasGetConnectStatus API can give you the reason in RASCONNSTATUS.dwError field.
I have a queue for which the reader consumes messages under sycpoint and it ended abruptly. This caused 2 messages left in Uncommitted state. so the "msgage" property keeps increasing for the message and "uncom" property of queue remains same as 2, even though we restarted the consumer application and no long running UOW.
Anyway we can reset these properties without restarting MQ?
Presuming your application is connecting in client mode (over TCP) I expect that although your application has gone away, from the queue manager's point of view it is still active.
When the network socket the application opened closes, then MQ should roll back the 2 messages so they're eligible for consumption by another application.
The network socket will close when the operating system eventually notices the remote end of the TCP connection is unresponsive - this triggers a 'connection reset by peer' type socket closure. It's the operating system the queue manager is running on which will do this, not the remote one.
Some operating systems can take hours to notice a duff socket in their default configuration. Look into 'TCP keepalive' settings on your operating system to tune how long this takes.
I recently switched my Chromecast app to a custom receiver. I'm still using the Cast Companion Library. The custom receiver is basically based on this https://github.com/googlecast/cast-custom-receiver/blob/master/sample_media_receiver.html the only changes are the adding of a logo and loading screen and commenting out this line appConfig.maxInactivity = 6000; although at first I didn't have it commented out and still had the same issue.
Anyways the issue is pretty simple and only happens to a few people. It happens to me with one of my test devices, not all and not always. Basically I start streaming a video and it is all fine, then the device screen goes off, when I turn it off again the app has disconnected from the Chromecast. I do not have wifi set to turn off when sleeping, and all of the users who have complained about this claim their devices also don't have that setting turned on.
It could be a coincidence that this happened when I switched to the custom receiver but I just wanted to make sure there wasn't something I needed to add to my custom receiver to tell the CCL code to stay connected?
Thanks.
I faced similar issue today. Main cause for this behaviour is that as soon as the sender (in your case phone) is locked (sleep mode) then senderDisconnected event is fired on the receiver side. And if you check the event.reason, it will be unknow, so you could probably check for the reason, if it unknown then dont stop the playback on receiver (window.close).
When the sender itself disconnects, event.reason is "disconnected_from_sender".
I hope this helps.
It has nothing to do with maxInactivity.
The policy for disconnecting wifi when your phone goes to sleep does depend on the brand and vendor . Currently, the Cast SDK holds a lock to keep the wifi connected as long as there is a cast connection but even that is not a 100% guarantee to work for all phones/models/vendors/.... This has nothing to do with your receiver. The proper solution is not to try to fight against the wifi disconnect when phone goes to sleep, instead you have to consider adding some logic to recover the cast connectivity when phone wakes up and wifi connectivity is re-established (register a broadcast receiver to listen for wifi connectivity changes).
I have a Windows XP system with 2 NIC cards. 1 NIC card is used to just used to set some configuration to LabView. The other NIC is used to pump data real-time to another device using tcpip (not able to use UDP). The issue is that it cannot stop and rest for 125ms, once this happens we have problems.
The network we are on is pretty isolated, so nothing much is going on on the other NIC. Using Wireshark I can not correlate any event that happens on the other NIC, and do not see anything else with the Windows event logs.
Any ideas?
Is there a way to set the priority so that the real-time NIC doesn't get interrupted?
If nothing is going on, on the other NIC, and nothing is seen in the Windows event logs, what else could be going on to interrupt the real-time NIC?