Kodi crashes when 2 concurrent busy dialogs occur

[KOPRajs]

Bug report

Describe the bug

Kodi crashes while browsing in the official YouTube add-on if 2 "busy/wait" actions occurs at once.

Expected Behavior

Kodi does not crash.

Actual Behavior

Kodi crashes.

Possible Fix

To Reproduce

Steps to reproduce the behavior:

1. Add 2 videos from YouTube to the playing queue (use the "Queue video" action).
2. Go back to the GUI and leave the first video playing in the background.
3. Execute just about any other "busy" action in the add-on (e.g. a search for another video) just before the first video ends and the second one tries to start in the background (so that both the second video loading and the search occurs at once).
4. Kodi crashes.

Debuglog

The debuglog can be found here: http://ix.io/1YCl The crashlog is from Amlogic MX2 box running Kodi 18.2 because that is the slowest device laying around right now but the same happens on at least 2 different devices as well.

Screenshots

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

Additional context or screenshots (if appropriate)

The timing can be a little tricky but it is more easy to reproduce on a slow device (e.g. RPi) where the loading times are bigger.

It is probably not YouTube specific. At least I've tested that the second action can be executed from another add-on while the YouTube video is loading in the background and the Kodi still crashes.

Your Environment

Used Operating system:

• [ ] Android

• [ ] iOS

• [X] Linux

• [ ] OSX

• [ ] Raspberry-Pi

• [ ] Windows

• [ ] Windows UWP

• Operating system version/name: LibreELEC 9.1.501 (tested on Rockchip and Amlogic)

• Kodi version: 18.4/Leia

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.

[xbmc-gh-bot[bot]]

Thank you for using Kodi and our issue tracker. This is your friendly Kodi GitHub bot :wink:

The issue that you have opened was marked as ignoring the rules of our bug tracker by a team member. Please review the following requirements for issue reports and make sure that you follow all of them:

• Reports must follow our template and have all relevant fields filled in.
• A full debug log is always mandatory.
  • Make sure that you restart Kodi after setting the log level to debug.
  • Log files may not be modified except for the removal of personally identifying information, usernames/passwords and similar.
  • For build errors, include a full build log instead.
• You may not have any banned add-ons installed.
• Bugs should be reproduced on a clean Kodi installation whenever possible.

Please understand that adherence to these rules is required for the team to be able to handle the volume of open issues efficiently. The issue will be closed after one week has passed without satisfactory follow-up from your side.

[KOPRajs]

I've added the crashlog to the first comment. I can remember this crash happening to me from time to time since the "Confluence days".

[DaVukovic]

Thanks for the log. Please be aware that you have banned add-ons installed. So please remove all unnecessary add-ons and repos which are not used to reproduce this issue. If the issue still exists, then provide a new logfile.

The "ignored rules" label will stay for the time being.

Thanks in advance.

[KOPRajs]

Ok, I can create another crashlog on a clean Kodi installation, it'll just take more time, however, I wonder what add-on would that be? Looking here (https://kodi.wiki/view/Official:Forum_rules/Banned_add-ons) and cannot find any of the installed add-ons listed there. Even though some of them might be used as well for illegal content I do use them only for a legal content. Not to mention all other video add-ons except YouTube were disabled and not involved in any way during the crash.

[DaVukovic]

I'm kind of talking about plugin.video.stream-cinema

That's also on our banned list. No matter if that requires an account or not, this add-on seem somewhat suspicious and we would like you to remove that and provide another logfile

[KOPRajs]

No problem, I've edited the first comment and added the new crashlog. This time it is reproduced on a clean installation with YouTube add-on only. Again, this bug does not seem to be related neither to the YouTube add-on nor to the Amlogic platform.

[KOPRajs]

I've briefly looked through the stack trace and through the source code and I believe the cause of the crash is pretty obvious.

The offending line seems to be in the xbmc/dialogs/GUIDialogBusy.cpp:

bool CGUIDialogBusy::WaitOnEvent()
...
      if (dialog->IsDialogRunning())
      {
        throw std::logic_error("busy dialog already running");
      }

It is actually an expected behaviour to throw an exception when there is a concurrent busy dialog.

So we either need to prevent the VideoPlayer in background from creating the busy dialogs when switching to next item in queue, or we need to allow concurrent busy dialogs.

[a1rwulf]

Concurrent busy dialogs are a nogo. We had them before and they caused even more issues, hence above code was introduced to find out when exactly those situations happen.

[KOPRajs]

The most common use case would be browsing in the GUI while playing a playlist from YouTube (or any other add-on) in background.

[a1rwulf]

@KOPRajs can you compile from source? If so, you can try: https://github.com/xbmc/xbmc/pull/16450 Then I know if this is also related to the thing I try to fix.

[KOPRajs]

Yes, I can. I'll try to build it when I've got some spare time. The other issues mentioned in the https://github.com/xbmc/xbmc/pull/16450 definitely seem related.

[ksooo]

For sure above mentioned PR will fix the issue, but we agreed that the chosen implementation is a workaround at best. So, I don't know what new insights we will get from this test. Sorry, but veto from my end to merge this PR in its current state.

[a1rwulf]

Nobody ever mentioned that the PR should get merged. From the looks I was not sure enough if it's the same issue, that's all.

[lusum]

I'm the developer of https://github.com/lusum/ampache-xbmc-plugin ampache plugin

Kodi crashes using my plugin when next song is called in a playlist and the busy dialog is active for whatever reason ( faster double click on next song, long list loading, settingbox open ).

I have tried to disable the busy dialog when setResolvedUrl is called, but it seems impossible.

liz = xbmcgui.ListItem() liz.setPath(song_url) xbmcplugin.setResolvedUrl(handle=int(sys.argv[1]), succeeded=True,listitem=liz)

I have tried with

• xbmc.executebuiltin("Dialog.close('busydialog')")
• xbmc.executebuiltin("Dialog.close('busydialog','force')")
• xbmc.executebuiltin("Dialog.close('all','true')")
• liz.setProperty("show_dialog_busy","false")

[naseef]

I'm too facing this crash while using YouTube addon with Kodi android remote apps . Steps to reproduce

1. Load a video from YouTube addon from Kodi remote app ( I'm using Yatse in android)
2. Load another video from remote app while Kodi still loading the video from step 1

The crash is so frequent in this use-case as it is very easy to trigger

[KOPRajs]

I originally wrote this to https://github.com/xbmc/xbmc/pull/21563, but since it is closed, lets bring the discussion here:

It is 2024, Omega is out, yet the crashes are still ruining my Kodi experience.

Is there still no hope to fix this? How about at least canceling the second busy action (let it fail) instead of letting Kodi to crash? Or even blocking the main thread until the second busy action is finished seems better than a crash. More ideas?

[github-actions[bot]]

This issue is now marked stale because it has been open over a year without activity. Remove the stale label or add a comment to reset the stale state. This issue will be closed in 30 days if no activity is detected.

[KOPRajs]

So here we are, another year has passed and this still seems to be impossible to fix. Would it be possible to deny use of busy dialog from the background actions?