Plugin: SageAlert v2.x

[GKusnick]

Originally Posted by Slugger

Another alternative is to submit a feature request to SageTV asking for the ability to install older versions of plugins. I do not delete the install files for older versions when I submit a new build. The only reason you can't install an older version is because SageTV doesn't currently support it. If they did, one could go back and reinstall SageAlert 2.0.0.916 - the last build not requiring a license file.

You could resubmit 916 to the repository using a different pluginID for people who want to use this option. One potential downside, though, is the possibility that someday a core change will break 916, making it unusable. So in my opinion that's not a good long-term solution.

[Slugger]

Originally Posted by GKusnick

You could resubmit 916 to the repository using a different pluginID for people who want to use this option. One potential downside, though, is the possibility that someday a core change will break 916, making it unusable. So in my opinion that's not a good long-term solution.

And I really don't want to get into dual maintenance. I definitely won't be maintaining two versions simultaneously (same reason I don't support Sage v6 versions of any of my plugins anymore), but if someone else wanted to repackage 916 for the repository then more power to them. If someone were going to do that then they might just as well take the latest from trunk, strip the licensing code, and package that up for the repository. And if someone wants to go to that trouble then they also win the title of new SageAlert plugin owner/maintainer.

[wayner]

I am trying to update SageAlert and I keep getting the error: FAILED - Dependency: SageAlert Version 2.0.0.951. FYI my current version is 2.0.0.951 and it is telling me that an update is available. I have purchased a license.

[wayner]

Originally Posted by phareous

The only thing I use SageAlert for is to email me when something goes wrong with the sage server. While I am not against paying you for your work, I think $7.50 is too high for what it does. So I will unfortunately be uninstalling it

The other reason is because you took features that were free and removed them. I would have been much more supportive if you had a donators version that had new features not previously available

I am more than willing to pay the $7.50. Slugger has written several brilliant SageTV plugins including SRE, SJQ and SageAlert not to mention some that are now defunct. He has tirelessly provided support for these plugins and generally responds to posts to these support threads in hours, if not minutes. He generally also adds functionality requested by the user.

In fact I believe SageAlert grew out of SageTweet when some users asked if they could get notifications in ways other than Twitter.

[lenkost]

I use SageAlert to resolve issues with my troublemaker HD-PVRs. It is a great plug in and it is totally worth a donation. I don't understand why this topic keeps coming back.

It would be nice if there was another server to run exe and/or bat file with the message as a parameter. In my case it would eliminate the need for Growl.

[Slugger]

Originally Posted by wayner

I am trying to update SageAlert and I keep getting the error: FAILED - Dependency: SageAlert Version 2.0.0.951. FYI my current version is 2.0.0.951 and it is telling me that an update is available. I have purchased a license.

Yeah, you have to uninstall the current SageAlert, don't restart, then install the new one, then do the restart and all will be well. Once you upgrade to build 1000 then that error will go away. Uninstalling will not delete your SageAlert db file so you won't lose any of your config. There were some bugs with my dependencies list in and around builds 950-970, which caused this error. It has since been fixed.

[Slugger]

Originally Posted by lenkost

It would be nice if there was another server to run exe and/or bat file with the message as a parameter. In my case it would eliminate the need for Growl.

SJQ should fit that bill. SJQ can process system messages and then you can trigger any kind of task based on the contents of the system message. The only difference is that it's not immediate (it may be up to 5 mins before a task client executes the job triggered by a sys msg). Also, it could be awhile before the sys msg is processed by the SJQ server.

Assuming you want immediate triggering of the bat file, then I'd suggest opening a feature request ticket. I can probably add a very rudimentary task runner server type to SageAlert - it won't be fancy, but it'll work. Basically you'll setup an exe/bat as a "server" type in SageAlert and then SageAlert will call that bat with a series of command line args and/or environment variables with all the various elements of the alert object (subject, msg, source, etc.) available to the program being called.

[GKusnick]

Originally Posted by lenkost

I don't understand why this topic keeps coming back.

It keeps coming back because people keep getting surprised by it. It's very easy to upgrade from the free version to the paid version without even realizing there is a paid version. At that point the simplest way to get things working again is to bite the bullet and pay up. Even if you decide it's worth the price, this is not the most user-friendly way to find out about it.

In hindsight I think it might have smarter to spin off the paid version as a separate plugin that users would have to explicitly opt into by uninstalling the free version and installing the paid version. That way nobody would be surprised by accidentally upgrading themselves out of the free zone and a lot of these complaints could have been avoided.

[wayner]

Originally Posted by Slugger

Yeah, you have to uninstall the current SageAlert, don't restart, then install the new one, then do the restart and all will be well. Once you upgrade to build 1000 then that error will go away. Uninstalling will not delete your SageAlert db file so you won't lose any of your config. There were some bugs with my dependencies list in and around builds 950-970, which caused this error. It has since been fixed.

I did this and in the Sage Plugin UI everything looks ok. But when I go into my Jetty apps web page SageAlert does not show up, but my other Jetty apps including SRE, SJQ are there. Any advice on what to do?

By the way I appear to have 1002 installed.

[Slugger]

Originally Posted by wayner

I did this and in the Sage Plugin UI everything looks ok. But when I go into my Jetty apps web page SageAlert does not show up, but my other Jetty apps including SRE, SJQ are there. Any advice on what to do?

By the way I appear to have 1002 installed.

Can you get to /sagealert/ in jetty? Does it load? If not, I'm probably going to need jetty debug logs to see the error.

[wayner]

No - I get a 404 error from Jetty when I go to the Sagealert page.

Something weird must have happened as I don't see Sagealert files in the contexts or webapps folders. I do see such files in my Sage backup folders. Should I uninstall and then reinstall? If so can I just copy over a backup of my db file?

How does the Sage app think that Sagealert is installed if there is no context or webapp file?

What log files do you need? The /jetty/logs/2010_09_09.reguest.log file?

[Slugger]

Originally Posted by wayner

No - I get a 404 error from Jetty when I go to the Sagealert page.

Something weird must have happened as I don't see Sagealert files in the contexts or webapps folders. I do see such files in my Sage backup folders. Should I uninstall and then reinstall? If so can I just copy over a backup of my db file?

How does the Sage app think that Sagealert is installed if there is no context or webapp file?

All the files are installed to /SageTV/plugins/sagealert/ and are copied into Jetty when the plugin starts up and removed from jetty when the plugin is disabled. Yes, you may want to save a backup of the sagealert.sqlite file (there should be one in SageTV/plugins/sagealert/ as that's where it reads it from).

What log files do you need? The /jetty/logs/2010_09_09.reguest.log file?

I need 2010_09_09.stderrout.log, which you're probably not generating. First, ensure that the SageAlert plugin is enabled. When you enable it, it copies the files from plugins/sagealert/ to jetty/webapps/ and jetty/contexts/. If it's already enabled then disable and reenable. At that point it should be working. If it shows as 'failed' in the plugin list after a disabled/enable then you need to look in the Sage debug logs as to why the plugin init failed. If it doesn't say failed there, but it's still not copying files into jetty then you need to figure out why it's not installing the app into jetty as expected. That may require the additional jetty debug logging.

[Slugger]

Originally Posted by GKusnick

In hindsight I think it might have smarter to spin off the paid version as a separate plugin that users would have to explicitly opt into by uninstalling the free version and installing the paid version. That way nobody would be surprised by accidentally upgrading themselves out of the free zone and a lot of these complaints could have been avoided.

I might have been inclined to do this if there was a way to specify anti-dependencies such that I could ensure that the "free" version would never be installed along side the "donators" version. Unfortunately, there is no way to do that and I shutter to think about the support questions that would arise when someone mistakenly thinks they're "upgrading" the free version to the donators version, but in reality they're installing a second copy of various jars (all containing the duplicate copies of the same class files). Who knows what chaos that will cause one's system? God knows I don't want to try and figure that out. In order to do this, I'd have had to rename my implementation class, for example, in one version or the other just on the off chance both got installed. What does the core do if two different plugins specify the same implementation class? Is that allowed? Nothing but a nightmare, at best, so I dropped that idea very quickly.

I will say that anything requiring a branch of the code and dual maintenance simply won't happen (from me). If I could package up 2.0.0.916 separate, call it, say, "sagealert-unreg" and make it an antidependency of "sagealert" and make "sagealert" an antidependency of "sagealert-unreg" then I'd be willing to do that, but without that ability it's way too much of a burden, especially once someone manages to get extra jars on their classpath that shouldn't be there.

[wayner]

D'oh - I didn't reinstall Sagealert, I had reinstalled Sagealert(common). As David St. Hubbins said, It is a very fine line between stupid and clever.

[Slugger]

Originally Posted by wayner

D'oh - I didn't reinstall Sagealert, I had reinstalled Sagealert(common). As David St. Hubbins said, It is a very fine line between stupid and clever.

And so I assume all is good then?

[wayner]

All is good and everyone else should just man up and pay the $7.50.

[Slugger]

Originally Posted by wayner

All is good and everyone else should just man up and pay the $7.50.

If I need a marketing guy, I'll give you a call!

I don't want anyone to pay if they don't want to. I hope I explained sufficiently in the donations FAQ why I started asking for donations. I'm not trying to make a living here, I simply want to recoup my expenses related to my development work. Ultimately, it comes down to this simple reasoning: I'll donate my time and I have cheerfully since 2007. I think I'd scare myself if I tried to count the hours of development I've spent on SageTV so I won't even bother. But I don't care, glad to do it. 2 months ago I had to buy a Sage for Linux license and a new hard drive after wiping my lone (production) Sage server working on plugin code. 3 long evenings of restore and listening to "when can we watch tv again?" was enough that I knew I wasn't going to chance that happening again. So I spent $135 on a license and a hard drive for the test server - and let me be clear, if I didn't do this dev work I would have never bought the Linux license nor the hard drive. I'll donate my time, but I feel it appropriate to disperse out of pocket expenses amongst all who enjoy the fruits of my labour. And, quite simply, if you disagree with that reasoning then that's fine, simply don't donate. Not a problem. But to be fair, I'm not hiding anything and the source code is right there in plain view for all to see. Literally 3-4 hours, tops, of effort and one can have a fully functioning version of the latest SageAlert up and installed on their server with no need for a license file. One could even take the fruits of their effort and release the "sagealert-stick-it-to-slugger" version of the plugin to the repository for all to enjoy. Really wouldn't care - just means I can stop work on SageAlert and move on to something else.

Any donations above the initial $135 I've spent (and I'm about 90% there as of this writing) will be reinvested into my dev environment. For example, I'm really wanting to add a tuner to my test server so I can test something in a multi-tuner env - things like that. That's all.

If you don't want to donate money then that's fine, hopefully everyone understands where I'm coming from on this. And that's all I'm going to say about this topic...

[Slugger]

Snapshot 1007 provides a new server type: the process executor server

This server type allows you to execute a process in response to alerts. The initial version is rather straightforward and will be tweaked based on user response. Here are the details:

First, create one or more process executor servers in SageAlert. The file name is the name of the executable to run. Relative paths are relative to the base install dir of SageTV. Absolute paths are allowed. The executable path is for the server on which SageAlert is running.

Next, assign the server(s) you created to which ever alerts you want to execute the process for.

That's it!

When SageAlert executes the process it will inject various environment variables into the process' execution environment. These env variables contain the various details about the alert being fired. The env variables are:

• SA_SUBJ: The alert's subject
• SA_SOURCE: The source of the alert; typically this is the name of the underlying event fired by the core that triggered this alert
• SA_SHORT: The short text message of the alert
• SA_MED: The medium text message of the alert
• SA_LONG: The long text message of the alert

Below are a couple of example scripts that make use of the env vars provided. Obviously, you'll want to do way more interesting things than simply echo back the contents of the alert!

Linux bash script

#!/bin/bash

echo $SA_SUBJ
echo $SA_SOURCE
echo $SA_SHORT
echo $SA_MED
echo $SA_LONG
echo All done

Logged output in sagealert.log:

2010-09-10 14:55:12,806 WARN  [k]: Running '/opt/sagetv/server/sa_echo.sh' (output below)

New client connected to SageTV server
ClientConnected
Client 'Laptop PS' has connected to the SageTV server.
Client 'Laptop PS' has connected to the SageTV server.
Client 'Laptop PS' has connected to the SageTV server.
All done

Windows batch file

@echo %SA_SUBJ%
@echo %SA_SOURCE%
@echo %SA_SHORT%
@echo %SA_MED%
@echo %SA_LONG%
@echo All done

2010-09-10 14:55:12,806 WARN  [k]: Running 'C:\Program Files\SageTV\SageTV\sa_echo.bat' (output below)

New client connected to SageTV server
ClientConnected
Client 'Laptop PS' has connected to the SageTV server.
Client 'Laptop PS' has connected to the SageTV server.
Client 'Laptop PS' has connected to the SageTV server.
All done

Each time a process is executed plenty of output is logged to the sagealert.log file (in plugins/sagealert/) so if things aren't working as expected then head there first. If you post a question here, please append the relevant portion of the sagealert.log file for me to review.

Feedback, suggestions, etc. about this new feature are welcomed.

NOTE: This feature is currently unlocked and fully functional, but will eventually be locked and require a license file after a sufficient amount of testing has been performed.

[lenkost]

2 issues so far:

1. The Shell command will not execute from my exe file compiled via vb6.
Example:
a=Shell("C:\Program Files\SageTV\SageTV\UU.W32.exe 192.168.0.200:80 Admin:1234 3off")
The same command executes OK if exe starts manually or via Growl.

2. The exe file runs hidden(all graphical interface is blocked).
This is not that important , but the first issue is.
Thanks.

[Slugger]

Originally Posted by lenkost

2 issues so far:

1. The Shell command will not execute from my exe file compiled via vb6.
Example:
a=Shell("C:\Program Files\SageTV\SageTV\UU.W32.exe 192.168.0.200:80 Admin:1234 3off")
The same command executes OK if exe starts manually or via Growl.

What is the exact command name you registered with SageAlert? Does the command have arguments? Can I please see the sagealert.log output of the attempt to run it by SageAlert? Currently, command line args aren't going to work well (i.e. not at all) with this implementation. That can be fixed.

2. The exe file runs hidden(all graphical interface is blocked).
This is not that important , but the first issue is.
Thanks.

This is a limitation of executing processes via Java. Interactive/GUI apps will not work well, if at all, when triggered by a Java program.