These commits (and all the PVR addons in my github account) are my initial take at moving PVR addons out of the xbmc-pvr-addons repository and into our binary addons buildsystem. A few notes

• I've only really tested compiling as I don't have any PVR setup. I only tested the pvr.demo addon which lead to the first commit.
• I've only tested this on WIN32
• all PVR addons in my github account (see https://github.com/Montellese?tab=repositories) are based on the repositores created by and kept in sync by @notspiff so a big thank you to him.
• all PVR addons depend on https://github.com/Montellese/kodi-platform which in turn depends on tinyxml which are added as common dependencies to all PVR addon repositories.

TODOs

• [x] move kodi-platform into kodi's depends buildsystem
• [x] test building on all platforms
• [ ] test every PVR addon
• [x] fix detection of OpenGL/OpenGLES2 in pvr.vdr.vnsi
• [x] pvr.dvblink depends on libcurl
• [ ] pvr.filmon depends on libcurl
• [x] libjansson and cppmyth includes and libs are installed into the wrong directory
• [x] pvr.iptvsimple depends on zlib which is downloaded from our mirrors and built using the supplied CMakeLists.txt. Unfortunately it builds shared and static libs and the builtin FindZlib.cmake provided with cmake picks up the shared lib instead of the static lib (at least on WIN32) and I haven't found a way around that yet.
• [x] sync all PVR addons to xbmc-pvr-addons
• [x] get the dependency handling right
• [x] move kodi-platform to xbmc's github account

This adds automatic dependency handling for cmake based addons by using the depends folder in existing binary addons. Addons are first downloaded and extracted, then we check if the depends folder exists and handle addon deps dynamically. Tested on linux

Additionally a few screensavers and visualizations are moved over to addons. @Montellese @jmarshallnz @notspiff ping for platform stuff and sanity checks

Note about projectm: After sinking hours on end into trying to fix the mess that projectms buildsys is and trying to get it compiled static without unresolved symbols, I gave up at let it build dynamically. On linux libprojectm.so is copied to the addon install path.

This is the rework of the HW deinterlacing for IMX6 boards (see xbmc-imx6/xbmc#70). It creates a mixer threads that offloads deinterlacing to the IPU in parallel to VPU decoding and GPU rendering.

What works:

• Selectable deinterlacing modes: None, Auto, Force

What does not work:

• Double rate feature. Can be easily implemented but needs proper settings in the GUI
• Smooth playback for HD streams which needs to be tested. The performance for my test setup increased already compared to Gotham

This PR is for review to be integrated into the current IMX6 Codec implementation.

This PR adds series recording support to Kodi.

The technical concept:

Basic concept is that PVR addons now define an arbitrary number of timer types they support, each type defining its own combination of timer type attributes (out of a set of attributes predefined by the PVR addon API).

Kodi PVR core picks up the different types (and their attributes) using a new PVR addon API function and strictly builds up the complete timer-related logic dynamically, according to the timer attributes. Timer type information is now available at every TimerInfoTag instance.

Essential timer attributes: Kodi distinguishes between manual (time-based) and epg-based timers. Also, there can be one-shot and repeating timers. All combinations of these attributes are allowed, e.g. "manual + one-shot" or "epg + repeating".

Examples for other timer attributes: "supports recording priority", "supports epg search string", "supports recording folders", ...

UI changes:

Timer window:

• A "Type" column has been added
• "Scheduled time" column now handles all combinations of weekdays, and start/stop time (incl. "any time" for timer schedules) correctly.

• The timers scheduled by timer schedules (aka repeating timers) can be displayed as "children" of the timer schedule, similar to the "group items" feature of the recording window

• This behaviour can be controlled using a new (level 4) setting available in the Confluence side blade, similar to the group items feature of the recordings window.

Timer settings dialog:

• Completely rewritten from scratch, now acts completely dynamically upon the available timer types and their attributes
• Main idea is to start creation of a new timer by selecting the appropriate timer type. Dialog content will automatically adjust itself according to the respective timer type attributes. As before, user fills in the relevant data on kicks of the new timer
• Dialog can (like before) also used for editing existing timers
• Couple of new/enhanced features, among them support for epg-based repeating timers, support for all weekday combinations, pre- and post-record time, ...
• Finally, lots of bug fixes...

• For weekday selection, a new dialog was implemented.

Context menu actions:

• All relevant context menu items are now displayed only if the corresponding functionality is available according to the timer type attributes. Example: Activate/deactivate timer
• A (from my point of view very cool) new menu item "Add advanced timer" is now available if an epg entry was selected, for example in the epg grid. This opens a timer settings dialog preset to create a an epg-based series recording based on the data of the selected epg entry.

Note: All this is implemented and tested against a real PVR addon (pvr.hts), not "just" pvr.demo. I consider pvr.hts as the reference implementation of this (larger) PVR addon API change. Code is currently here (https://github.com/ksooo/pvr.hts/tree/series-recording-support), PR will follow soon.

Feedback is much appreciated!

Last weekend I was thining that it would be nice if we would support addons that simply provide files that could be used by internal code and/or by other addons. There would be no logic and nothing to be executed in those addons. An example use case would be image package addons that could be used by multiple skins (e.g. an image package of all studio logos). I started working on it and added a basic "resource" addon which is exposed through our VFS under a resource://path.

Since I don't know much about skinning I decided to try another possible resource addon and came up with language addons. Every language in Kodi basically consists of a langinfo.xml and a strings.po so there are only files and no other logic. So I came up with the xbmc.resource.language addon extension point and resource.language.<language id> addons. The files of a language are available through resource://language/<language id>/<file>.

I have adjusted the startup code (had to move addon initialization before language loading) and added some logic to handle updates coming from old configurations. I have also added reloading of language strings if the addon providing the currently used language is updated. Furthermore I have added a dialog asking the user if he wants to switch to a newly installed language (same as for skins).

I have converted all existing languages to addons but I'm pretty sure that I messed some of them up. Furthermore I noticed that not all of the languages with a strings.po have a langinfo.xml. How does that work? Last but not least the German language also had a keyboardmap.xml file which doesn't seem to be used/referenced anywhere in our code base so I removed it.

I have also tried to adjust the build scripts but that's completely untested right now. On win32 it's also not possible right now to choose the installed languages in the installation wizard. Furthermore Xcode will need updating.

I have no idea how this fits into the tools used by @alanwww1 and our transifex project. Maybe with this it could become possible for language-specific teams to create an updated addon of their language themselves and submit them to the official repository to lessen the work @alanwww1 has to do on his own right now.

TODOs:

• [x] we need to upload all addons to a repository and integrate it into our addon repository
• [x] I don't like having repository.xbmc.org hardcoded
• [x] refreshing of the main addon repository doesn't work if the login dialog is enabled due to https://github.com/xbmc/xbmc/blob/master/xbmc/addons/AddonInstaller.cpp#L385
• [ ] the OK dialog letting the user know that we had to fall back to the English language because we couldn't find the configured language doesn't always show because Confluence's Startup.xml replaces the startup window with the home window which leads to the dialog being hidden. Whether the dialog is visible or not depends on timing. The same problem applies to the migration info dialog that @Memphiz added for the XBMC -> Kodi migration.
• [ ] we need to figure out if the windows installer properly deletes the old language directory
• [x] android packaging still seems to include the old language files

Attached a audio DSP processing system over add-ons.

This is my first version and not complete finished. Can you have a look over it and any ideas for things which must be improved or are wrong.

The current system in steps:

• Data is passed from CActiveAEBufferPoolResample to the DSP processing system if DSP enabled and minimum one add-on is available.
• All Add-ons are asked about the requested stream type to find available addons and modes, e.g. 5.1 Audio not need a stereo up mix.
• The system makes a list of master processing modes which are selectable from user.
• The system makes also a list of pre and post processing modes which are selectable and process point moveable inside Settings->System->Audio->Audio DSP Settings
• On data processing it goes over following steps:
  1. Input processing - Unmodified input stream and is send to all enabled add-ons for detection and error correction
  2. Input re-sample - Re sample of the input signal for the master processing, only one add-on is allowed for it.
  3. Pre processing - Used for any steps before master processing. All enabled add-ons functions are called to make this.
  4. Master processing - The main processing like, surround up mix or sound modification processes. Only one from user over menu selectable mode is allowed. Add-ons can pass multiple selectable modes to KODI. If input channel alignment on it is higher as requested output and the master mode does not perform a down mix it becomes handled from ffmpeg re sample after return of master function.
  5. Post processing - Used for any other steps like, volume correction, equalizer and much more. All enabled add-ons functions are called to make this.
  6. Output re-sample - Re sampling of the processing signal to KODI audio output processing.

The pre and post processing modes can be selected and moved within processing chain on audio dsp settings inside Settings->System->Audio.

Things to do or finished:

• The first version of dsp add-on headers and the basic system is finished.
• Things for me which missing and are to-do:
  1. Code cleanup
  2. Faults removal
  3. Create a helper documentation about a DSP add-on programming
  4. Code re check

Addon position The DSP enable position The button position to select streaming DSP settings dialogue The basic settings dialogue, separated in sub menus A add-on master mode settings dialogue Process chain information dialog (with CPU usage) Add-on mode process chain selection dialogue

Here it is... the first half of RetroPlayer!

Relavant links:

• Guide (pics!): Guide to configure controllers in Kodi
• Documentation: Controller Input for Emulator Development
• Code (github can't get the commit order right): commits
• Forum thread for non-code discussion: Input
• Some fancy flow charts: The lifetime of a button press for peripherals with input
• Evolution of the controller dialog: Evolution of the controller window (pics!)

This PR contains a new system for controller and keyboard input used by RetroPlayer. Games aren't included in this PR, so you'll have to use a RetroPlayer build to test the full extent of the input system. Still, the input system offers many improvements in Kodi outside of games, and lets us start collecting button map data for when games hit.

This PR is accompanied by a binary add-on, peripheral.joystick. It warrants review alongside the PR. This add-on was created to contain all of Kodi's platform-specific joystick code and keymap data.

Here are the blocking issues:

• [x] Compilation on all platforms (RPi needs an #ifdef HAS_LIBUDEV around the touchscreen fix)
• [x] Android support (thread) (thanks montellese)
• [x] The controller window's "get more" button fails silently (report)
• [x] Breaks some EventServer clients (Apple IR Remotes, some Yatse buttons, etc) (report)
• [x] Erratic button presses while mapping buttons (report)
• [x] Empty keyboard settings breaks GUI (report) (thanks montelllese)
• [x] Missing scroll bars in controller dialog (thanks hitcher)
• [x] Broken volume commands (report)
• [x] Open separate PR for [guilib] fix (done: PR 8932)
• [x] Open separate PR for [addon] changes (thanks montellese)
• [x] Broken controller input on RPi and some linux boxes (report)
• [x] Erratic controller behavior in GUI (report)
• [x] Controller dialog skips down and left for some controllers (report)
• [x] OK dialog when peripheral.joystick is not focused on opening (report) (thanks Montellese)
• [x] Move peripheral event processing to another thread to fix hangs (report)
• [x] Notification for add-on updates clears the controller profiles list (thanks montellese)
• [x] Labels disappear on first install (report) (thanks montellese)
• [x] Canceling the prompt doesn't absorb keyboard input
• [x] Kodi doesn't fail gracefully when peripheral.joystick isn't found (report) (thanks montellese)
• [x] Possible deadlock on shutdown (report) (thanks montellese)

Here are the issues that aren't blocking the merge:

• [ ] iOS Game Controller Framework support (thread)
• [x] Broken touchscreen on RPi (report)
• [ ] Controller button doesn't stay focused while user is mapping buttons (report)
• [ ] Move focusing logic to CGUIViewControl (report) (skinner advice please?)
• [ ] Incompatible with Universal Remote server (report)
• [ ] Incompatible with iMON receiver (report)
• [ ] Problems with accelerometers (report and linux solution)
• [x] Controller input not ignored when Kodi is minimized (report)
• [ ] CPeripheralAddon requires refactoring (report)
• [x] Add "Help" button
• [ ] Refocus controller when user ends mapping
• [ ] The "Reset" button resets all controllers instead of asking for a specific one
• [ ] Anomalous trigger detector misidentifies axes that are fully pressed when controller is connected
• [ ] Erroneous drivers with no joystick name can't be mapped

Skin includes have been enhanced to accept parameters and thus be able to generate dynamic content based on them. Basically, they can now act as "procedures" where needed. This can help clean up XMLs a bit, making skins much easier to read and maintain. It also allows for more component-based modular skin design.

The syntax is as follows:

include definition:

<include name="MyControl1">
  <!-- parameter list with possible default values is specified here (optional) -->
  <param name="id"/>
  <param name="posx" default="120"/>
  <param name="posy" default="120"/>
  <param name="border" default="5"/>
  <param name="background">foo.png</param> <!-- alternative form -->
  <param name="color"/>
  <definition>
    <!-- include body goes here -->
    <control id="$PARAM[id]" ...>
      <posx>$PARAM[posx]</posx>
      <posy>$PARAM[posy]</posy>
      <control ...>
        ...
        <texture border="$PARAM[border]">$PARAM[background]</texture>
      </control>
      ...
      <!-- nested include call -->
      <include name="MyControl2">
        <param name="label">$INFO[Player.Title]</param>
        <param name="color" value="$PARAM[color]"/> <!-- parameter forwarding -->
      </include>
      ...
    </control>
    ...
  </definition>
</include>

include call:

  <include file="MyControls.xml" name="MyControl1">
    <param name="id" value="60"/>
    <param name="posx" value="225"/>
    <param name="posy" value="150"/>
    <param name="color" value="white"/>
  </include>

Rules:

• Parameter list is specified using <param> tags in both include calls and definitions.
• Include definition body is enclosed within <definition> tag.
• Default values for parameters can be specified within include definition and are used as replacement when parameters are not passed in the include call
• Parameters without default values in include definitions are specified for better readability and documentation purposes only, but are otherwise not mandatory and can be omitted.
• If there are no <param> tags in include definition, <definition> tag can be omitted too.
• Concrete arguments are specified within include call tag
• Actual arguments are a combination of these two, with passed arguments having a higher priority over default ones
• Parameter references of the form $PARAM[ParamName] are replaced with actual arguments within include definition body, inside both tag values and attributes
• There can be one or more parameter references specified within a single tag/attribute value, possibly in combination with other characters (e.g. <param name="debug" value="x:$PARAM[x]; y:$PARAM[y]"/>)
• Parameter references are resolved before everything else ($INFO labels, $LOCALIZE, etc.), so these can be passed as arguments too
• Parameter references that refer to missing/undefined parameters are replaced with empty strings; one exception to this rule is when forwarding a missing parameter of the form <param name="..." value="$PARAM[MissingParamName]"/> from enclosing include to the nested include, where this parameter, which would normally be expanded to "", won't be passed at all, allowing any default value from the nested include to be correctly picked up and not overriden by ""
• Extra parameters in include call that are passed but not referenced anywhere within include definition are ignored
• Incomplete parameter references (without closing ']') are logged as errors and left as is, rather than resolved to empty strings

This feature was proposed and discussed in more detail here: http://forum.xbmc.org/showthread.php?tid=190135. It requires a change in Wiki documentation which I can help with if it gets accepted.

EDIT: Originally proposed syntax is given below. Together with the discussion that follows it, it shows the full evolution of the feature for any future reference. This syntax is NOT included in Kodi.

include definition:

<!-- default parameter values are specified here -->
<include name="MyControl1" p:posx="120" p:posy="120" p:border="5" p:background="foo.png">
  <control id="$PARAM[id]" ...>
    <posx>$PARAM[posx]</posx>
    <posy>$PARAM[posy]</posy>
    <control ...>
      ...
      <texture border="$PARAM[border]">$PARAM[background]</texture>
    </control>
    ...
    <!-- nested include call -->
    <include p:label="$INFO[Player.Title]" p:color="$PARAM[color]">MyControl2</include>
    ...
  </control>
  ...
</include>

include call:

  <include file="MyControls.xml" p:id="60" p:posx="225" p:posy="150" p:color="white">MyControl1</include>

Description

So this is it. I've been "dreaming" of this final step ever since I worked on the original settings rework in core but it turned out to be much more complicated than expected which is also why it took so long. This PR introduces (almost) all the necessary bits to be able to use the same settings system for add-ons that we already in core. Furthermore it contains a backwards compatibility layer which reads in old settings definitions (and values) and translates those into settings from the new system. After this PR settings will always be saved in the same format as guisettings.xml but it can read the settings definition either from the old add-on settings format or from the "new" core settings system format.

Since I'm not that much of an add-on user myself and since I've never written an add-on myself I'm pretty sure I missed a few things in the backwards compatibility layer. So it would be greatly appreciated if people with more experience in this area could give this a try. But beware once Kodi has written the setting values in the new format you can't go back to the old format without losing all your add-on settings. So best make a backup of your add-on data before giving this a try.

There are a few parts that are known not to be backwards compatible but I've tried to add log messages in those places so that it becomes obvious. I hope that those cases are edge cases that can live without backwards compatibility but who knows.

There are also parts that I wasn't able to test like binary add-ons defining settings through the binary add-on API since I don't know if and which add-on is using this at all.

In the end the major benefit is that GUIDialogAddonSettings has become very simple because it can derive from the existing settings related base classes. The major part of the work is in CAddonSettings which also contains the backwards compatibility layer which we can hopefully drop someday (a few releases into the future).

I'm not sure if we want to "mark" the old add-on settings approach as deprecated to try and get add-ons to adopt to the new approach or not.

Some (basically the first 25) of the commits could go into a separate PR (as I've already done with a few fixes before) but since they didn't bring any real benefit to the existing code I didn't do that yet. If someone would like me to do that to make reviewing easier I'm fine with that. Just let me know.

Part of this work also overlaps with my media importing work (CSettingsBase et al.) and should make things a bit easier there as well code-wise.

How Has This Been Tested?

Locally by installing some add-ons, opening their add-on settings and comparing the result to before.

Types of change

• [ ] Bug fix (non-breaking change which fixes an issue)
• [ ] New feature (non-breaking change which adds functionality)
• [x] Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

• [x] My code follows the Code guidelines of this project
• [x] My change requires a change to the documentation, either Doxygen or wiki
• [ ] I have updated the documentation accordingly
• [x] I have read the CONTRIBUTING document
• [ ] I have added tests to cover my change
• [x] All new and existing tests passed

Moves video rendering (fullscreen) from application to GUIWindowFullScreen. By doing this dirty regions work on fullscreen mode and the platform has separate layers for video and ui.

@popcornmix iirc you still need some options to limit fps of gui, right?

http://forum.xbmc.org/showthread.php?tid=64139&pid=1131505#pid1131505

I spent few hours to dig into it and the results are promising. I'm pretty fresh to xbmc though, so maybe there is better way to deal with it. Anyway, what you need to run native resolution:

• apply the provided patch
• set in your advancedsettings.xml following variable in < video > section:

    <video>
        <upscalemode>1</upscalemode>      <!-- upscalemode: 0-default, 1-native scaling -->
    </video>

• set your receiver to upscaling mode - upscale source to maximum display resolution (1080p in my case)

How it works:

• the GUI works with maximum resolution
• when the player is spawned it reads the source dimension and sets the renderer to the lowest supported resolution which is the best match for the source resolution
• the movie is played with lowest acceptable resolution and is upscaled by the receiver to 1080p
• when the playback stops, the xbmc GUI is back to default resolution (1080p for me)

Here are few examples, where USER = default screen resolution NATIVE = movie resolution ADJUST2 = final xbmc resolution for playback

    NOTICE: Display resolution USER : default: 1920x1080 @ 24.00Hz (17)
    NOTICE: Searching for NATIVE resolution: 1920x1080
    NOTICE: Display resolution ADJUST2 : default: 1920x1080 @ 24.00Hz (17)
    .
    NOTICE: Display resolution USER : default: 1920x1080 @ 24.00Hz (17)
    NOTICE: Searching for NATIVE resolution: 1280x720
    NOTICE: Display resolution ADJUST2 : default: 1280x720 @ 50.00Hz (29)
    .
    NOTICE: Display resolution USER : default: 1920x1080 @ 24.00Hz (17)
    NOTICE: Searching for NATIVE resolution: 720x304
    NOTICE: Display resolution ADJUST2 : default: 720x576 @ 50.00Hz (37)
    .
    NOTICE: Display resolution USER : default: 1920x1080 @ 24.00Hz (17)
    NOTICE: Searching for NATIVE resolution: 608x336
    NOTICE: Display resolution ADJUST2 : default: 640x480 @ 60.00Hz (41)
    .
    NOTICE: Display resolution USER : default: 1920x1080 @ 24.00Hz (17)
    NOTICE: Searching for NATIVE resolution: 640x256
    NOTICE: Display resolution ADJUST2 : default: 640x480 @ 60.00Hz (41)
    .
    NOTICE: Display resolution USER : default: 1920x1080 @ 24.00Hz (17)
    NOTICE: Searching for NATIVE resolution: 640x272
    NOTICE: Display resolution ADJUST2 : default: 640x480 @ 60.00Hz (41)
    .
    NOTICE: Display resolution USER : default: 1920x1080 @ 24.00Hz (17)
    NOTICE: Searching for NATIVE resolution: 720x392
    NOTICE: Display resolution ADJUST2 : default: 720x576 @ 50.00Hz (37)
    .
    NOTICE: Display resolution USER : default: 1920x1080 @ 24.00Hz (17)
    NOTICE: Searching for NATIVE resolution: 608x256
    NOTICE: Display resolution ADJUST2 : default: 640x480 @ 60.00Hz (41)
    .
    NOTICE: Display resolution USER : default: 1920x1080 @ 24.00Hz (17)
    NOTICE: Searching for NATIVE resolution: 640x352
    NOTICE: Display resolution ADJUST2 : default: 640x480 @ 60.00Hz (41)
    .
    NOTICE: Display resolution USER : default: 1920x1080 @ 24.00Hz (17)
    NOTICE: Searching for NATIVE resolution: 624x224
    NOTICE: Display resolution ADJUST2 : default: 640x480 @ 60.00Hz (41)
    .
    NOTICE: Display resolution USER : default: 1920x1080 @ 24.00Hz (17)
    NOTICE: Searching for NATIVE resolution: 1280x544
    NOTICE: Display resolution ADJUST2 : default: 1280x720 @ 50.00Hz (29)
    .
    NOTICE: Display resolution USER : default: 1920x1080 @ 24.00Hz (17)
    NOTICE: Searching for NATIVE resolution: 624x352
    NOTICE: Display resolution ADJUST2 : default: 640x480 @ 60.00Hz (41)

I have to say that results are surprisingly good. I'm using receiver with Marvell Qdeo chip and it is doing great job, the picture is visible better than when xbmc is upscaling directly to 1080p. Well, you need to try yourself to judge.

The function used to find the closest resolution match is very simple, perhaps it might be improved. For now it tries to find the lowest resolution which is equal or higher than source resolution and tries to keep as close as possible to original refresh rate for the display.

These are the results of the work I was able to do during christmas break. Seeking with RAW works way better. Kodi complexity was highly reduced and sleep workarounds as well.

Someone needs to bring it forward. Best someone with a Shield and other devices.

I want to park that here for reference as everyday job starts again.

When parsing a file failed so that needed fields, in our case frameSize are not available a guess work like with m_channels or m_samplerate does not help. Therefore fail early.

Fixes: #22378

…s startup window due to missing window content refresh after PVR Manager started.

Backport of #22389

@phunkyfish please review. Regression risk is low to zero.

…s startup window due to missing window content refresh after PVR Manager started.

Supersedes #22374.

This is a quick fix with low regression risk. The root cause of the problem is identified but fix is rather high effort. Therefore we will go with a quick fix for now and I put the real fix on my todo list.

Root cause: When used as a startup window, loading window content must be deferred until the component responsible to deliver the data for the window is fully initialized. PVR startup is async. This logic is currently (maybe always was broken). Details are discussed in #22374.

Runtime-tested by me and @emveepee

@phunkyfish please review.

Bug report

Describe the bug

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

The setArtists() method of InfoTagVideo expects a string despite being documented as expecting a list. https://alwinesch.github.io/group__python___info_tag_video.html#gad35ce83f3d549079099e31d812735c31

It raises a TypeError when given a list

TypeError: argument "entry1" for method "setArtists" must be unicode or str

Expected Behavior

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

The method should expect a tuple or list as per the documentation.

Possible the documentation is incorrect but my initial assumption is that it would be expected to function the same as other similar methods such as setStudios or setDirectors. Additionally, the original setInfo() method accepted a list.

Actual Behavior

The method expects a string and raises a TypeError when given a list as per the documentation

Possible Fix

To Reproduce

Steps to reproduce the behavior:

info_tag.setArtists(['Artist1', 'Artist2'])

Debuglog

The debuglog can be found here: https://paste.kodi.tv/evefezexaf.kodi

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

• [x] Windows

• [ ] Windows UWP

• Operating system version/name: Win 11

• Kodi version: Nexus

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.