I am looking as how to get the crash log for my receiver app which is on chromecast device.
I have a custom sender app and a receiver app. I am using player to fetch the content URL from sender app and playback the content in receiver app. After some time of playback or data streaming between sender and receiver app, suddenly I observe that Receiver app crashes and sends TCP packet with RST flag enabled(which means receiver app is closed the connection). I tried to check the debug logging in debugger tool, but as the Receiver app is terminated due to crash, the debugger tool is disconnected.
I want to know how to get the crash log and the error log of our receiver app running on chromecast device in this scenario?
You can try debugging for a Chromecast device, where you navigate to your receiver's IP address on port 9222.
http://:9222
The logs will still be available in 9222 and you can see them.
Related
As we know the messages in buffer shall be still sent out even after socket closed. this is usefull, but there's a use case that we want to wait the messages is sent and acked by peer,
e.g. in embeded device, a firmware upgrade function in web ui. after upgrade done a message is sent to web ui then reboot the device. we want the message is sent and acked, or reboot may drop messages. then web ui lost reply.
so, is there a way in linux wait a socket (closed or not closed) sent out and acked all messages ?
The use case is to receive device connected event as soon as the device is connected to the iothub.
There is a device connected/disconnected event that can be captured and routed to eventhub/servicebus/eventgrid, but, this event isn’t triggered in Amqp if the message is sent by .net program i.e it is inconsistent.
Is there any mechanism available to get the recent device connected event in Iothub! Or heartbeat pattern is the only mechanism available or is most efficient way?
Your understanding is correct. Suggestion is to use the Device heartbeat pattern.
The IoT Hub identity registry contains a field called connectionState. Only use the connectionState field during development and debugging. IoT solutions should not query the field at run time. For example, do not query the connectionState field to check if a device is connected before you send a cloud-to-device message or an SMS. We recommend subscribing to the device disconnected event on Event Grid to get alerts and monitor the device connection state. Use this tutorial to learn how to integrate Device Connected and Device Disconnected events from IoT Hub in your IoT solution.
If your IoT solution needs to know if a device is connected, you can implement the heartbeat pattern. In the heartbeat pattern, the device sends device-to-cloud messages at least once every fixed amount of time (for example, at least once every hour). Therefore, even if a device does not have any data to send, it still sends an empty device-to-cloud message (usually with a property that identifies it as a heartbeat). On the service side, the solution maintains a map with the last heartbeat received for each device. If the solution does not receive a heartbeat message within the expected time from the device, it assumes that there is a problem with the device.
Google Chromecast supports external control, such as play, pause, next, previous using both the Google Home app and an Infrared remote (over HDMI CEC).
How can these events be captured in a custom media receiver (using the CAF Receiver API) when the receiver has no media playing?
When no media is playing, the receiver is in IDLE state - that means that a sender is connected and the receiver app is loaded and running, but there is currently no playback, paused playback or buffering operation ongoing.
The messages that can now be intercepted/observed by the receiver are basically the same regardless if they have been issued by a sender app, Google home/assistant or CEC - and you can process them the same way.
If you want to implement different behavior depending on the device that send the message (or track that maybe), you can have a look at the customData section - you can set up your sender app to include some data into that, but you have no influence on how a Google Home / Google Assistant or CEC issued messages look like: CustomData will be empty here.
I have the following situation in Azure IOT Hub:
Script sends message to device queue. Listening with device explorer: Succes
Script listens for message to device queue. Sending with device explorer: Succes
This problem arises:
Script listens for message to device queue. Other script sends message to device queue: Listener does not receive the message.
So, it works well using the device explorer tool. But with the scripts only, the listener does not receive.
I hope someone might be able to help me with this issue.
There might be two possible problems on your side:
a) Device Explorer shows messages only from one device. If you have two separate device clients, you have to select another one.
b) But it's possible that you send and receive on two separate scripts with one deviceId (clientId) - it might be the problem.
The use case is that a user starts playback from their iPhone, lets say, and then picks up their iPad (both running my app) and wants to contect to and control the running video from this other iOS device.
On iOS, I do not see any way to determine if there is a instance of my receiver app already running on the Google ChromeCast device. Once I create my session it seems the only thing I can do is to attach a new protocol message stream, which interrupts whatever might be playing already.
It this suppose to be handled in the iOS client side Framework, perhaps there is some coding I need to do in the HTML receiver app?
Thanks.
There is a way outside the API to determine if an app is running. Do a HTTP GET on the apps URL for the ChromeCast IP address: http://192.168.0.x:8008/apps/
If the HTTP response is 200, nothing is running. If the HTTP response is 204, then an app is running and the HTTP response would be redirected to a URL like: http://192.168.0.x:8008/apps/GoogleMusic
Which tells you which app is running.
Interestingly, Google Play Music cannot be controlled by 2 devices simultaneously, but YouTube can. I suspect Play Music is using RAMP which is what the Cast SDK does for media streams. YouTube could be using a proprietary message stream to control the media playback. So you might have to do the same if you want to have the an app on a device controlled by multiple sender apps.
One method is to check the playStatus after you start your session and before you initiate a loadMedia(). If your app is already running - it should return a non-nil (ie. IDLE, PLAYING, ...) result.