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

Kodi: media content type issue #6989

Closed
Molodax opened this issue Apr 8, 2017 · 16 comments · Fixed by #13204
Closed

Kodi: media content type issue #6989

Molodax opened this issue Apr 8, 2017 · 16 comments · Fixed by #13204

Comments

@Molodax
Copy link

Molodax commented Apr 8, 2017

Make sure you are running the latest version of Home Assistant before reporting an issue.

You should only file an issue if you found a bug. Feature and enhancement requests should go in the Feature Requests section of our community forum:

Home Assistant release (hass --version):
Since 0.41.0

Python release (python3 --version):
3.4.2

Component/platform:
Kodi

Description of problem:
After implementing PR #6645 there is no media_type_content while video is playing.
My automation doesn't work after upgrading to HASS 0.41 and later

Expected:
Be able to distinguish media type content using attributes.media_content_type

Problem-relevant configuration.yaml entries and steps to reproduce:

- alias: 'Media player playing'
    trigger:
      - platform: state
        entity_id: media_player.kodi
        from: 'idle'
        to: 'playing'
    condition:
      - condition: state
        entity_id: sun.sun
        state: 'below_horizon'
      - condition: state
        entity_id: group.ceiling
        state: 'on'
      - condition: template
        value_template: '{{ states.media_player.kodi.attributes.media_content_type == "video" }}'
    action:
        service: scene.turn_on
        entity_id: scene.cinema_time

Traceback (if applicable):

Additional info:
Media content type is available while audio is playing.

@point-4ward
Copy link
Contributor

point-4ward commented Apr 14, 2017

I noticed this the other day when my lights failed to dim. For some reason the media_content_type attribute has now changed to show the 'type' of video that is playing. Rather than "video" it now displays "tvshow" or "movie".

You need to change the conditions in your automation(s) to:

- alias: 'Media player playing'
    trigger:
      - platform: state
        entity_id: media_player.kodi
        from: 'idle'
        to: 'playing'
    condition:
      - condition: state
        entity_id: sun.sun
        state: 'below_horizon'
      - condition: state
        entity_id: group.ceiling
        state: 'on'
      - condition: or
        conditions:
        - condition: template
          value_template: '{{ states.media_player.kodi.attributes.media_content_type == "tvshow" }}'
        - condition: template
          value_template: '{{ states.media_player.kodi.attributes.media_content_type == "movie" }}'
    action:
        service: scene.turn_on
        entity_id: scene.cinema_time

Hope this helps.

@Molodax
Copy link
Author

Molodax commented Apr 16, 2017

@mf-social
Thank you for your comment. It wouldn't be a problem if the type would change to "tvshow" or "movie". However, the problem is that I do not see any media_content_type on states of the dev tool when video is playing.

@point-4ward
Copy link
Contributor

That's odd, definitely there for me in the latest version.

Hope you get sorted.

@Spartan-II-117
Copy link
Contributor

Are you playing content from your library?

@Molodax
Copy link
Author

Molodax commented May 8, 2017

@Spartan-II-117,
I use several addons, e.g. PlexKodiConnect and YouTube where it is the issue now, because there is no media_type_content while video is playing.

@Spartan-II-117
Copy link
Contributor

Hmm, looking through the recent code changes it looks like it should still show up, but I'm not a programmer, so I can't tell for sure

@balloobbot
Copy link

There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates.

Please make sure to update to the latest Home Assistant version and check if that solves the issue. Let us know if that works for you by adding a comment 👍

@Molodax
Copy link
Author

Molodax commented Jul 18, 2017

The issue still persists in the recent 49.0

@tomoqv
Copy link

tomoqv commented Sep 17, 2017

Any news on this? I am on 0.53.1 and just started to get more into the hass.io and kodi integration. I have an automation that looks like this:

   - alias: SVT1 köket
    trigger:
      platform: state
      entity_id: input_boolean.kitchen_svt1
      to: 'on'
    action:
    - service: media_player.play_media
      data:
        entity_id: media_player.kodi_kok
        media_content_id: 7
        media_content_type: "CHANNEL"

It sends some kind of command to kodi as I can see the spinning wheel on the kodi screen, but then it goes back to the GUI without starting TV.
I also don't see any media_content_type in states of the dev tool when I play TV in kodi.

@ryanm101
Copy link
Contributor

Sorry to ask you to check again but:
a) what version of Kodi are you using?
b) can you update to the latest version of hass

I'm running 17.3 & hass 0.56dev0 and playing a tvshow i can see this in the dev tools:
"media_content_type": "tvshow",

@tschmidty69
Copy link
Contributor

@Molodax is this still an issue?

@tomoqv
Copy link

tomoqv commented Feb 7, 2018

For me this sort of works. I can see the media_content_id in the states view, but it is not the same id as the one I use when I call media_player.play_media. Tried it just now starting playback with media_content_id: 14 and the states view shows media_content_id: 7.

@Molodax
Copy link
Author

Molodax commented Feb 20, 2018

@tschmidty69 sorry, I will be able to check it in a couple of weeks only.

@kuzin2006
Copy link
Contributor

I've managed to solve this issue. The problem is in video type definition in Kodi. The existing procedure makes two API calls: Player.GetActivePlayers to determine if player active, and then, if there is one, call to Player.GetItem gets item details, exposed as attributes of Kodi entity in HASS. And here's the problem: player item's property "type" is "unknown" for all videos not recognised by Kodi's scrobbling: so, if you play something known by IMDB, for example, the "type" is "movie":

{
  "id": 1,
  "jsonrpc": "2.0",
  "result": {
    "item": {
      "album": "",
      "artist": [
        
      ],
      "episode": -1,
      "file": "F:\\Video\\Фильмы\\The.Accountant.2016.BDRip.1080p.mkv",
      "id": 15,
      "label": "The Accountant",
      "season": -1,
      "showtitle": "",
      "thumbnail": "image://http%3a%2f%2fimage.tmdb.org%2ft%2fp%2foriginal%2fafhAUuWVB7k7PjJUd4lwO3rzhSq.jpg/",
      "title": "The Accountant",
      "type": "movie",
      "uniqueid": {
        "imdb": "tt2140479",
        "tmdb": "302946"
      }
    }
  }
}

but when you play your home video, or some other file with unrecognised name or tags - "type" is "unknown"

{
  "id": 1,
  "jsonrpc": "2.0",
  "result": {
    "item": {
      "album": "",
      "artist": [
        
      ],
      "episode": -1,
      "file": "F:\\Video\\Фильмы\\ALF.[UKR_ENG]\\Season 1\\Alf.s01e05. Keepin' the Faith.mkv",
      "label": "Alf.s01e05. Keepin' the Faith.mkv",
      "season": -1,
      "showtitle": "",
      "thumbnail": "image://video@F%3a%5cVideo%5c%d0%a4%d0%b8%d0%bb%d1%8c%d0%bc%d1%8b%5cALF.%5bUKR_ENG%5d%5cSeason%201%5cAlf.s01e05.%20Keepin%27%20the%20Faith.mkv/",
      "title": "",
      "type": "unknown"
    }
  }
}

this causes "@Property media_content_type(self)" to return None, so HASS entity has no "media_content_type" attribute at all.

My solution is pretty simple: the first call to Player.GetActivePlayers also returns "type" of player, and it is "video" for all videos, so it is possible to return Player type when Item type is unknown

{
  "id": 1,
  "jsonrpc": "2.0",
  "result": [
    {
      "playerid": 1,
      "type": "video"
    }
  ]
}

Hope this will be fixed in further versions, and now my temporary solution is to create custom platform "kodi_m", which fully inherits the existing Kodi platform except media_content_type property

<config_dir>/custom_components/media_player/kodi_m.py

from homeassistant.components.media_player.kodi import *

@asyncio.coroutine
def async_setup_platform(hass, config, async_add_devices, discovery_info=None):
    """Set up the Kodi platform."""
    if DATA_KODI not in hass.data:
        hass.data[DATA_KODI] = []
    name = config.get(CONF_NAME)
    host = config.get(CONF_HOST)
    port = config.get(CONF_PORT)
    tcp_port = config.get(CONF_TCP_PORT)
    encryption = config.get(CONF_PROXY_SSL)
    websocket = config.get(CONF_ENABLE_WEBSOCKET)

    entity = KodiDeviceM(
        hass,
        name=name,
        host=host, port=port, tcp_port=tcp_port, encryption=encryption,
        username=config.get(CONF_USERNAME),
        password=config.get(CONF_PASSWORD),
        turn_on_action=config.get(CONF_TURN_ON_ACTION),
        turn_off_action=config.get(CONF_TURN_OFF_ACTION),
        timeout=config.get(CONF_TIMEOUT), websocket=websocket)

    hass.data[DATA_KODI].append(entity)
    async_add_devices([entity], update_before_add=True)

    @asyncio.coroutine
    def async_service_handler(service):
        """Map services to methods on MediaPlayerDevice."""
        method = SERVICE_TO_METHOD.get(service.service)
        if not method:
            return

        params = {key: value for key, value in service.data.items()
                  if key != 'entity_id'}
        entity_ids = service.data.get('entity_id')
        if entity_ids:
            target_players = [player for player in hass.data[DATA_KODI]
                              if player.entity_id in entity_ids]
        else:
            target_players = hass.data[DATA_KODI]

        update_tasks = []
        for player in target_players:
            yield from getattr(player, method['method'])(**params)

        for player in target_players:
            if player.should_poll:
                update_coro = player.async_update_ha_state(True)
                update_tasks.append(update_coro)

        if update_tasks:
            yield from asyncio.wait(update_tasks, loop=hass.loop)

    if hass.services.has_service(DOMAIN, SERVICE_ADD_MEDIA):
        return

    for service in SERVICE_TO_METHOD:
        schema = SERVICE_TO_METHOD[service]['schema']
        hass.services.async_register(
            DOMAIN, service, async_service_handler,
            schema=schema)


class KodiDeviceM(KodiDevice):
    @property
    def media_content_type(self):
        """Content type of current playing media."""
        """ Modified to avoid unknown type of videos """
        content_type = 'unknown'
        if MEDIA_TYPES.get(self._item.get('type')) is None and self._players:            
                content_type = MEDIA_TYPES.get(self._players[0]['type'])
        else:
            content_type = MEDIA_TYPES.get(self._item.get('type'))
        return content_type

configuration.yaml (with normal and test instances)

media_player:
  - platform: kodi
    name: Livingroom Media Player
    host: 192.168.0.3
    port: 8080
  
  - platform: kodi_m
    name: Test Kodi_m
    host: 192.168.0.2
    port: 8888

As the result, all videos are displayed as "movie", so now it is possible to make automations (I'm going to dim lights, of course).

@ryanm101
Copy link
Contributor

If you have implemented the fix why not create a PR?

@kuzin2006
Copy link
Contributor

yes, on my way to it ))

emlove pushed a commit that referenced this issue Mar 15, 2018
* media_content_type fix

Kodi media_content_type attribute display fix

* media_content_type fix (#6989)

fixes attribute display for unknown media

* code cleanup

* trailing whitespaces

* comments correction

* redundant "else:" removed
@home-assistant home-assistant locked and limited conversation to collaborators Jul 26, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

8 participants