New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Do not automatically start worker thread and connect in Chromecast constructor #271
Conversation
When do we want to connect right away? Could we just do the connect call only inside the discover methods and not do any I/O in the constructor? (which shouldn't do I/O really) |
@balloob sure, but I guess this library is used by many people. Do you think it's ok to change the behaviour? Edit: With current behavior, the constructor throws |
Ah right, now I remember the usage. It is so that when you instantiate, you know if it works or not. I suggest we make this a breaking change and a major bump. Require people to manually call |
|
ah good one. Maybe we can do that? |
I'm not sure what that means in this case, do you just suggest ro remove this: What may be useful though is to make the change in this PR, i.e. |
Yes, let's make it the only supported mode. We will do a major version bump. We should make sure we update our examples to show how existing code can be updated |
README.rst
Outdated
@@ -39,6 +39,8 @@ How to use | |||
['Dev', 'Living Room', 'Den', 'Bedroom'] | |||
|
|||
>> cast = next(cc for cc in chromecasts if cc.device.friendly_name == "Living Room") | |||
>> # Start worker thread | |||
>> cast.start() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thinking here, do you think that we can automatically call start
inside wait
, if not started yet ? That way it's a less breaking change.
Could you write a message describing the breaking change for the release post? |
Sure, where do I write it? |
As a comment here :D |
OK, I updated the issue description to be clearer, I think it can be used for the release post. |
Released as 3.0.0 |
Struggling a bit getting 3.0 working again, for now going to revert to 2.4 or 2.5 Running through the simple example on the landing page I get the below:
Calling cast.wait() or cast.connect() Traceback (most recent call last): Calling cast.start() results in the below error: Traceback (most recent call last):
pychromecast.error.NotConnected: Chromecast 10.1.1.12:8009 is connecting... |
Do not automatically start worker thread or connect in
Chromecast
constructor.This is a breaking change, and the user will now have to call either of:
Chromecast.start()
: Start the worker thread and connect to the chromecast device. Connection status will be reported through the listener registered inChromecast.register_connection_listener
.Chromecast.wait()
: Wait for connection, this will also start the worker thread if it has not been started.Chromecast.connect()
: Connect to the chromecast. This must only be called if the worker thread has not been started. Connection status will be reported through the listener registered inChromecast.register_connection_listener
.Background:
The automatic connect in the constructor meant that the constructor would hang forever if the number of retries was unlimited and the chromecast could not be found.
It was also a bit unnatural to start the worker thread in the constructor.