[therealbricky]

Hi All,

I'm working on a simple service + script addon, and I've come up against some things that have left me scratching my head:

- Automatic update for an always-running service addon.

How does this work exactly? The service addon will always be running (unless xbmc.abortRequested is set), so how does XBMC manage to replace running code? (So far I've seen XBMC poll the addons.xml in the repo, but, for most users at least, it doesn't appear to be updating automatically)

- Is there a tab panel control I can use in an addon?

Something like the addon settings dialog: tab buttons along the top, with each tab being a separate sub-window of sorts.
(I can monkey one together of course, but I'm just hoping that there's a standard one available already)

- How do I (programmatically) get a context menu on a ListItem of a xbmcgui.WindowXML?

The closest I've been able to do is a xbmcgui.Dialog().select(...) (e.g. here), which works I guess, but it's not as pretty as I'd like!


The addon in question is here: https://github.com/bricky/xbmc-addon-tvtumbler


Any help appreciated

[sphere]

These aren't noobie questions, hard to answer - I try my best

- Automatic update for an always-running service addon.

I never tried or did a closer look but there was a FIX labeled Pull Request 8 months ago which should be part of XBMC >= Frodo which changes the behavior to stop the service add-on before doing the update.

- Is there a tab panel control I can use in an addon?

Afaik, no

- How do I (programmatically) get a context menu on a ListItem of a xbmcgui.WindowXML?

Again, I never tried but it may work like with plugins:

PHP Code:

listitem = ListItem()
listitem.addContextMenuItems([('Label', 'Action'), ...]) 


But the context-menu itself is a new DialogWindow, not sure if you need (and are able) to activate (and fill) it yourself...
Another possibility is doing it completely yourself (defining a complete new dialogwindowxml, modal opening, adding items to it, waiting for OnControl, OnAction, etc) without the above method.

Or you just use dialog.select() like you already mentioned

[therealbricky]

- Automatic update for an always-running service addon.

I never tried or did a closer look but there was a FIX labeled Pull Request 8 months ago which should be part of XBMC >= Frodo which changes the behavior to stop the service add-on before doing the update.

Great find! Thank you!
That code certainly appears to handle it correctly. I guess I'll need to debug it a little better.
(it's quite probable that it does work correctly, but I'm just doing something dumb!)

Again, I never tried but it may work like with plugins:

PHP Code:

listitem = ListItem()
listitem.addContextMenuItems([('Label', 'Action'), ...]) 


But the context-menu itself is a new DialogWindow, not sure if you need (and are able) to activate (and fill) it yourself...

I've just tried that - there's no error as such, but no context menu either.
I do see the action = 117 (ContextMenu) being passed to xbmcgui.WindowXMLDialog.onAction(self, action), but no menu pops up.

If I understand you correctly you're saying that XBMC builds a DialogWindow here itself for the context menu in plugins? (now that I look a little closer, it certainly appears that way). I guess if that's the case, I'll stick with .select() for now!


Thanks for your help!

[therealbricky]

Small update here as regards the updating not working.

From my understanding, it does try to stop the running service before it does the upgrade:
(from AddonInstaller.cpp)

PHP Code:

bool CAddonInstallJob::OnPreInstall()
{
  ...

  if (m_addon->Type() == ADDON_SERVICE)
  {
    CAddonDatabase database;
    database.Open();
    bool running = !database.IsAddonDisabled(m_addon->ID()); //grab a current state
    database.DisableAddon(m_addon->ID(),false); // enable it so we can remove it??
    // regrab from manager to have the correct path set
    AddonPtr addon;
    ADDON::CAddonMgr::Get().GetAddon(m_addon->ID(), addon);
    boost::shared_ptr<CService> service = boost::dynamic_pointer_cast<CService>(addon);
    if (service)
      service->Stop();
    CAddonMgr::Get().RemoveAddon(m_addon->ID()); // remove it
    return running;
  }
  ... 


... but service->Stop() is only called here if m_addon->Type() == ADDON_SERVICE.

In my case, my addon is both a ADDON_SCRIPT and ADDON_SERVICE.
From my addon.xml:

PHP Code:

<extension point="xbmc.python.script" library="script.py">
        <provides>video executable</provides>
    </extension>
    <extension point="xbmc.service" library="service.py" start="startup" /> 


with xbmc.python.script being extended first because otherwise service.py was being called when I tried to run it from the gui.



Anyway, what I think is happening here is that m_addon->Type() for my script is giving ADDON_SCRIPT, and so service->Stop(); is not being called during the upgrade.





Verified this last night by pushing an update to the repo. The update was downloaded during the night, replaced the existing code, but looking through the xbmc.log today, there was no attempt made to stop the script (so the old script is still running).



I'm very much out of my depth here: anyone know an easy way to fix this?



Log file is here if it's of any use. Updates start at around 23:59.

[therealbricky]

Bumping this one last time, because I have some solutions, and I think I won't be the only one asking these questions:

Regarding the automatic update not stopping the service before doing the update: it appears to work correctly if you put the extension point xbmc.service before xbmc.python.script in your addon.xml. Side-effect of that is that the library listed in xbmc.service gets called when you try to run the gui. If that's a problem for you (it was for me), then another possible workaround is to have the service detect the update itself (by watching for something that will change, maybe the addon.xml) and restart the service itself (via an AlarmClock call, or I actually did it by disabling and re-enabling the addon via jsonrpc).

Regarding the context menu: there's a really nice one in script.globalsearch, nicely thought out, styled, and implemented.

Hope this helps someone.

[Martijn]

Bumping this one last time, because I have some solutions, and I think I won't be the only one asking these questions:

Regarding the automatic update not stopping the service before doing the update: it appears to work correctly if you put the extension point xbmc.service before xbmc.python.script in your addon.xml. Side-effect of that is that the library listed in xbmc.service gets called when you try to run the gui. If that's a problem for you (it was for me), then another possible workaround is to have the service detect the update itself (by watching for something that will change, maybe the addon.xml) and restart the service itself (via an AlarmClock call, or I actually did it by disabling and re-enabling the addon via jsonrpc).

Sounds like bug too me. Please create trac ticket for this.

[therealbricky]

Sounds like bug too me. Please create trac ticket for this.

I think the bug here is that I'm trying to use two extension points in one addon. It kinda works, but I wonder did anyone every really intend it to?

[Martijn]

Sounds like bug too me. Please create trac ticket for this.

I think the bug here is that I'm trying to use two extension points in one addon. It kinda works, but I wonder did anyone every really intend it to?

Yes it should work. I use it too.

[therealbricky]

Ok, ticket created: http://trac.xbmc.org/ticket/14609

[pieman]

A Google search brought up this thread regarding some coding we are trying to put together. We realise it is an old thread but some of our issues are covered by it.

We have a script addon that needs to have some time scheduling integration. As newbies we were going to reinvent the wheel with something like python-crontab. We would then have the problem that some OS' don't have cron(tab). On reflection we realised that Kodi has the service feature that we should be able to use for time scheduling.

So we are asking for advice on the best way to go about it. The existing script will have user defined start and stop times in the settings options. I guess some people have gone down the route of a 'multi-functional' script / service addon and come up against the bug defined in this thread.

Some of our users will still be running Gotham and I'm not 100% sure if the bug has been fixed for Helix. We could implement a one off fix or work around for the Gotham users and recommend they upgrade to Helix if the bug is fixed and a simple solution for time scheduling can be found.

What is the best way of interfacing a script addon time schedule from the corresponding addons' settings with Kodi? As newbies a simple explanation or example(s) would certainly help us.

[pieman]

Anybody have any ideas?