Fixed Kodi Media Browsing#165819
Conversation
|
Hey there @OnFreund, mind taking a look at this pull request as it has been labeled with an integration ( Code owner commandsCode owners of
|
There was a problem hiding this comment.
Pull request overview
This PR fixes media browsing behavior in the Kodi integration by ensuring the BrowseMedia.can_play field is evaluated as a proper boolean instead of sometimes becoming a string.
Changes:
- Adjust
can_playcalculation in Kodi media browsing to always produce a boolean value.
| media_content_type=search_type, | ||
| title=title, | ||
| can_play=search_type in PLAYABLE_MEDIA_TYPES and search_id, | ||
| can_play=search_type in PLAYABLE_MEDIA_TYPES and search_id is not None and search_id != "", |
| media_content_type=search_type, | ||
| title=title, | ||
| can_play=search_type in PLAYABLE_MEDIA_TYPES and search_id, | ||
| can_play=search_type in PLAYABLE_MEDIA_TYPES and search_id is not None and search_id != "", |
edenhaus
left a comment
There was a problem hiding this comment.
Please fix the CI and make sure it's passing
|
Please take a look at the requested changes, and use the Ready for review button when you are done, thanks 👍 |
There was a problem hiding this comment.
Pull request overview
Fixes Kodi media browsing by ensuring the BrowseMedia.can_play field is evaluated as a proper boolean (instead of potentially becoming a non-bool truthy value).
Changes:
- Update Kodi browse-media response building to compute
can_playas a boolean expression.
| media_content_type=search_type, | ||
| title=title, | ||
| can_play=search_type in PLAYABLE_MEDIA_TYPES and search_id, | ||
| can_play=search_type in PLAYABLE_MEDIA_TYPES and search_id is not None and search_id != "", |
There was a problem hiding this comment.
Align the PR description/checklist with the actual diff (either include the mentioned Roku fix/tests, or update the description to only reference the Kodi change).
joostlek
left a comment
There was a problem hiding this comment.
The CI is still failing, can you take a look?
|
Euh the CI wasn't complaining about |
Yes I know that but I prefered to reproduce the same code as other integrations (jelly for example) |
Finally I changed the code to stick to other media browsing implementations such as jellyfin |
| title=title, | ||
| can_play=search_type in PLAYABLE_MEDIA_TYPES and search_id, | ||
| can_play=bool(search_type in PLAYABLE_MEDIA_TYPES and search_id), |
There was a problem hiding this comment.
Clarify whether this PR is intentionally Kodi-only, since the same can_play=... and search_id pattern (returning a str) still exists in homeassistant/components/roku/browse_media.py and may need a separate fix/PR.
There was a problem hiding this comment.
The origin of this PR : in some situations, can_play evaluates to a string instead of a boolean. This PR prevents this by forcing the type to boolean
Proposed change
This is a fix for Kodi media browsing : the
can_playflag was evaluated as a string with the previous expression instead of a boolean.Maybe other components with browsing support have copied/paste this bug : I have found another one -> Roku
Type of change
Additional information
Checklist
ruff format homeassistant tests)If user exposed functionality or configuration variables are added/changed:
If the code communicates with devices, web services, or third-party tools:
Updated and included derived files by running:
python3 -m script.hassfest.requirements_all.txt.Updated by running
python3 -m script.gen_requirements_all.To help with the load of incoming pull requests: