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).
Related
I have an unpublished custom receiver app, and I am unable to cast to it from my web player sender app in chrome. I do get the receiver "available" message upon initialization of cast api, but when I click on the cast button in player and select the chromecast device from drop down menu in extension, the TV screen goes black and few seconds later I get onError method called with following error:
{code: "channel_error", description: "Error: Timeout", details: null}
The casting works fine when using default media receiver. Also, I do not see any network traffic coming from chromecast device in my server console log, which means that chromecast is not fetching the receiver application.
I made sure of the following:
The Chromecast dongle is registered as Cast Receiver device in Cast
Developer console.
My macbook has NodeJS server running to serve the
receiver application and the "Receiver Application URL" in cast
developer console is correctly pointing to server running on my
macbook.
The chromecast and my macbook both are on same network, with
valid 192.168.x.x IP addresses.
I found another thread discussing this error Chromecast sample sender application CastHelloText-chrome ends with error when trying to get session, but the suggestions provided there dont seem to apply to my situation.
I was able to resolve this particular error by restarting the chromecast device. I tried it on two separate occasions and both times the issue went away once the device was restarted. I can't explain how it worked, but it did the job. If someone can explain what is the cause of this particular error and why restarting fixes it, I will accept that answer.
I already read this (Can not access Chromecast receiver debug page by http://chromecastIP:9222?) and similar threads. I am not sure if they are outdated from the pre-release SDK but at any rate here is my tale of woe...
Chrome is giving me these details when attempting to browse my Chromecast IP:
Google Chrome's connection attempt to 192.168.2.78 was rejected. The website may be down, or your network may not be properly configured.
NOTE - I did remember to add the :9222 suffix
My Chromecast device appears to be whitelisted.
From the cast.google.com/publish/#/overview console page it lists both my Application ID and my Serial #.
The App ID is fine if that even matters as I have successfully run many github sample apps using it.
The serial # I entered is correct as I was meticulous reading it with a magnifying glass off the device (felt like Sherlock Holmes).
The status for my Serial # lists, "Ready for testing"
I did this all after a factory reset today.
I then unplugged the USB cable from the Chromecast dongle and counted to 30 and reseated it.
This is exactly what the instructions on the cast developer site instructed.
I have seen some posts where people say it could take hours but that seems to be pre-release posts where there were alot of issues.
So basically I ready every stackoverflow post on this, followed all instructions, everything looks good and works right (I can cast no problem) even with my own code for both Android & Web but I just cannot browse, http://:9222
I just get err_connection_refused
I can ping it without the :9222 suffix as well.
Since it says, "Ready for testing" I assume I do not have to wait for Google to process this.
Finally I was triple sure to check, "Send Serial # to Google for updates" in installation app.
Can anyone provide guidance please?
Thanks!!
These are the instructions I followed (meticulously I might add)
https://developers.google.com/cast/docs/registration
To register your Google Cast device:
Sign in to the Google Cast SDK Developer Console.
From either the Overview page or Devices page, click Add New Device.
Enter the serial number of your device. ( I TRIPLE CHECKED THIS)
The serial number on a Chromecast is a 12-digit alphanumeric string, laser-etched (not printed) on the back of the device and begins with a 3, 4 or 5. It may be easier to read if you take a picture of the serial number then enlarge it. The serial number is also printed on the package.
Enter a description, and click OK.
This is just a friendly name for your device (it does not need to match the name you gave to the device during user setup).
Wait fifteen minutes before continuing. (I waited till it says, "Ready for testing")
Once registration is complete, the Status for the device will read "Ready for Testing."
In the Chromecast setup app, select your Chromecast and check the box, Send this Chromecast's serial number when checking for updates.
Restart your Chromecast by disconnecting the USB cable from the device, then reconnecting it.
After restarting the device, check whether you can access http://:9222 from a chrome browser on the same WiFi network.
** AFTER ALL THIS STILL GET ERR CONNECTION REFUSED **
Once you can access the URL, your device is ready for development. If you can't access the URL, check the serial number you entered in step 3, above.
Please read the documentation here (search for Debugging). The Registration page will be updated later today or tomorrow to remove item number 8 at the bottom of the page. In short, you need to have your own application running on the Chromecast device to be able to attach your chrome debugger to it. Also see this post.
I have two iOS devices; one is sending beacons using peripheralManager, beaconPeripheralData, etc. The second, a receiver device, is currently scanning for regions and beacons of the same UUID using didEnterRegion, didRangeBeacons, etc.
Is there any method or callback for the -broadcaster- side to know if the scanning side has entered its region or received its beacon? Something similar to "didEnterRegion", but for the broadcaster.
Thanks.
Simple answer - no.
Not so simple answer - clients don't connect to the "broadcaster", they just listen for advertisements, so there is no way for "broadcasters" to identify who has "heard" them.
Vladimir's answer is correct. However, you can set up your "broadcaster" (advertiser, in BLE terms) to also listen for other BLE devices that are advertising services, or sending out iBeacon broadcasts.
Then you would set up the remote receiving iOS app to execute special code when it gets a didEnterRegion call. That code could start advertising a pre-defined BLE service that your "broadcaster" is already listening for, and the two devices could then enter into a 2-way BLE conversation.
More simply, your receiver could simply start sending it's own beacon signal when it gets a didEnterRegion message as a result of detecting the "broadcaster"'s beacon signal.
You can do this is you just use CoreBluetooth CBCentral and CBPeripheral rather than trying to be an iBeacon (which encourages non-connectability).
While there is no standard way for a broadcaster or peripheral to automatically know who's found it you can do this by having an service and characteristic on your iOS peripheral. You could have your central scan for a particular UUID and when it finds it, have it connect and write an attribute, and then disconnect. This would give your peripheral information about who saw it.
This avoids the issue where you try to toggle between one device being a broadcaster and a central, since you can't be both of them at the same time.
I have completed Google's form to enable my device to be whitelisted and have been provided with an AppID.
I have followed the procedures outlined here to try and debug the device with no success:
https://developers.google.com/cast/developing_your_receiver#debugging
I am able to ping my device by the IP, but connecting to port 9222 results in failure. Telnet to that port is also unsuccessful.
Does anyone know why this might not be working? I must be missing something simple.
The problem was that my Chromecast device was not sending the serial number to Google.
I was able to get it to work by enabling the sending of the devices serial number in the Windows settings utility (changing this setting in the android app didn't seem to work). After changing the setting I rebooted the device, and now I can connect on port 9222. I am not sure why this isn't in the developer walk through... or maybe I missed it?
I only got this option when I opened "Options" in the Google Cast Extension inside Chrome and then clicked on the blue icon about a dozen times very quickly. Suddenly a new option appeared at the bottom where I could enter the hostname of my whitelisted URL:
I also made sure that "send serial number" was enabled in the Chromecast.app (and make sure to reboot!)
Now, I am able to hit port 9222 in a browser and can see my app at http://{my-chromcast-ip}:9222/. I can use dev tools in Chrome to debug, refresh the page, inspect on-screen elements, etc.
Something else that I haven't seen others mention yet. If you're going to the right IP and getting the link to remote debugging, but you don't see your source, elements, etc. It could be blocked by security settings. This stumped me for a while until I noticed a small shield icon in my url bar. Click on this and allow it to load sources. Once I did that everything populated as expected.
I struggled a bit with this one. I think some things might have changed with the last firmware update on the Chromecast. I could connect to port 9222 after I did the following:
Registered the custom receiver and host it on the outside of my network (on Google Drive:
https://support.google.com/drive/answer/2881970?hl=en)
Launch the receiver. I used the Chromecast example https://github.com/googlecast/CastHelloText-chrome
Make sure the app ID in chromehellotext.html is the one registered on your account.
When After this, I could connect to the debugging port.
The port is only open when your custom receiver is running on the Chromecast.
I also might be useful to enable debugging on the chrome extension. This will show what's going on between the Chromecast and sender:
https://developers.google.com/cast/docs/chrome_sender
I realize that this is an ancient question, however my answer might help people searching in the future.
Simply rebooting the Chromecast after having set up my details in the Cast console helped for me.
You must cast to a custom receiver first (at least once) before trying to access the IP with debug port. Otherwise debugging won't be enabled.
My application communicates with several GSM electric controllers, that means that I have to send anywhere between one to twenty messages every few hours. right now I'm working with HUAWEI Mobile Connect - 3G. it is a USB device that uses a comm port for the pc communication and I'm using GSMComm to send messages and read/delete messages from the device.
Every two seconds I'm checking the device's storage, and if there is any message, I will then read it and store it locally and then clear the device's storage. I'm not sure if I'm working correctly, but it seems to me as if it is a very unreliable device:
Every time I boot my machine, I must remove the device from the USB or my machine will get stuck at the BIOS start up screen (or whatever the name is).
Very frequently the comm port can become unavailable for some reason. I have to close and re open the port, and at times that may not even help.
In the production machine of my client, when he uses one of his software's that utilize the first comm port, he will get a warning message from the software about problems in the port if the device is plugged in (the device port is around 28 or something).
If you've been using a device which you consider reliable, or have been working with the same device as I work with, or you just think that I'm doing it wrong, I'd like to get an advice from you.
Thanks.
This sounds like an issue with your modem. Have you tried any other models? Consumer USB models tend to be unreliable. The preferred method, though slightly more expensive, is using a commercial grade modem in situations where you need the reliability.
Some modems to look at:
Wavecom Fastrack
Sierra Wireless Airlink
These use a serial port or ethernet to communicate with the host which is far more reliable. Serial ports may not be available in your particular situation but even a USB to RS232 adapter will be more reliable.
One further option is to use a smartphone, there are several applications that you can act as a gateway through HTTP.
SMS Gateway for Android:
https://market.android.com/details?id=eu.apksoft.android.smsgateway&hl=en
i have not used this method, but it seems like some people are having luck with it. it may not be any more reliable then your USB modem though.
Hope that answers your question.
I have used WaveCom's modem for sending messages in bulks and found it to be reliable. One difference though, in my implementation was i used Kannel as an SMSC, so my queues were automatically handled by Kannel. But sending multiple requests like 40+ per minute didnt pose any problems for me.
Hope this helps.