Skip to content
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

[lgwebos] mediaPlayer and mediaStop channels state not updated #7356

Closed
lolodomo opened this issue Apr 13, 2020 · 11 comments
Closed

[lgwebos] mediaPlayer and mediaStop channels state not updated #7356

lolodomo opened this issue Apr 13, 2020 · 11 comments
Labels
bug An unexpected problem or unintended behavior of an add-on won't fix Invalid Issues and requests that do not fit the specified add-on

Comments

@lolodomo
Copy link
Contributor

When handling a channel command, the channel state is not updated.

@lolodomo lolodomo added the bug An unexpected problem or unintended behavior of an add-on label Apr 13, 2020
@lolodomo
Copy link
Contributor Author

lolodomo commented Apr 13, 2020

PR #7355 is fixing the case of the power channel.
Another PR might be necessary for other channels.

@lolodomo
Copy link
Contributor Author

lolodomo commented Apr 13, 2020

After first checking, I was wrong, it is working well at least for the following channels: volume, mute channel and appLauncher. It is due to the subscriptions used for these channels.

@lolodomo
Copy link
Contributor Author

It also depends on whether autoupdate="false" is set or not on the item.
I think only the channels power, mediaPlayer and mediaStop require a fix.

@sprehn
Copy link
Contributor

sprehn commented Apr 13, 2020

let us not discuss the power channel in too many threads.

MediaControlPlayer see comment: // TODO: playstatesubscription
I have not found out how to listen for those play states yet in the api

@lolodomo
Copy link
Contributor Author

For mediaPlayer, I tried few commands to get the player status but with no success.
So we have no known way to detect player commands from external devices (like TV remote control).
At least, we could try to maintain a coherent state between mediaPlayer and mediaStop channels, when used only from openHAB. This is better than nothing, but of course not perfect.

@lolodomo lolodomo changed the title [lgwebos] Channel state not updated when handling a command [lgwebos] mediaPlayer and mediaStop channels state not updated Apr 17, 2020
@koshisan
Copy link

koshisan commented Jun 30, 2020

Is there any hope this will be fixed? I would love to get a reliable play/pause state from the tv to control the living room lights...

Wasn't the playstate subscription added to the original SDK? ConnectSDK/Connect-SDK-iOS@5d1695a (Android Link doesn't seem to work...)

@lolodomo
Copy link
Contributor Author

lolodomo commented Jul 5, 2020

@sprehn : do you see something in the provided link that could help identify the URL to subscribe to?

@sprehn
Copy link
Contributor

sprehn commented Jul 8, 2020

hi, no I don't find it in there and this is just the error handling piece. Connect SDK was trying to implement a universal abstraction, not only for WebOS, but also for ChromeCast, AppleTV etc. - so it does not mean this works in WebOS.
@lolodomo you are correct, if we know which url to subscribe to, we could do it. But I don't.

@lolodomo lolodomo added the won't fix Invalid Issues and requests that do not fit the specified add-on label Jul 25, 2020
@lolodomo
Copy link
Contributor Author

As there is no identified solution to determine the playback status, I mark this issue with the tag "won't fix".

@lolodomo
Copy link
Contributor Author

lolodomo commented Aug 1, 2021

... and I even close it.

@lolodomo lolodomo closed this as completed Aug 1, 2021
@jimtng
Copy link
Contributor

jimtng commented Nov 24, 2021

Any more development on this? It's a shame that this isn't currently possible.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug An unexpected problem or unintended behavior of an add-on won't fix Invalid Issues and requests that do not fit the specified add-on
Projects
None yet
Development

No branches or pull requests

4 participants