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

Multiple scrapers in an addon calls wrong library #22399

Open
1 of 7 tasks
fhriley opened this issue Jan 5, 2023 · 1 comment · May be fixed by #22422
Open
1 of 7 tasks

Multiple scrapers in an addon calls wrong library #22399

fhriley opened this issue Jan 5, 2023 · 1 comment · May be fixed by #22422

Comments

@fhriley
Copy link
Contributor

fhriley commented Jan 5, 2023

Bug report

Describe the bug

Here is a clear and concise description of what the problem is:

I have the following addon.xml:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<addon id="metadata.foo.python" name="Foo Scraper"
       version="0.0.2" provider-name=“Author”>
    <requires>
        <import addon="xbmc.metadata" version="2.1.0"/>
        <import addon="xbmc.python" version="3.0.0"/>
        <import addon="script.module.requests" version="2.22.0"/>
    </requires>
    <extension point="xbmc.metadata.scraper.movies" language="en" library="movie_scraper.py"/>
    <extension point="xbmc.metadata.scraper.tvshows" language="en" library="tvshow_scraper.py"/>
    <extension point="xbmc.addon.metadata">
        <summary lang="en_GB">Fetch TV show and Movie metadata from a Foo server</summary>
        <summary lang="en_NZ">Fetch TV show and Movie metadata from a Foo server</summary>
        <summary lang="en_US">Fetch TV show and Movie metadata from a Foo server</summary>
        <description lang="en_GB">Fetch TV show and Movie metadata from a Foo server</description>
        <description lang="en_NZ">Fetch TV show and Movie metadata from a Foo server</description>
        <description lang="en_US">Fetch TV show and Movie metadata from a Foo server</description>
        <platform>all</platform>
        <license>GPL-3.0-or-later</license>
        <reuselanguageinvoker>false</reuselanguageinvoker>
    </extension>
</addon>

This works fine in the kodi gui: I can add a movie content source and select my addon for it, and I can also add a tvshow content source and select my addon for it. However, when kodi actually runs the scraper, it always calls movie_scraper.py, even for tv shows. Is this expected behavior or a bug?

Expected Behavior

Here is a clear and concise description of what was expected to happen:

Kodi calls movie_scraper.py for movies and tvshow_scraper.py for tv shows.

Actual Behavior

Kodi calls movie_scraper.py for movies and movie_scraper.py for tv shows.

Possible Fix

To Reproduce

Steps to reproduce the behavior:

  1. Use addon.xml from above.

Debuglog

The debuglog can be found here:

Screenshots

Here are some links or screenshots to help explain the problem:

Additional context or screenshots (if appropriate)

Here is some additional context or explanation that might help:

Your Environment

Used Operating system:

  • Android

  • iOS

  • tvOS

  • Linux

  • macOS

  • Windows

  • Windows UWP

  • Operating system version/name: MacOS 13.1

  • Kodi version: 19.5

note: Once the issue is made we require you to update it with new information or Kodi versions should that be required.
Team Kodi will consider your problem report however, we will not make any promises the problem will be solved.

@lrusak
Copy link
Contributor

lrusak commented Jan 5, 2023

That's interesting. I'm not sure if it is by design or if it is a bug.

Looking at the included scrapers they are typically separate: https://github.com/xbmc/xbmc/tree/master/addons

That doesn't mean that it should be that way, it's just an observation.

Someone else more familiar with the scraper add-ons may have to chime in.

fhriley added a commit to fhriley/xbmc that referenced this issue Jan 8, 2023
…nes multiple types

Addons correctly handled having multiple types. However, CPluginDirectory did not know what addon type it was working with. When it retrieved the addon, it used the PLUGIN or UNKNOWN. This would only search on the first type of an addon, which meant an addon with multiple types would match incorrectly.

This change makes CPluginDirectory aware of the type of addon it should retrieve so it always gets the correct addon type. Note that the changes any APIs are 100% backwards compatible.

Fixes xbmc#22399
fhriley added a commit to fhriley/xbmc that referenced this issue Jan 8, 2023
…nes multiple types

Addons correctly handled having multiple types. However, CPluginDirectory did not know what addon type it was working with. When it retrieved the addon, it used the PLUGIN or UNKNOWN types. This would only search on the first type of an addon, which meant an addon with multiple types would match incorrectly.

This change makes CPluginDirectory aware of the type of addon it should retrieve so it always gets the correct addon type. Note that the changes to any APIs are 100% backwards compatible.

Fixes xbmc#22399
fhriley added a commit to fhriley/xbmc that referenced this issue Jan 8, 2023
…nes multiple types

Addons correctly handled having multiple types. However, CPluginDirectory did not know what addon type it was working with. When it retrieved the addon, it used the PLUGIN or UNKNOWN types. This would only search on the first type of an addon, which meant an addon with multiple types would match incorrectly.

This change makes CPluginDirectory aware of the type of addon it should retrieve so it always gets the correct addon type. Note that the changes to any APIs are 100% backwards compatible.

Fixes xbmc#22399

Signed-off-by: Frank Riley <fhriley@gmail.com>
fhriley added a commit to fhriley/xbmc that referenced this issue Jan 8, 2023
…nes multiple types

Addons correctly handled having multiple types. However, CPluginDirectory did not know what addon type it was working with. When it retrieved the addon, it used the PLUGIN or UNKNOWN types. This would only search on the first type of an addon, which meant an addon with multiple types would match incorrectly.

This change makes CPluginDirectory aware of the type of addon it should retrieve so it always gets the correct addon type. Note that the changes to any APIs are 100% backwards compatible.

Fixes xbmc#22399

Signed-off-by: Frank Riley <fhriley@gmail.com>
fhriley added a commit to fhriley/xbmc that referenced this issue Jan 8, 2023
…nes multiple types

Addons correctly handled having multiple types. However, CPluginDirectory did not know what addon type it was working with. When it retrieved the addon, it used the PLUGIN or UNKNOWN types. This would only search on the first type of an addon, which meant an addon with multiple types would match incorrectly.

This change makes CPluginDirectory aware of the type of addon it should retrieve so it always gets the correct addon type. Note that the changes to any APIs are 100% backwards compatible.

Fixes xbmc#22399

Signed-off-by: Frank Riley <fhriley@gmail.com>
fhriley added a commit to fhriley/xbmc that referenced this issue Jan 22, 2023
…nes multiple types

Addons correctly handled having multiple types. However, CPluginDirectory did not know what addon type it was working with. When it retrieved the addon, it used the PLUGIN or UNKNOWN types. This would only search on the first type of an addon, which meant an addon with multiple types would match incorrectly.

This change makes CPluginDirectory aware of the type of addon it should retrieve so it always gets the correct addon type. Note that the changes to any APIs are 100% backwards compatible.

Fixes xbmc#22399

Signed-off-by: Frank Riley <fhriley@gmail.com>

Change to not reveal implementation details at the api surface.

Use the type from the base class.

Give the added hint field a better name

Get the addon type to CPluginDirectory using the existing Directory api.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants