Studio Tools for SageTV V7

[GKusnick]

Tools Library V1.1 has been uploaded to the repository, and includes a refresh of the API wrappers for SageTV V7.0.11.

Studio Plugin Framework V1.1 has also been uploaded, and fixes the issue where hotkeys don't work until after you've opened the Plugins menu once.

There is no update to the Studio Tools plugin at this time.

[GKusnick]

Studio Plugin Framework V1.2 has been uploaded, fixing a ConcurrentModificationException during plugin shutdown.

[jusjoken]

I have the Studio Tools installed however in Studio, the Plugins menu is empty except for a greyed out item that states "No studio plugins are enabled". How do I enable your plugins so they show up or how do I determine why they are not displaying?

Thanks

[GKusnick]

Originally Posted by jusjoken

How do I enable your plugins so they show up or how do I determine why they are not displaying?

You enable Studio plugins in the V7 plugin manager, the same as any other kind of plugin. Make sure you have the Studio Tools (not just the Studio Plugin Framework) installed and enabled.

If that doesn't solve it, quit Sage, open up gkusnick.util.Log.properties in Notepad, and set gkusnick.sagetv.studio.Hook=true. Then try it again and post the log here (as an attachment, please).

[jusjoken]

Studio Tools and Studio Plugin Framework are installed and enabled.

Here is my log file after enabling the hook property.

Thanks for your help.

Copy of sagetvclient_0.txt

[GKusnick]

According to your log, GetPluginImplementation() is returning null. That means my framework can't get a reference to the Tools plugin, which is why it's not showing up on the Plugins menu.

I've reproduced that behavior here by running the framework on the server. This is not how I would expect GetPluginImplementation() to work, so I've opened a bug ticket with Sage support.

Meanwhile, if you have an instance of SageTV Client you can use, it should work correctly there. In my opinion that's a better way to develop anyway since it insulates your server from any mistakes you might make (although obviously it does require a separate client license).

[Opus4]

Is the client running on the server? If so, is the server running in service mode or as a separate UI?

- Andy

[GKusnick]

Originally Posted by Opus4

Is the client running on the server? If so, is the server running in service mode or as a separate UI?

I tried it both ways (service mode and non-service mode) and GetPluginImplementation() returned null for all installed plugins in both cases. In particular, the Studio Framework could not get a reference to its own implementation, which seems odd no matter which process it's running in. Similarly, one would hope that the Tools plugin and the Framework plugin would load into the same process and therefore have access to each other's implementation, regardless of whether Sage is running as a service or not.

[GKusnick]

Update: it does after all work correctly in non-service mode on the server; I was just doing my testing wrong.

There is an issue that prevents it from working properly in service mode, but I'm told this will be fixed in the next build.

[jusjoken]

As you are now aware, I was running it in service mode.

Thanks for looking into this and glad to see it will be fixed in the next build. I will also likely setup a client to do my builds with.

[GKusnick]

Originally Posted by jusjoken

I have the Studio Tools installed however in Studio, the Plugins menu is empty except for a greyed out item that states "No studio plugins are enabled". How do I enable your plugins so they show up or how do I determine why they are not displaying?

Originally Posted by GKusnick

There is an issue that prevents it from working properly in service mode, but I'm told this will be fixed in the next build.

I have verified that Framework V1.2 (the current version in the repository) works correctly now in service mode in 7.0.12.

[GKusnick]

Tools Library V1.2 has been uploaded to the repository. This update includes a refresh of the API wrappers for SageTV V7.0.12. MediaNodeAPI methods are now being wrapped correctly for the first time.

This version also includes two new utility classes:

STVIConfig provides runtime support for my new STVI Configurator plugin. You shouldn't need to call these methods directly, but the Javadocs for this class provide detailed instructions on how to use the STVI Configurator to provide a config UI for your STVI plugin using the standard V7 plugin configuration machinery.

XmlConfig allows you to define your plugin's config settings in an XML file. It provides XML-based implementations of all the get/setConfig* methods that you can call directly or inherit from an abstract class. XmlConfig is orthogonal to STVIConfig and can be used either from a Java-based plugin or an STVI plugin built on top of the STVI Configurator. (To be clear, this is not about storing the actual setting values in XML files; those are still stored in Sage.properties as usual. The purpose of the XML file is to define the names, types, and default values of the settings your plugin supports.) Full details, including the XML file format, are in the Javadocs.

[GKusnick]

Tools Library V1.3 has been uploaded and includes a refresh of the API wrappers for SageTV V7.0.15.

There are no other changes.

[Slugger]

A user is reporting errors with SageAlert. I've tracked it down to this stack trace:

Exception in thread "Thread-67" java.lang.NullPointerException
	at gkusnick.sagetv.api.MediaFileAPI$MediaFile.GetMediaFileID(MediaFileAPI.java:388)
	at com.google.code.sagetvaddons.sagealert.server.events.RecordingStartedEvent.getLongDescription(RecordingStartedEvent.java:52)
	at com.google.code.sagetvaddons.sagealert.server.GrowlServer$1.run(GrowlServer.java:119)

Originally I was getting NPEs on a RecordingStarted event handler with this line of code:

String subtitle = mf.GetMediaFileAiring().GetShow().GetShowEpisode();

So like a good little defensive programmer, I modified the code to look like this:

		AiringAPI.Airing a = mf.GetMediaFileAiring();
		if(a != null) {
			ShowAPI.Show s = a.GetShow();
			if(s != null) {
				String subtitle = s.GetShowEpisode();
				if(subtitle != null && subtitle.length() > 0)
					msg.append(": " + subtitle);
			} else
				LOG.warn("Airing show is unexpectedly null for Airing ID: " + a.GetAiringID());
		} else
			LOG.warn("MediaFile airing is unexpectedly null for MF ID: " + mf.GetMediaFileID());

Now I get the NPE into your code on the last line, on the call to mf.GetMediaFileID(). So many questions...

The mf var above is the wrapped arg received in the event listener

Should mf.GetMediaFileAiring() ever return null? I believe the fact that it does is a bug somewhere. I tried to get the api call to return null in Studio, but it never did. Is this a bug with the wrapper or is there an issue with the contents of the object when passed to an event listener (which is then corrected shortly there after)?

Any clue why your code is throwing an NPE? Maybe this will solve the problem?

I'm unable to reproduce this on any of my servers:

WinXP, Sage 7.0.13, wrapper 1.2.31
Linux, Sage 7.0.13, wrapper 1.2.31

The user is running:

Win7, Sage 7.0.13, wrapper 1.2.31

Thoughts/suggestions appreciated.

EDIT: User is running Vista, not Win7

[GKusnick]

Do you see any InvocationTargetExceptions in the debug log? That's about the only case I can see where my wrappers return null. In the case of GetMediaFileAiring, the null is just returned; in the case of GetMediaFileID, it tries to cast it to an int, so that's probably where the NPE is coming from.

My best guess is that the event listener was passed an invalid MediaFile object, or that it somehow became invalid after you wrapped it, and that's causing InvocationTargetExceptions when you try to invoke its methods. But if so, those errors ought to be showing up in a log somewhere (wherever System.err output goes in your user's setup).

[Slugger]

Not seeing any InvocationTargetExceptions (thrown by Sage.jar), but I can see that SageAlert is always the second listener receiving the event and now that I've looked at the log output a little closer, I'm seeing a major issue with the event queue thread...

Here's some output from the user's log

Core is about to process the event RecordingStarted vars={MediaFile=MediaFile[id=6315079 A[6103039,1235061,"Good Day Oregon Sunday",10651@0815.07:00,120] mask=TV host=zoomerang encodedBy=Hauppauge HD PVR Capture Device Best-H.264 format=MPEG2-TS 0:00:00 2948 kbps [#0 Video[H.264 29.97003 fps 1920x1080 16:9 interlaced]#1 Audio[AC3 48000 Hz 6 channels 448 kbps MAIN idx=1 id=1100]] \\192.168.1.9\Videos\SageTV\GoodDayOregonSunday-6103039-0.ts, Seg0[Sun 8/15 8:08:49.229-Sun 8/15 8:10:29.069], Seg1[Sun 8/15 8:19:59.377-Wed 12/31 16:00:00.000]]}
Core sending event RecordingStarted to ortus.mq.OrtusMQPlugin@b4d685 vars={MediaFile=MediaFile[id=6315079 A[6103039,1235061,"Good Day Oregon Sunday",10651@0815.07:00,120] mask=TV host=zoomerang encodedBy=Hauppauge HD PVR Capture Device Best-H.264 format=MPEG2-TS 0:00:00 2948 kbps [#0 Video[H.264 29.97003 fps 1920x1080 16:9 interlaced]#1 Audio[AC3 48000 Hz 6 channels 448 kbps MAIN idx=1 id=1100]] \\192.168.1.9\Videos\SageTV\GoodDayOregonSunday-6103039-0.ts, Seg0[Sun 8/15 8:08:49.229-Sun 8/15 8:10:29.069], Seg1[Sun 8/15 8:19:59.377-Wed 12/31 16:00:00.000]]}
DONE Core sending event RecordingStarted to ortus.mq.OrtusMQPlugin@b4d685
Core sending event RecordingStarted to com.google.code.sagetvaddons.sagealert.server.RecordingEventsListener@bdc70f vars={MediaFile=6315079}
DONE Core sending event RecordingStarted to com.google.code.sagetvaddons.sagealert.server.RecordingEventsListener@bdc70f
Exception in thread "Thread-65" java.lang.NullPointerException
	at com.google.code.sagetvaddons.sagealert.server.events.RecordingStartedEvent.getLongDescription(RecordingStartedEvent.java:37)
	at com.google.code.sagetvaddons.sagealert.server.GrowlServer$1.run(GrowlServer.java:119)

Core is about to process the event RecordingStarted vars={MediaFile=MediaFile[id=6315111 A[6110124,6101990,"At the Movies",20292@0815.16:30,30] mask=TV host=zoomerang encodedBy=Hauppauge HD PVR Capture Device Best-H.264 format=MPEG2-TS 0:00:00 0 kbps [] \\192.168.1.9\Videos\SageTV\AttheMovies-6110124-0.ts, Seg0[Sun 8/15 16:30:00.106-Wed 12/31 16:00:00.000]]}
Core sending event RecordingStarted to ortus.mq.OrtusMQPlugin@168aaed vars={MediaFile=MediaFile[id=6315111 A[6110124,6101990,"At the Movies",20292@0815.16:30,30] mask=TV host=zoomerang encodedBy=Hauppauge HD PVR Capture Device Best-H.264 format=MPEG2-TS 0:00:00 0 kbps [] \\192.168.1.9\Videos\SageTV\AttheMovies-6110124-0.ts, Seg0[Sun 8/15 16:30:00.106-Wed 12/31 16:00:00.000]]}
DONE Core sending event RecordingStarted to ortus.mq.OrtusMQPlugin@168aaed
Core sending event RecordingStarted to com.google.code.sagetvaddons.sagealert.server.RecordingEventsListener@7bed26 vars={MediaFile=6315111}
DONE Core sending event RecordingStarted to com.google.code.sagetvaddons.sagealert.server.RecordingEventsListener@7bed26
Exception in thread "Thread-199" java.lang.NullPointerException
	at gkusnick.sagetv.api.MediaFileAPI$MediaFile.GetMediaFileID(MediaFileAPI.java:388)
	at com.google.code.sagetvaddons.sagealert.server.events.RecordingStartedEvent.getLongDescription(RecordingStartedEvent.java:52)
	at com.google.code.sagetvaddons.sagealert.server.GrowlServer$1.run(GrowlServer.java:119)

You'll notice in both cases, the ortus event handler is receiving an arg map that definitely appears to contain a MediaFile object (based on the contents of the dump). But then right below when the event thread dispatches the event to the SageAlert listener the arg map just contains {MediaFile=6315079}, which if I'm interpreting this correctly suggests that the SageAlert listener is just receiving a string (or possibly an int) referencing the MediaFile id instead of the actual object. The first thing SageAlert does with that arg is wrap it as a MediaFileAPI.MediaFile, but if it's just receiving a string or int then obviously wrapping it is incorrect. I'm looking at the SageTVEventListener.java file and it doesn't say the arg can be an obj or a string/int, I'd assume based on that file that we should always expect an actual object as the arg.

I guess we'll need Narflex or someone to jump in and confirm that I'm interpreting the log output properly and then advise if this is a bug or as designed. Does my interpretation of the log output I'm seeing above make sense?

[GKusnick]

Originally Posted by Slugger

I guess we'll need Narflex or someone to jump in and confirm that I'm interpreting the log output properly and then advise if this is a bug or as designed. Does my interpretation of the log output I'm seeing above make sense?

Makes sense to me. The next steps I'd take in your shoes would be to try to verify that the thing in the arg map is a MediaFile object when you're the first (or only) listener in line and that it's some other type (String or int or whatever) when Ortus gets to it first. If that's the case, then a conversation with the Ortus guys would seem to be in order to find out if they're inadvertantly doing something to alter the contents of the map. If they are, then it would be up to Jeff to rule on whether that's allowed (in which case he needs to rebuild the arg map between listeners) or not (in which case that should be spelled out in the listener interface contract).

One could also make a separate case that my Wrap() methods should sanity-check their arguments and throw an exception if they're not of the expected type. I'm a bit reluctant to do that since there are some legitimate polymorphisms in the Sage API such that (for instance) AiringAPI methods can be invoked on MediaFiles and vice versa and the right thing happens. I'd have to explicitly allow for such intentional loopholes if I were to tighten up my wrapping rules.

[Slugger]

When SageAlert is the first/only listener in line, such as on my servers, then it's definitely a MediaFile object in the map. That explains why I could never reproduce this bug locally. I don't even know which plugin(s) use the ortus mq plugin, but I'll get a message sent off to them to see if they're modifying the map.

I'm assuming Jeff's going to say this is a bug in the core and that the map should be reconstructed for each listener? That's the only way you can guarantee that the map has known contents for each listener. Or I suppose the core could use a Collections.unmodifiableMap() and then if a listener attempts to modify it they'll get a UnsupportedOperationException. Reconstructing the map for each listener seems like the more friendly approach.

[jphipps]

Yep, I am the culprit... I wasn't thinking when I was converting the media object to the mediaid so that I could make the map serializable.. I am fixing the code to copy the map before I use it and should have an updated plugin submitted to sage sometime this morning...

Sorry about that...

Thanks,
Jeff

EDIT: Version 1.0.8 of ortus-mq should be in the repository now. Let me know if you see any other issues...

[Slugger]

Once the user upgraded the Ortus MQ plugin then all the SageAlert issues were immediately resolved. Thanks for the quick turn around.

I opened a bug with Sage to have them take a look at this. I believe they should be reconstructing the map for each listener anyway. Or if not, they should at least make the "do not mod the map" requirement explicit.