Posts: 17,855
Joined: Jan 2011
Reputation:
1,055
Milhouse
Retired Team-Kodi Member
Posts: 17,855
2014-03-02, 10:39
(This post was last modified: 2014-03-02, 10:43 by Milhouse.)
Would an extra JSON API help? Either a start/end update method that would bookend a series of updates, or extra attribute on the SetFooDetails method? Or is there any way to defer the GUI update a few seconds in case another JSON update comes in (or just defer updates until the current JSON session is disconnected?)
Texture Cache Maintenance Utility: Preload your texture cache for optimal UI performance. Remotely manage media libraries. Purge unused artwork to free up space. Find missing media. Configurable QA check to highlight metadata issues. Aid in diagnosis of library and cache related problems.
Posts: 3,077
Joined: Jun 2009
There was a discussion about that is an earlier post about improving performance and it was discarded
But an API overlay to allow transaction type behavior would solve not only this use case but also the problems about hundreds of notifications send when added tons of items to playlists for example
Posts: 17,859
Joined: Jul 2011
Reputation:
371
Maybe buffer the notifications?
So add them to a buffer and if no more are added after X seconds execute the notification.
Posts: 62
Joined: Mar 2011
Reputation:
6
More digging and it appears that the issue is related to a list kept of all the movies when in the movie view. That list is walked for each updated and each item compared with the "updated" item.
That comparison isn't cheap (as it uses IsSamePath, and ends up doing the curl thing on one of the items)
I've added another optimization to IsSamePath where if the items being compared both contain VideoInfoTags (which they generally do) then just compare the movie and file ids to determine if it's the same path (as it should be, even if one is actually in disk path format (nfs or smb), the other in videodb format)
Be interesting to see if that helps.
Posts: 62
Joined: Mar 2011
Reputation:
6
2014-03-03, 00:55
(This post was last modified: 2014-03-03, 01:03 by cg110.)
Well I think I've understood the issue around the is test some more.
I've added another commit that switches the FileItem tests for IsVideoDB and IsMusicDb to the URIUtils versions (which matches what the rest of the Is tests are in FileItem). So now it's a simpler string compare.
That removes the parsing of the URL into a URL object just to compare the protocol. Part of me wonders if changing that validation is a good/bad thing.
However, given the function name sounds like it shouldn't be much more than an simple test, it seems reasonable to expect it to be cheap to run.
Not sure you'll notice it being snappier any where else with this change, but I am wondering if the change to IsSamePath is actually needed, it's still cheaper to compare ids, but it does add more complexity to code.
Hmm, I wonder if I should be doing these other changes on another Pull Request, as they're fixes for issues that the db changes uncovered by hitting the other code that much quicker.
However, I've no idea how I'd untangle them I guess another branch from head, cherry pick them and revert them on the db change branch.
(then I'd need another own branch with all these PRs in to test out....)
Posts: 26,215
Joined: Oct 2003
Reputation:
187
The usual method is as you propose: separate branches for specific issues, with a merged up branch for you to test with.
Posts: 471
Joined: Dec 2011
Reputation:
10
As an end-user I want to say thank you to cg110 for this achievement. This is a massive usability improvement for xbmc. I really look forward to it making its way to mainline, and back down into Openelec, etc..
Posts: 62
Joined: Mar 2011
Reputation:
6
Ok, thanks for the guidance. I think that's worked, it's removed the additions and reversion for the code now in PR 4345. (although I did manage to get it in a right mess, but managed to untangle said mess)
I do wonder if there's a neater way as I didn't include one minor optimization in the above PR, which has now been lost to history, wouldn't be hard to redo. I guess I dislike seeing code deleted/thrown away that might still have a use, but it does make both PRs tidier without it.