Fanart Grabber - script for skinners

  Thread Rating:
  • 1 Votes - 5 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Post Reply
Milhouse Offline
Team-Kodi Member
Posts: 3,819
Joined: Jan 2011
Reputation: 89
Post: #46
Fair enough, and thanks for addressing the logging issue so swiftly.

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.
find quote
SpaceMonkey Offline
Posting Freak
Posts: 1,162
Joined: Aug 2008
Reputation: 24
Location: Finland
Post: #47
Question: add-on waits the amount of time specified in the runscript command before the first background is visible after XBMC startup.

Could this be changed so that the after the startup first background is visible as soon add-on has finished loading, and then use the refresh time to cycle?

This would make the experience much more seamless. I'm using 9 second refresh time and the default BG for the skin is visible for the first 9 seconds. At first I thought this is the amount of time add-on needs to populate the first image but that's not the case, it uses the value from runscript command to determine when to show the first background.
find quote
robweber Offline
Posting Freak
Posts: 880
Joined: Sep 2009
Reputation: 26
Post: #48
I see what you mean here. It has to do a run through the main loop at least one time before media is refreshed and the arrays populated. The service should probably just kick off that process as soon as the service is started. I updated the code to populate these arrays before the refresh loop is ever even entered. In my unscientific before/after tests it cut about 75% off the initial load time. Pull the newest version from git and try it out. Thanks for the feedback!
find quote
robweber Offline
Posting Freak
Posts: 880
Joined: Sep 2009
Reputation: 26
Post: #49
Just issued a request to have this added to the official xbmc repo. Hopefully you'll see it there within a few days.Should help skinners trying to use this as a dependency.

Also, I removed the Programs extension point from the addon file. This was really only there for testing purposes and with it going into the repo is no longer needed. The addon will only show up under "services" now.
find quote
Milhouse Offline
Team-Kodi Member
Posts: 3,819
Joined: Jan 2011
Reputation: 89
Post: #50
FYI, just noticed this in my log (latest git build of Gotham):
Code:
14:21:13 T:2803586128  NOTICE: script.grab.fanart: media type is: random
14:21:18 T:2803586128  NOTICE: script.grab.fanart: found 648 movies files
14:21:19 T:2803586128  NOTICE: script.grab.fanart: found 53 tv files
14:21:25 T:2803586128  NOTICE: script.grab.fanart: found 551 music files
15:21:13 T:2803586128  NOTICE: script.grab.fanart: media type is: random
15:21:18 T:2803586128  NOTICE: script.grab.fanart: found 648 movies files
15:21:19 T:2803586128  NOTICE: script.grab.fanart: found 53 tv files
15:21:25 T:2803586128  NOTICE: script.grab.fanart: found 551 music files
...
16:21:13 T:2850026576  NOTICE: script.grab.fanart: media type is: random
16:21:18 T:2850026576  NOTICE: script.grab.fanart: found 648 movies files
16:21:18 T:2850026576  NOTICE: script.grab.fanart: found 53 tv files
16:21:24 T:2903766096   ERROR: EXCEPTION Thrown (PythonToCppException) : -->Python callback/script returned the following error<--
                                             - NOTE: IGNORING THIS CAN LEAD TO MEMORY LEAKS!
                                            Error Type: <type 'exceptions.IndexError'>
                                            Error Contents: list index out of range
                                            Traceback (most recent call last):
                                              File "/storage/.xbmc/addons/script.grab.fanart/service.py", line 313, in <module>
                                                GrabFanartService().run()
                                              File "/storage/.xbmc/addons/script.grab.fanart/service.py", line 101, in run
                                                utils.log('Music - ' + self.xbmc_music[self.music_index].title,xbmc.LOGDEBUG)
                                            IndexError: list index out of range
                                            -->End of Python script error report<--
16:21:24 T:2850026576  NOTICE: script.grab.fanart: found 551 music files

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.
find quote
robweber Offline
Posting Freak
Posts: 880
Joined: Sep 2009
Reputation: 26
Post: #51
Please pull and try again. I made a mistake right before the weekend with one of my commits. I had meant to remove visibility in the Programs area but instead accidentally made it so that the service kept spawning every time the RunScript function was called. Really stupid mistake that I didn't notice until XBMC had been running for a few hours. Should be fixed now.
find quote
Milhouse Offline
Team-Kodi Member
Posts: 3,819
Joined: Jan 2011
Reputation: 89
Post: #52
(2013-12-09 18:09)robweber Wrote:  Please pull and try again.

Will do, although I'm still running 0.12.2 so not sure your recent changes (in 0.12.3) would account for the exception being thrown.

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.
find quote
robweber Offline
Posting Freak
Posts: 880
Joined: Sep 2009
Reputation: 26
Post: #53
Let me know if you still experience the exception. 12.2 is the release that is basically broken.
find quote
Milhouse Offline
Team-Kodi Member
Posts: 3,819
Joined: Jan 2011
Reputation: 89
Post: #54
It's happened again, this time with 0.12.3:
Code:
...
10:29:29 T:2850026576  NOTICE: Thread FileCache start, auto delete: false
11:19:30 T:2782286928  NOTICE: Previous line repeats 2 times.
11:19:30 T:2782286928  NOTICE: script.grab.fanart: media type is: random
11:19:36 T:2782286928  NOTICE: script.grab.fanart: found 649 movies files
11:19:36 T:2782286928  NOTICE: script.grab.fanart: found 53 tv files
11:19:42 T:2782286928  NOTICE: script.grab.fanart: found 551 music files
12:19:31 T:2782286928  NOTICE: script.grab.fanart: media type is: random
12:19:36 T:2782286928  NOTICE: script.grab.fanart: found 649 movies files
12:19:36 T:2782286928  NOTICE: script.grab.fanart: found 53 tv files
12:19:42 T:2782286928  NOTICE: script.grab.fanart: found 551 music files
13:19:31 T:2782286928  NOTICE: script.grab.fanart: media type is: random
13:19:37 T:2782286928  NOTICE: script.grab.fanart: found 649 movies files
13:19:38 T:2782286928  NOTICE: script.grab.fanart: found 53 tv files
13:19:44 T:2782286928  NOTICE: script.grab.fanart: found 551 music files
14:19:31 T:2782286928  NOTICE: script.grab.fanart: media type is: random
14:19:36 T:2782286928  NOTICE: script.grab.fanart: found 649 movies files
14:19:37 T:2782286928  NOTICE: script.grab.fanart: found 53 tv files
14:19:42 T:2782286928  NOTICE: script.grab.fanart: found 551 music files
15:19:31 T:2782286928  NOTICE: script.grab.fanart: media type is: random
15:19:37 T:2782286928  NOTICE: script.grab.fanart: found 649 movies files
15:19:37 T:2782286928  NOTICE: script.grab.fanart: found 53 tv files
15:19:43 T:2782286928  NOTICE: script.grab.fanart: found 551 music files
16:19:32 T:2782286928  NOTICE: script.grab.fanart: media type is: random
16:19:38 T:2782286928  NOTICE: script.grab.fanart: found 649 movies files
16:19:39 T:2904253520   ERROR: EXCEPTION Thrown (PythonToCppException) : -->Python callback/script returned the following error<--
                                             - NOTE: IGNORING THIS CAN LEAD TO MEMORY LEAKS!
                                            Error Type: <type 'exceptions.IndexError'>
                                            Error Contents: list index out of range
                                            Traceback (most recent call last):
                                              File "/storage/.xbmc/addons/script.grab.fanart/service.py", line 313, in <module>
                                                GrabFanartService().run()
                                              File "/storage/.xbmc/addons/script.grab.fanart/service.py", line 68, in run
                                                utils.log('TV - ' + self.xbmc_tv[self.tv_index].title,xbmc.LOGDEBUG)
                                            IndexError: list index out of range
                                            -->End of Python script error report<--
16:19:39 T:2782286928  NOTICE: script.grab.fanart: found 53 tv files
16:19:45 T:2782286928  NOTICE: script.grab.fanart: found 551 music files

XBMC has been completely idle since 21:51 the previous night (9 Dec). No changes have or are being made to the TV library (at least, not by me anyway). When this happened previously, the exception occurred while processing the Music artwork. This time, it's TV.

Hardware is a Raspberry Pi 512MB running this build of OpenELEC Gotham.

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.
find quote
Milhouse Offline
Team-Kodi Member
Posts: 3,819
Joined: Jan 2011
Reputation: 89
Post: #55
Hi, had another exception at 20:52:05 - this time I had debug logging enabled. Full debug log is on xbmclog.com.

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.
(This post was last modified: 2013-12-11 07:47 by Milhouse.)
find quote
robweber Offline
Posting Freak
Posts: 880
Joined: Sep 2009
Reputation: 26
Post: #56
Thanks for the log, I know in debug mode this thing spams the log something aweful. probably should just remove a lot of that as even when debugging it isn't super useful.

In any case I think I see what is going on here. There is a very brief window of time, probably like a milisecond, during the update process where the original artwork list is reset to 0 and new artwork is being inserted. This update happens for all the lists once an hour in a new thread. If during this update the original thread tries to access an index you'll get an exception as the list hasn't been populated yet. Like I said, this amount of time is extremely small - I have yet to have an issue on any of my machines - but you seem to hit it pretty consistently.

I've thought about this problem before and my goal is always to make the user experience seem seamless. This is why the update happens in a different thread so we don't have to pause the slideshow while the list is re-populated. I think I've hit a solution that will still keep the slideshow running though. I'll give it a try and commit any changes to GitHub. Most likely have it done some time today, just check the github page for any commits.
find quote
Milhouse Offline
Team-Kodi Member
Posts: 3,819
Joined: Jan 2011
Reputation: 89
Post: #57
(2013-12-11 16:07)robweber Wrote:  Like I said, this amount of time is extremely small - I have yet to have an issue on any of my machines - but you seem to hit it pretty consistently.

I'm running this on a Raspberry Pi (1GHz/512MB) but I'm guessing you're not, in which case "extremely small" on a powerful machine can very easily become quite large and noticeable on a little R-Pi! Smile

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.
find quote
robweber Offline
Posting Freak
Posts: 880
Joined: Sep 2009
Reputation: 26
Post: #58
That is true. I do have an Rpi but it is not my main machine. I have noticed that getting the fanart array populated does take a lot longer on the Pi though.

I made some changes to the code and committed them. The lists only get reset to 0 when we know there is content to fill them, no waiting for JSON commands while the list waits empty any more. I also added some try/except blocks for when accessing the list index just in case all else fails. This should let the program continue running and try and grab something on it's next pass through. Give it a try and see what happens.
find quote
Milhouse Offline
Team-Kodi Member
Posts: 3,819
Joined: Jan 2011
Reputation: 89
Post: #59
So far so good, no more exceptions - thanks! Smile

Now, I hate to raise the issue of logging again but is there any way you could stop these log entries appearing every hour?
Code:
06:04:06 T:2895115344  NOTICE: script.grab.fanart: media type is: random
06:04:12 T:2895115344  NOTICE: script.grab.fanart: found 649 movies files
06:04:13 T:2895115344  NOTICE: script.grab.fanart: found 53 tv files
06:04:18 T:2895115344  NOTICE: script.grab.fanart: found 551 music files

It's not good for HDD spin down when the log is being written to on a regular basis in an otherwise idle system. The above log messages should be DEBUG in my humble opinion. Or output the media counts only when one or more of the media counts has changed from its previous value.

If I leave a system idle for 24 hours, the only new log entries that appear are from script.grab.fanart, and if that log resides on a HDD, the disk is going to spin up every hour.

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.
(This post was last modified: 2013-12-14 14:11 by Milhouse.)
find quote
robweber Offline
Posting Freak
Posts: 880
Joined: Sep 2009
Reputation: 26
Post: #60
I suppose I can agree with you here. I don't much care about the writing to the HD part; but those same entries every hour do get a bit spammy when trying to find other stuff in the log. Initially those probably existed just to prove the thing was working, but can be made into debug only statements now. I'll update and push out a new release to the XBMC repo. Thanks for the feedback.
find quote
Post Reply