Gotham scrolling performance vs Frodo (large library)
#1
Hi

I've got a relatively large movies library, 1000+ movies, compared to Frodo using a few days old Gotham release I noticed scroll performance in poster mode is "slower". When with Frodo when I scroll at full speed the pictures will show up very quickly after scroll stopped, with Gotham it can take a few seconds for these to catch up.
Not a biggie and it's possible it's fully expected.
This is running on a NUC Haswell.
Reply
#2
Gotham should be faster.
Your textures aren´t cached, rescanned library? Could also be that db version is new, but I thought it would automatically update itself(?).
Anywhooo... as soon as it is cached it will be fast(er) again.

Edit: This will speed up things (running with './texturecache.py c' will automatically cache everything without having to browse through the library): http://forum.xbmc.org/showthread.php?tid=158373
Reply
#3
Hi
The slow display of movie pictures (under xperience1080 and xperience1080++ skins) in Gotham compared to Frodo was much slower and as far as I know my NUC had completed the indexing and the slow performance was happening across XBMC restarts.
I have 16GB RAM so I don't have a problem with XBMC eagerly loading all pictures.
I will let you know how it goes.
Thanks
Reply
#4
(2014-02-05, 11:00)miappa Wrote: Edit: This will speed up things (running with './texturecache.py c' will automatically cache everything without having to browse through the library): http://forum.xbmc.org/showthread.php?tid=158373
Running this should fix it, I had similar issue until I forced the cache to update, then it was back to the usual speed. What you describe at the moment is the brief wait while it downloads the art manually when you stop on an item.
Reply
#5
(2014-02-05, 23:13)jznine Wrote:
(2014-02-05, 11:00)miappa Wrote: Edit: This will speed up things (running with './texturecache.py c' will automatically cache everything without having to browse through the library): http://forum.xbmc.org/showthread.php?tid=158373
Running this should fix it, I had similar issue until I forced the cache to update, then it was back to the usual speed. What you describe at the moment is the brief wait while it downloads the art manually when you stop on an item.

I have the similar issue with Gotham 13.1 having Aeon Nox 5 running on Windows 7 x86 on Dell Studio Hybrid 1.8 Core2Duo with 4GB RAM. Movie database size is 2500+ and TV Shows 500+ episodes, spanned over three 2 TB Network storage drives connected and mapped to the XBMC PC as local drive letters.

Given the kinda newbie I am, can someone please exactly guide how to run this command. I have downloaded and installed Python 3.4.1 but how to proceed forward. Is there any specific folder or command window where this command is to be executed.

Thanks for quick help.
Reply
#6
I have run the script which completed successfully over a library of 2500+ movies, it ran for around 6 hours with some errors on some rows, not sure what the error were meant for.

Even after running the script the movie library scrolling performance has not improved. It is the same or maybe worst. In frodo the movie library instantly updated my "list" view with the movie posted and the movie fanart in the background. However now in Gotham, it is still very slow and poster is displayed with a gap or 7-10 sec or maybe more, and sometimes the fanart is not loaded at all.

This is a big turn down for me as the visual appeal of the whole home movie theatre is spoiled. I have tried running it with the default confluence skin , but am now using the Aeon Gotham 4.1.9.x and the issue remains the same.

Can I downgrade back to Frodo. I read that the database in the earlier version is also saved while upgrading, i still want to remain on Gotham however if the library is back with all the bling bling.

Any further ideas or guidance is appreciated.

Thanks.
Reply
#7
Have you tried looking at a debug log (wiki) to see if there are any errors in it related to XBMC fetching the art ? Fanart not loading at all is clearly not correct if it is present.

You said you tried Confluence. Does the issue still manifest itself in that skin ?
Learning Linux the hard way !!
Reply
#8
Helix is even better and seems way more efficient so far. But nothing like texturecache.py to pre-cache the textures.
Reply
#9
Just out of interest, what output do you get with the following command:
Code:
texturecache.py fixurls

If all is well it should be "[]", but if you get something else then it would suggest your media urls are mangled which may result in artwork being cached multiple times.

If you run:

Code:
texturecache.py fixurls | texturecache.py set

the urls will be corrected, after which you should re-cache your artwork one more time and then (hopefully) XBMC will be displaying artwork with minimum delay, if not then something else is obviously the issue (graphics driver?)
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.
Reply
#10
(2014-08-29, 18:09)Milhouse Wrote: Just out of interest, what output do you get with the following command:
Code:
texturecache.py fixurls

If all is well it should be "[]", but if you get something else then it would suggest your media urls are mangled which may result in artwork being cached multiple times.

If you run:

Code:
texturecache.py fixurls | texturecache.py set

the urls will be corrected, after which you should re-cache your artwork one more time and then (hopefully) XBMC will be displaying artwork with minimum delay, if not then something else is obviously the issue (graphics driver?)

Here is the output I get with "texturecache.py fixurls"

Microsoft Windows [Version 6.1.7600]
Copyright © 2009 Microsoft Corporation. All rights reserved.

C:\Program Files\Python34\Scripts>python.exe texturecache.py fixurls
Parsing MovieSets: ╨ó╤Ç╨╕ ╨╝╨╡╤é╤Ç╨░ ╨╜╨░╨┤ ╤â╤Ç╨╛╨▓╨╜╨╡╨╝ ╨╜╨╡╨▒╨░ (╨Ü╨╛╨╗╨╗╨╡╨
[]

I have already run it with "c" option once on my Kodi//Gotham installation and the result is nill.

Grraphic driver is not the issue, cause all hardware / software settings are kept constant and I only upgraded from Frodo to Gotham,

On Frodo with the same graphics card//driver a media library of 2500+ movies and TV Shows was running lightning fast and the movie poster and background artwork was instantly updated even when I was browsing the movie library at high speed with a constant click of up or down button.

Kinda regretting my decision to upgrade.

Thanks for any further help.
Reply
#11
Doesn't appear to be a caching issue then. I can't think of anything else to suggest, hopefully someone else will think of something.

Edit: Just a thought, test your scrolling performance in stock Confluence and use that as your baseline. If Confluence is fine then it might suggest a performance issue with your third party skin.
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.
Reply
#12
It's almost the same in confluence. Otherwise the software is responsive and everything else works the same way it should. Only the scrolling performance is affected.

Can anyone else with a big library please confirm it.

Is there a safe way to downgrade to earlier Frodo. A link to it would be thanked for.
Reply

Logout Mark Read Team Forum Stats Members Help
Gotham scrolling performance vs Frodo (large library)0