Solved Kodi 18 hangs with change info provider
#1
I have a hang (windows says "not responding / wait / close") on Kodi 18 win32 x86 master 0711 nightly. But for some reason it only happens in my skin, not Estuary (in Estuary I can't get a contextmenu on the "double-dot" entry).

Steps to repeat using skin.aeonmq5.leiamod:

1. Go to music window in album node (path musicdb://albums).
Navigate to the "double-dot" (..) entry.

2. open context menu on "double-dot" (dialogcontextmenu). first option is to "change information provider". Select it.

3. Dialogsettings - content opens. Select a different information provider (in my case Uni Album Scraper is the default in music settings. Selecting this opens DialogSelect. I select "Local info only" (i.e., change info provider). Back in DialogSettings select "OK" to dismiss dialog.

4. DialogConfirm - yes/no opens with text "Change Content" "Do you want to refresh information for all items within this path?" Select "yes". DialogConfirm closes and Kodi hangs at this point.

5. Killing Kodi from the OS and restarting shows that the information provider was changed but the hang appears to be when attempting to do the scan. Last thing logged is:

Code:
13:12:51.068 T:8476   DEBUG: CMusicDatabase::GetAlbumsByWhere query: SELECT albumview.* FROM albumview  WHERE albumview.strReleaseType = 'album'
13:12:51.080 T:8476   DEBUG: CMusicDatabase::GetAlbumsByWhere - query took 12 ms

Note: If instead a single album is selected with the same sequence of events, the info provider is changed just for that album and it is properly scanned (local info picked up in this case). Also after the hang and restarting Kodi, selecting an album, opening context menu, and selecting "Query information for all albums" does work.

I can't seem to find any other way to change the album info provider for all albums?

scott s.
.
Reply
#2
I'm looking at this too Scott, but great to have your feedback.

There have been some changes to how addon (inc scrapers) settings are processed, and that may also be having an impact.

I'll let you know when there is a fix to test if you would be so kind.
Reply
#3
Scott, I can't actually see a "double-dot" (..) entry in the albums node in any skin so I can't reproduce your hang. Confused

I'm not that familiar with skin.aeonmq5.leiamod so maybe I am doing it wrong there, but no "double-dot" in Estuary or Confluence either? What am I missing? Screenshot perhaps?

But I can see bugs related to the "Change Info provider" context menu action and saying yes to "Do you want to refresh information for all items within this path?".
  • On doing it with a specific album selected it works on the song ids of the album as if they were album ids with potentially odd consequences e.g. the wrong items can have lastedscraped date cleared and be rescraped.
  • On doing it with "*all albums" selected (say having navigated from Artists > Albums, or Genres > Artists > Albums), the artist scraper path is set for the parent artist, then the songids are used as above.
I am fixing those, and maybe they are related to your hang, but I need pointing at the "double-dot" to be sure.

Quote:I can't seem to find any other way to change the album info provider for all albums?
The only way at the moment is to change the default album scraper from the settings>media>music menu, and that of course does not reset any scraper choice or settings already set for specific albums. They can only be changed one at a time.

Also although it seems that you can set artist scraper settings for a genre, the settings don't get picked up when the artist is actually scraped. Another bug!

Bottomline: content/scraper management for music has longstanding flaws. There was a (somewhat heated) discussion of redesigning it nearly 2 years ago, but this was based on the misconception that it was just a matter of making the UI more like video. It isn't, there are fundamental library differences that need to be embraced.

The video library is based upon scraping of filenames using the scraper settings for the video source that contains that file. It is all about physical folder path and filenames, hence setting the "content" of a source is an obvious means to set the scraper.

The music library is based upon scanning tags embedded in the files, that implicitly creates albums and artists that may have a matching unique folder containing all the related music, but do not always have one. Kodi could insist that all the music files from an album have a unique folder (it does not currently, you can mix them and the library scan will cope), but this is not possible or reasonable for artists, even the relationship of artist to music source can be many to many.

Hence the artist scraper settings need to be held per artist and album scraper settings per album. This is currently achieved in a round about way by using the virtual path e.g "musicdb://albums/156" as strPath in the content table. By using a "path" this superficailly makes it seem like video, but storing ids would be more efficient.

To go with this it needs the facility to set/clear the scraper settings for multiple albums and artists with one action. The facility belongs on any node showing artists or albums, i.e. filtered by genre, year, playlist rules or whatever, to enable the user to scrape these using this. It does not belong to the music source, and does not really have anything to do with "content". Currently scarper settings can only be adjusted from the default album or artist at a time, a pretty useless feature.

I would like to do something about that, but I do fear a re-run of the heated "must be like video" debate. I guess I put up the PR and see what happens.
Reply
#4
Here is what I mean by "double dot" [..]

Image

In a media container, the first list item which takes you "up" a library node level.

Here's something I see in testing:

I'm not exactly sure how Estuary is opening the "albums" category from the home window (the xml code is kind of convoluted) but from testing if I use:

Code:
ActivateWindow(music,library://music/albums.xml,return)

I get the behavior of Estuary -- that .. listitem doesn't have a context menu dialog.

But the way my skin does it is to use:

Code:
ActivateWindow(music,albums,return)

then I do have the context menu dialog for .. with the only option to change information provider. Selecting that is what causes Kodi to hang.

scott s.
.
Reply
#5
Thanks Scott, all I have to do now id work out why I don't get a double-dot item like I can see you do. A setting perhaps? To go up a library level I hit backspace or Esc key.

Ah ha "Show Parent Folder Items" is the setting for hiding or showing this item.

I suspect this item was not intended to have "change information provider" in the context menu, but the method that checks if an item is a "Parent Folder" is getting confused because the path has navigation options appended. How the call to ActivateWindow impacts on this I'm not sure, but I will try to find out.
Reply
#6
As in effect a navigation control, the double-dot parent folder item should not have any context menu , but an error in the code means that it can end up with a "change information provider" (CONTEXT_BUTTON_SET_CONTENT) entry.

I figure you may like an explanation:
The visibilty of this context menu button, and the action it invokes, also varies with the duoble-dot item path, and path varies depending of the route taken navigating to that node. For example (in Confluence) navigating Music Library > Albums the path = "", and no context menu, but Music Library > Artists > Albums and path = "musicdb://artists/" so "change information provider" is in the context menu. This looks up the artist scraper, and tries to requery albums Sad

EDIT:
BTW how can I stop scanning when in Aeon Nox skin? In Confluence it is on the side blade when scanning is in progress, I didn't see it in Aeon Nox.

I would guess that the different calls to Activatewindow cause the double-dot item to have different paths, hence the behaviour you saw. But I have not been able to make it actually hang. Since the fix is to prevent the item from having a context menu I am not going to dig any deeper into that.

The fix preventing the double-dot item from having a "change information provider" on the context menu sometimes will be in my next PR.
Reply
#7
Agree that having a context menu for the "double dot" doesn't really make sense.

"Stop scanning" is an undocumented action for UpdateLibrary(music). The built-in acts as a toggle so when the library is scanning, the function works to stop the scan. The label should be updating in Nox to show the so-called "altlabel" (stop scanning) when scan is in progress as a togglebutton control (in latest Nox 7.0 control id="20" in MyMusicNav.xml).

scott s..
.
Reply
#8
PR to fix change of information provider for albums and artists here https://github.com/xbmc/xbmc/pull/12597/files
a) Setting artist or album info provider selectively that works!
b) Facility to set for multiple artists or albums
c) Facility to set default from within library, and to reset for artists and albums

Thus provides a way to change the album info provider for all albums Smile
Fixes the context menu funnies, and the other issues I found.
Also fixes the bug you reported with loading from nfo removing releasegroup id (https://forum.kodi.tv/showthread.php?tid=318218)

Bumps db to v67. I'll get a test build up and post a link if you would review please Scott.
Reply
#9
(2017-07-31, 20:50)DaveBlake Wrote: PR to fix change of information provider for albums and artists here https://github.com/xbmc/xbmc/pull/12597/files
a) Setting artist or album info provider selectively that works!
b) Facility to set for multiple artists or albums
c) Facility to set default from within library, and to reset for artists and albums

Thus provides a way to change the album info provider for all albums Smile
Fixes the context menu funnies, and the other issues I found.
Also fixes the bug you reported with loading from nfo removing releasegroup id (https://forum.kodi.tv/showthread.php?tid=318218)

Bumps db to v67. I'll get a test build up and post a link if you would review please Scott.

Already answered on the pinned roadmap thread so looking for the test build.

scott s.
.
Reply
#10
Test build here PR12597 Change Info Provider or 9095c13 on other platforms respectively.
Reply
#11
So in the test build "double dot" no longer provides a change info provider, so I call this "solved". I will start a new thread on other test results, so not to clutter up other threads.

scott s.
.
Reply

Logout Mark Read Team Forum Stats Members Help
Kodi 18 hangs with change info provider0