Plugin: SageAlert v2.x

[GKusnick]

Is there something different about the way SageAlert handles the SMTP Test Settings message v. actual email alerts? For some reason the test messages are getting through for me, but all the actual alerts are landing in my spam bucket.

[Slugger]

Originally Posted by GKusnick

Is there something different about the way SageAlert handles the SMTP Test Settings message v. actual email alerts? For some reason the test messages are getting through for me, but all the actual alerts are landing in my spam bucket.

Nope, the test button simply fires an alert within SageAlert that is handled and triggers an email just like any other. The only thing I can think of is that your spam filter is generating a false positive based on the contents of the email? The headers should be exactly the same (except for the subject header). The only difference is the body of the message. You should be able to whitelist the configured sender of the alert emails though to prevent alerts from ending up in the spam folder?

[GKusnick]

Originally Posted by Slugger

The only thing I can think of is that your spam filter is generating a false positive based on the contents of the email?

Yeah, that's my guess too. The test messages are longer than typical alert messages (long enough to be broken into two SMS messages), so maybe that's the difference.

Originally Posted by Slugger

You should be able to whitelist the configured sender of the alert emails though to prevent alerts from ending up in the spam folder?

You'd think, wouldn't you? Unfortunately Exchange IMF doesn't support whitelisting without some sort of third-party add-on. I'm looking into that now.

[GKusnick]

I notice that SageAlert is still deploying to the %TEMP% directory. This is incorrect since files in that directory are routinely deleted by automated disk cleanup utilities, breaking the SageAlert webapp. I believe the Jetty file-locking issues have been fixed, so can we get SageAlert to deploy itself in some non-volatile directory? Thanks.

[GKusnick]

Feature request: can we get some sort of configurable cap on how many alerts SageAlert sends in a given time period? I had a capture device failure this morning while recording the early news and woke up to more than a hundred SageAlerts messages in my Inbox. I obviously don't need to be told that many times that something's gone wrong with my recording. (I also have SageAlert configured to text the alerts to my phone, and those are still trickling in; at this rate I expect to be deleting SageAlert texts pretty much all day.)

It could be considered a Sage core bug that it generates that many system messages for one failed recording, but on the other hand there's no harm in capping or batching messages in SageAlert as well, if it's not too much trouble.

Thanks.

[Slugger]

Originally Posted by GKusnick

I notice that SageAlert is still deploying to the %TEMP% directory. This is incorrect since files in that directory are routinely deleted by automated disk cleanup utilities, breaking the SageAlert webapp. I believe the Jetty file-locking issues have been fixed, so can we get SageAlert to deploy itself in some non-volatile directory? Thanks.

Unfortunately, this isn't the case. Since SageAlert requires some private jar files to be included within the war itself, the Sun JVM and/or Jetty locks these jars (on Windows) and causes the same problems with file locking. Because of this, I still have to deploy into the %TEMP% directory. This is especially true because of how easy it is now for users to disable/reenable the plugin, which is using the hot deploy features of Jetty to disable and reenable the app at the user's request from the plugin's config menu in the STV.

[Slugger]

Originally Posted by GKusnick

Feature request: can we get some sort of configurable cap on how many alerts SageAlert sends in a given time period? I had a capture device failure this morning while recording the early news and woke up to more than a hundred SageAlerts messages in my Inbox. I obviously don't need to be told that many times that something's gone wrong with my recording. (I also have SageAlert configured to text the alerts to my phone, and those are still trickling in; at this rate I expect to be deleting SageAlert texts pretty much all day.)

It could be considered a Sage core bug that it generates that many system messages for one failed recording, but on the other hand there's no harm in capping or batching messages in SageAlert as well, if it's not too much trouble.

Thanks.

I can possibly cap via the SystemMessageAPI.GetSystemMessageRepeatCount() call, but the API docs aren't clear on what constitutes a repeated message and more importantly, because you don't want to miss new alerts, when/how the core resets that count. Out of curiosity, would the GetSystemMessageRepeatCount() call have worked if SageAlert only sent messages where that value were less than 2? In other words, when you got the 100 sys msgs this morning, were they identified as repeated messages in the STV or were they listed as 100 separate messages?

[GKusnick]

Originally Posted by Slugger

In other words, when you got the 100 sys msgs this morning, were they identified as repeated messages in the STV or were they listed as 100 separate messages?

They're grouped together as repeated messages.

[GKusnick]

Originally Posted by Slugger

Unfortunately, this isn't the case. Since SageAlert requires some private jar files to be included within the war itself, the Sun JVM and/or Jetty locks these jars (on Windows) and causes the same problems with file locking. Because of this, I still have to deploy into the %TEMP% directory. This is especially true because of how easy it is now for users to disable/reenable the plugin, which is using the hot deploy features of Jetty to disable and reenable the app at the user's request from the plugin's config menu in the STV.

What is it about %TEMP% that avoids the file-locking issue? Surely not the name of the directory. Is there no way to get that same behavior in some other directory that's not going to be subject to automatic cleanup? Because as things stand the webapp is basically always broken for me; I have to go into the plugin config and force a redeploy every time I want to use it.

[Slugger]

Originally Posted by GKusnick

What is it about %TEMP% that avoids the file-locking issue? Surely not the name of the directory. Is there no way to get that same behavior in some other directory that's not going to be subject to automatic cleanup? Because as things stand the webapp is basically always broken for me; I have to go into the plugin config and force a redeploy every time I want to use it.

It has something to do with the actual Jetty implementation. jreichen is more familiar with the underlying problem, but it has something to do with the wacky way this was all implemented by Jetty. Hot deploying to %TEMP% is a special case that avoids the file locking issues on Windows for whatever reason. Last I remember from jreichen, the only way to fix it so you could hot deploy to other directories and avoid the file locking would be to patch it in the jetty source itself.

[Slugger]

I've just completed an initial version of the custom event support in SageAlert v2.x. I haven't put a new build in the repository yet as I'm working on a full example plugin to better illustrate its use to other developers. However, I've written a first draft of the wiki doc explaining how this works and would love for someone else to read it over and let me know if it makes sense, am I making too many assumptions, etc. with the docs? I used the docs to create my example plugin, but I may have used some insider knowledge and not realized it so if someone else can look it over I'd appreciate it.

A few things I'm looking for:

• Does the doc make sense? Do you feel you could implement the passive SageAlert support discussed in it from the doc alone? With an example (which is coming soon)?
• Is this custom event support something other devs would find useful? Would you implement it in your plugins? If not, is there something missing that is preventing you from using it?
• Any obvious errors or omissions?

The code to make all of this work is committed, I just need to finish up the example plugin and deliver it and then I'll deliver a new build with these changes.

Wiki doc: http://code.google.com/p/sagetv-addo...rtCustomEvents

What is custom event support in SageAlert? (see below)

Custom events allow other plugins to create custom events that SageAlert will listen for and handle automatically. This support is passive in that the plugin author adds the custom events and fires them as necessary in their code, but if the user of the plugin doesn't also have SageAlert installed then the events are simply ignored and not handled. If the user also chooses to install SageAlert then the custom events are automatically registered and handled by SageAlert.

Users configure notifications for custom events just like they do for the core events. Custom events are automatically added to the SageAlert GUI and are configurable just like all the others.

[Slugger]

Sorry for the series of updates today to SageAlert, but there was a packaging error that kept causing duplicate jars to be included in the final upload to Google Code, but was not happening in my test env so I kept getting confused.

Anyway, if you're running something higher than 935 please make sure it's at least 951.

935: Fine.
936-950: Bad.
951+: Fine.

Fixes in 951:

• Add support for custom events
• Do not process system message alerts if the system message being processed is a repeat (as determined by the core)
• Bunch of internal fixes (build, etc.)

A new plugin is also available: Custom Events

This plugin provides additional events that will be fired through the core's event system and provides access to additional events that you may find interesting. All of the events provided by this plugin are also available for notification via SageAlert, if you also have SageAlert installed. Feel free to suggest additional events via feature requests on my project web site.

This plugin is also the complete example of how to add passive SageAlert support to a standalone plugin.

[lenkost]

I am using SageAlert to resolve issues with HD-PVR.
I have 4 of those troublemakers.
I am using your excellent plugin and excellent solution by Eric3a.
http://forums.sagetv.com/forums/show...=Eric3a&page=5
Using WEB Power Switch
http://www.digital-loggers.com/lpc.html

Replaced batch files with simple vb6 code to handle messages correctly.
Batch file command line structure (parameters separated by spaces) cannot correctly interpret message format received from SageAlert:
-name1 "value1" -name2 "value2" etc. where values in turn can contain single quotation marks and spaces. The first space after closing quotation mark is treated as a separator:
-desc "The device input "Hauppauge HD PVR Capture Device #2 Component

So far it works perfectly with 4 HD-PVRs catching about 4-5 events a day.
It power cycles only a single effected HD-PVR.

If anyone is interested I could upload a source code and compiled exe file here.

I have a problem with the last update for SageAlert. I understand that repeated messages can be very annoying and should be avoided in case of email notification but in my case they are necessary. If a single power cycle does not fix the problem it will not retry until the next show will change the message (hopefully).

I would respectfully request to make this optional at least for Growl as soon as possible.
Thanks.

[Slugger]

I'm working on the settings panel, etc. I'm not sure how quick it will be, but eventually you'll be able to disable that feature.

[Slugger]

Originally Posted by lenkost

I have a problem with the last update for SageAlert. I understand that repeated messages can be very annoying and should be avoided in case of email notification but in my case they are necessary. If a single power cycle does not fix the problem it will not retry until the next show will change the message (hopefully).

I would respectfully request to make this optional at least for Growl as soon as possible.
Thanks.

Originally Posted by Slugger

I'm working on the settings panel, etc. I'm not sure how quick it will be, but eventually you'll be able to disable that feature.

Snapshot 962 (now in repository) provides for the ability to disable this feature. By default it's enabled and to disable it, you must do so via the Plugin Configuration screen in the STV. This is a global setting meaning you can't disable it by notification type (at this time, probably will always be this way). So if you disable it then repeat system messages will be processed and posted to all notification listeners. Conversely, enabling this feature means no listeners will ever receive duplicate system messages.

Eventually there will hopefully be some kind of synergy between the STV plugin config settings screen and web UI, but I have no idea how long that will be. I figured making this option configurable should be taken care of much sooner than later so this is the quickest solution to get it done.

[Bartok]

I have a problem with the 962... it tells me that I can't install it, as it's not compatible because I have 951 installed. Do I really need to un-install it completely to update, or is something fouled up in the updated file? Thanks

[kmp14]

Originally Posted by Bartok

I have a problem with the 962... it tells me that I can't install it, as it's not compatible because I have 951 installed. Do I really need to un-install it completely to update, or is something fouled up in the updated file? Thanks

Same with me, and also the newer 966 release, same problem.

[GKusnick]

Originally Posted by Bartok

I have a problem with the 962... it tells me that I can't install it, as it's not compatible because I have 951 installed. Do I really need to un-install it completely to update, or is something fouled up in the updated file? Thanks

Looks like a dependency deadlock. SageAlert 966 requires SageAlert (common) to be at least version 966. But SageAlert 951 requires SageAlert (common) to be at most version 951. So SageAlert (common) cannot be upgraded as long as SageAlert 951 is installed. But SageAlert cannot be upgraded without first upgrading SageAlert (common) to 966.

So yes, it looks like the workaround for now is to uninstall SageAlert 951, upgrade SageAlert (common) to 966, and then install SageAlert 966.

But since SageAlert 966 has a similar max version requirement, the same deadlock will happen again on the next upgrade. Looks like the long-term fix might be for SageAlert not to be so fussy about max version requirements.

[Slugger]

Originally Posted by Bartok

I have a problem with the 962... it tells me that I can't install it, as it's not compatible because I have 951 installed. Do I really need to un-install it completely to update, or is something fouled up in the updated file? Thanks

Originally Posted by kmp14

Same with me, and also the newer 966 release, same problem.

Originally Posted by GKusnick

Looks like a dependency deadlock. SageAlert 966 requires SageAlert (common) to be at least version 966. But SageAlert 951 requires SageAlert (common) to be at most version 951. So SageAlert (common) cannot be upgraded as long as SageAlert 951 is installed. But SageAlert cannot be upgraded without first upgrading SageAlert (common) to 966.

So yes, it looks like the workaround for now is to uninstall SageAlert 951, upgrade SageAlert (common) to 966, and then install SageAlert 966.

But since SageAlert 966 has a similar max version requirement, the same deadlock will happen again on the next upgrade. Looks like the long-term fix might be for SageAlert not to be so fussy about max version requirements.

Yes, you have to uninstall SageAlert then reinstall it (for now). The uninstall will not remove the db file or custom config, etc. so an uninstall/reinstall will act just like an upgrade (other than it's a little more inconvenient). I've been able to uninstall, skip the restart, reinstall then do the Sage restart with success (which at least saves having to restart SageTV twice for these upgrades). I'm working with support on trying to find a solution. The problem I face is that I must ensure that the common jar file is exactly at the same version as the SageAlert plugin. If I don't make that strict dependency check then there's a situation where a user could manually upgrade sagealert-common thereby breaking SageAlert. The only way for me to prevent this is to specify the MaxVersion in the SageAlert dependencies. Ironically enough, Linux allows the upgrade to proceed where Windows fails, requiring an uninstall and reinstall.

Ideally, the plugin manager will be able to determine that a SageAlert upgrade will also be forcing a sagealert-common upgrade and allow it to proceed. If support comes back and says that isn't going to happen then I'll have to remove the MaxVersion check and explain that users should never manually upgrade sagealert-common while SageAlert is installed. I don't prefer this sol'n, but I'm nearly resigned to the fact that it's probably going to have to be this way.

[kmp14]

Thanks slugger. Not a big deal to uninstall. I cant see why anyone would mess with sagealert-common, so MaxVersion should work fine IMHO.