• 1
  • 2
  • 3(current)
  • 4
  • 5
  • 32
Library Auto Updater - Version 1.1.0
#31
gobsmob Wrote:Nope. I am using my Mac for sickbeard, couchpotato and headphones too with system screensaver and sleep permanently disabled. Since XBMC is running on foreground all the time serving all my video needs, I have enabled the screensaver inside XBMC it self through settings --> appearances --> screensaver. It will kick in after 5 minutes of idle in XBMC.
I have tried to lower down to the auto updates settings to 1 hour, but with the screensaver on, it would not run. I still have to run it the updates manually once I am out the XBMC screensaver.

Hate to resort to this line of response but...."it's always worked for me" (and the couple thousand other downloads this addon has gotten).

About the only thing I can suggest here is to post a link to a debug log on your system. Include everything from a cold startup, letting it sit through at least 2 "update periods" (no media running during update time) and then shutdown XBMC.

If you know anything about Python code you can also trick the system into running more often. Take out one of the * 60 statements here:

Code:
if(now > self.last_run + (timer_amounts[self.Addon.getSetting('timer_amount')] * 60 * 60)):

and it will run every X minutes instead of every X hours. I do this when testing to save time and make sure things are working. If you can get this info post to a pastebin site and put the link here. I'll try to take a look at it.
Reply
#32
GJones Wrote:Glad you felt it was helpful.

Took longer than I thought to get to it but both of your suggestions have been implemented and a pull request for the repo has been sent.

One important thing to note with these changes is that because the timer information is now stored in a file doing a manual run of the program will reset the timer (good thing!) however if you restart XBMC you are no longer guaranteed to run an update as in the past.

For most people I would hope this is a good thing since there is no reason to run an update if the timeout period has not expired, however I'm sure people have gotten used to this functionality and expect a scraper run from this addon when XBMC starts.

There is also a new setting for start-up delay (default 0). In the event a library update is needed on startup this will delay it from happening for a few minutes based on this setting. Should help with XBMC slow-down from having too many addons running at startup.
Reply
#33
robweber Wrote:Took longer than I thought to get to it but both of your suggestions have been implemented and a pull request for the repo has been sent.

One important thing to note with these changes is that because the timer information is now stored in a file doing a manual run of the program will reset the timer (good thing!) however if you restart XBMC you are no longer guaranteed to run an update as in the past.

For most people I would hope this is a good thing since there is no reason to run an update if the timeout period has not expired, however I'm sure people have gotten used to this functionality and expect a scraper run from this addon when XBMC starts.

There is also a new setting for start-up delay (default 0). In the event a library update is needed on startup this will delay it from happening for a few minutes based on this setting. Should help with XBMC slow-down from having too many addons running at startup.

This is all great news. Thanks for looking at the suggestions and implementing them. This will allow me to go back to the release code with improvements.
Reply
#34
Two thoughts:

1- This may be kind of an edge use case, but I'd like to be able to do a library update at a a quarter past each our and a quarter 'till each hour. I use SAGETV-XBMC to move my recorded TV from SAGETV to XBMC, and that runs and ten past and ten 'til each hour. Under Dharma it would trigger an update library, but the JSON calls changed with Eden and the developer isn't planning anymore updates (since Google bought SAGETV and then canned it).

2- I'd like to have an option to have the update run even if the player is running. I use the advanced setting to do the library updates with no pop-up, so I don't really care if they're running when I'm watching something (and it would help #1 work the way I'd like it to).

I'm looking at the settings right now, and #2 doesn't seem like it will add any confusion. #1 is stumping me a bit in terms of how you might lay it out. I keep leaning towards a three pane config, one that has Library Settings (update video, update music, and update even if player is playing), Periodic Updating (time between and startup delay), and Scheduled Updating (booleans for :00, :15, :30, and :45).

I could whip up a separate plugin to do what I want, but I often find if I want something, someone else does too. Wink I'd be happy to do the updates, commit the changes, and let you see if you want to incorporate them.
Reply
#35
Just as an update to the above. I got bored and made the changes. I figured out how to have minimal impact on the preference screen, and if a user does nothing after updating the plugin everything will work as it did before (i.e. you don't have to update any preferences for things to work again). So far in limited testing on my development machine it's working fine. I'll probably push it to my production box tonight or tomorrow.

As I said before, I'd be happy to commit the changes, post them here, pastebin them, whatever.
Reply
#36
robweber Wrote:I agree!

Sorry that XBMC can't magically get album details from a generic "Track1.mp3" file that you ripped when the program was offiline.

Leads to the question how the album info is obtained from CDDB in the first place. From a hash of track one? You tell me. Anyway,
what's being read from the CD and fed to CDDB with a connection up, I would say would be possible to cache when such a connection
is not up, until such time as a connection IS up.
Reply
#37
amorf Wrote:Leads to the question how the album info is obtained from CDDB in the first place. From a hash of track one? You tell me. Anyway,
what's being read from the CD and fed to CDDB with a connection up, I would say would be possible to cache when such a connection
is not up, until such time as a connection IS up.

From the unique cd identifier on the CD. There's enough info on the web about this. If you want to know how this is done in XBMC you might go and ask in the general section and not here.

This has nothing to do with this library updater.
Read/follow the forum rules.
For troubleshooting and bug reporting, read this first
Interested in seeing some YouTube videos about Kodi? Go here and subscribe
Reply
#38
Martijn Wrote:From the unique cd identifier on the CD. There's enough info on the web about this. If you want to know how this is done in XBMC you might go and ask in the general section and not here.

't Was a rhetorical question. So the unique identifier is an uncachable entity,
interesting.

Martijn Wrote:This has nothing to do with this library updater.

It is however in answer to the bubble I was supposed to possess, plus it has
to do with the subject at hand. Your disinterest is not my problem.
Reply
#39
amorf Wrote:It is however in answer to the bubble I was supposed to possess, plus it has
to do with the subject at hand. Your disinterest is not my problem.

So is your problem not my problem.

Stop asking here about your problem! This thread is about this script about how to run an automatic update on your library. Not about some XBMC setup that hasn't got internet when ripping CD's and the expects it to magicly pull all the info from thin air.
Read/follow the forum rules.
For troubleshooting and bug reporting, read this first
Interested in seeing some YouTube videos about Kodi? Go here and subscribe
Reply
#40
pkscuot Wrote:Just as an update to the above. I got bored and made the changes. I figured out how to have minimal impact on the preference screen, and if a user does nothing after updating the plugin everything will work as it did before (i.e. you don't have to update any preferences for things to work again). So far in limited testing on my development machine it's working fine. I'll probably push it to my production box tonight or tomorrow.

As I said before, I'd be happy to commit the changes, post them here, pastebin them, whatever.

Did you use the current XBMC updater addon as the base for the additions you made? Sounds like you did so this may be something I could easily merge and add to the main repo for this addon. If you could make a diff that would be the easiest; however posting the modified files (I'm guessing probably just service.py and maybe the settings.xml file?) to pastebin would work just fine too. You can find a way to contact me via the google code page for this addon if you want to mail it directly. Thanks!

http://code.google.com/p/xbmclibraryautoupdate/
Reply
#41
robweber Wrote:Did you use the current XBMC updater addon as the base for the additions you made? Sounds like you did so this may be something I could easily merge and add to the main repo for this addon. If you could make a diff that would be the easiest

I did base it off the current code. I put a patch file in my github repository along with all the code. I've never done diff files before, but it looks reasonable to me.

https://github.com/pkscout/service.libra...e.advanced

I've branched my github repo, as I'm also working on a way to have separate timers for music and video. I might be able to finish it today or early tomorrow if you'd rather wait to see that.
Reply
#42
pkscuot Wrote:I've branched my github repo, as I'm also working on a way to have separate timers for music and video. I might be able to finish it today or early tomorrow if you'd rather wait to see that.

FYI, that's done now and been through testing on both my dev and prod machines. The URL in the last post points to the most up-to-date code. The v2 patch file takes you from 0.4.2 to what I labeled 0.6.0. No need to use the first patch, although it's still there if you want to look at it.

If you do decide to go with the 0.5.0 stuff, there are two bugs in the 0.5.0 patch. First, I had some non-localized strings the in the enums in settings.xml. Second, there is a "drift" bug on time of day and part of hour timers. Because the timer didn't get reset until after the library updates were done, over time the timer drifted (i.e. if you had something running at a quarter past each hour, over the course of a few days it became more like 17 past). Both those things are fixed in the 0.6.0 patch.
Reply
#43
OK, this morning I found a bug with the timers I haven't been able to track down. I'll work on it today and let you know tomorrow if it's ready.
Reply
#44
pkscuot Wrote:OK, this morning I found a bug with the timers I haven't been able to track down. I'll work on it today and let you know tomorrow if it's ready.

I'm looking over the changes from the git repo you posted. No comments yet, just getting into it. Thanks for working on this.
Reply
#45
robweber Wrote:I'm looking over the changes from the git repo you posted. No comments yet, just getting into it. Thanks for working on this.

Good enough. I'm still working on it. What's in the main branch should all be working, so I branched it yesterday to start something else. Basically I noticed that 95% of the plugin is timer logic, and 5% is actually doing the updates and logging stuff. I have another project that needs timers, so I'm trying to abstract out the "do the updates" stuff into another class so that if you want to use the timer framework someplace else you only have to change the action file rather than hump through all the timer logic.
Reply
  • 1
  • 2
  • 3(current)
  • 4
  • 5
  • 32

Logout Mark Read Team Forum Stats Members Help
Library Auto Updater - Version 1.1.00