New tools for Studio users

[beelzerob]

So far so good....

I am able to get a list of all of the recorded shows, and then I send that list to CQC, which it displays. You can then select a show on the list, and I send back to Sage the index into the list.

What I'd like to do (at this point) is then Play that selected index. So, what I tried to do is just use MediaPlayerAPI.Watch(), and I passed it in the mediafile from the list I had saved, at the passed in index.

Watch(mediafile) returns an object, which is either true if it worked, or a "localized error message" of it didn't. Because it didn't start playing the selected show, I assumed it was an error. So, I printed the object as a string, and it was "sage.e$e@a415a3".

Any idea how I can make that localized error message more understandable? Or, why my passed in MediaFile isn't working? Or is there a smarter way to tell Sage to play a particular showing/airing/mediafile?

[GKusnick]

Watch() is how you start playback. I don't know of another way to do it.

There's another thread that talks about the objects returned by Watch(), but the upshot is that nobody seems to have a good idea of how to deal with them from Java.

As to why your call to Watch() isn't working, you might try checking your debug logs. But now we're starting to get pretty far off topic from Studio Tools, so further debugging of that issue might best be done in another thread.

[alon24]

Hi,
You state that the code should work with java 1.5, but i see in the code that in Hook.java you use:

public boolean importData(TransferHandler.TransferSupport support)

and TransferHandler.TransferSupport is only from java 1.6 .

Java 1.6 is giving me a hard time, and I would like to not use it right now.
Is there a way to go around this, and be able to use java 1.5?
(I realize its a change in code, and will need to wait -if ever, for a new version).

[GKusnick]

You're right, it looks like a 1.6 dependency snuck in there somehow (even though I always work from the 1.5 Javadocs). I'll have to see what can be done about that. I can probably recode it for 1.5 compatibility, but at the moment I don't have a timetable for when the next release might be.

[BobPhoenix]

Is it just me or is this not compatible with 6.2.4 beta?

[Opus4]

You might need to specify which part you are having problems with... the things I use in Studio have been working for me all along.

- Andy

[BobPhoenix]

Well it doesn't look like it is even loading no menu items no entries in the log. But it lists in the system info as having been.

Nevermind stupid error I uninstalled Java and am back to an incompatible version.

[evilpenguin]

Hey Greg,

I'm modifying my STVi to use your import plug-in and I'm having trouble with one reference. Any thoughts would be greatly appreciated.

Reference:

backref>>0@Menu:Add Advanced Record/Panel:RecordOptions/Conditional:Frequency == 1/Panel:RecOption/Conditional:GetServerProperty("sagemc&slash;use_standard_compression", true)/Branch:false/Action:"REM link for compression STVi"

Path Reported by Copy Path:

Menu:Add Advanced Record/Panel:RecordOptions/Conditional:Frequency == 1/Panel:RecOption/Conditional:GetServerProperty("sagemc&slash;use_standard_compression", true)/Branch:false/Action:"REM link for compression STVi"

And I've attached a picture of the actual link point.

Thanks

[GKusnick]

The path is ambiguous because of the duplicate Ifs and all the identically-named RecOption panels. The path-decoding logic is fairly dumb and doesn't handle that case very well; it expects the names to be unambiguous.

I can look into making it smarter, e.g. by trying all the matching children until it finds one that works, instead of qutting after the first failure. But a quicker and better solution might be for Dirk to collect all such dummy link points under some unambiguous top-level widget, and then reference them from the point of actual use. That way your backref paths would be a lot shorter, and less prone to breakage if he rearranges his code.

[dflachbart]

Originally Posted by GKusnick

But a quicker and better solution might be for Dirk to collect all such dummy link points under some unambiguous top-level widget, and then reference them from the point of actual use. That way your backref paths would be a lot shorter, and less prone to breakage if he rearranges his code.

Makes a lot of sense, Greg. EP, I'll update the STV for this tonight.

Dirk

[evilpenguin]

Originally Posted by flachbar

Makes a lot of sense, Greg. EP, I'll update the STV for this tonight.

Dirk

Received updated STV and everything is working great, thanks guys.

[evilpenguin]

Hey Greg,

Would it be possible to manually setup conditionals in my STVi such that if the STV is SageMC it imports one menu where as if its the default STV it imports another?

Thanks,
Scott

[GKusnick]

Sage always imports all the menus defined in the STVI file. I don't have any control over that. (Well, I could write a whole new importer to parse the file and conditionally create the widgets. But then, so could you.)

But of course importing the menus isn't the whole story. The imported menus still have to be hooked up to existing menus, and you can put whatever conditional code you like in your STVImported hook to accomplish that.

If you're using the automatic ProcessImport code in my tools (which I presume is why you're asking on this thread), then I'm not sure any conditional code would be necessary. If the backref path is found, the code will be hooked up. If not, not. So it seems like all you would have to do is set up the right backrefs to the two different STVs and the right thing will happen in each case. You'd have to set up those backrefs manually, though, since Export As STVI works only in the context of the current STV.

Or is that your question? I.e. how do you set up backrefs manually? My advice would be to study some automatically generated backrefs to get the basic structure, and then use the Copy Widget Path command to get the actual paths you want.

That said, this sounds like a pretty laborious way to do things. I guess if I were doing it, I'd try to structure it as three separate STVIs: one that hooks into the default STV and does nothing but define another set of STV-independent hooks, a second that does the same for SageMC, and a third that contains the actual implementation and hooks into the common hooks defined by the two "compatibility layer" STVIs. Each of those three can then be maintained using the automatic tools without having to manually futz with backref paths.

[stuckless]

I've added the StudoTools, and I see the "Plugins" menu. When I select "Manage" I get a message "No studio plugins were found". After reviewing the sagetv_0.txt log file, I noticed this exception.

Exception chain:
java.lang.NullPointerException
Stack trace:
gkusnick.sagetv.studio.Hook.FindMenus [Hook.java line 754]
gkusnick.sagetv.studio.Hook.<init> [Hook.java line 52]
gkusnick.sagetv.studio.Inject.HookStudioFrame [Inject.java line 111]
gkusnick.sagetv.studio.Inject.access$200 [Inject.java line 22]

Exception chain:
java.lang.NullPointerException
Stack trace:
gkusnick.sagetv.studio.Hook.FindMenus [Hook.java line 754]
gkusnick.sagetv.studio.Hook.<init> [Hook.java line 52]
gkusnick.sagetv.studio.Inject.HookStudioFrame [Inject.java line 111]
gkusnick.sagetv.studio.Inject.access$200 [Inject.java line 22]

Exception chain:
java.awt.IllegalComponentStateException: component must be showing on the screen to determine its location
Stack trace:
java.awt.Component.getLocationOnScreen_NoTreeLock [Component.java line 1800]
java.awt.Component.getLocationOnScreen [Component.java line 1774]
sage.ae.a [null line -1]
sage.f.a [null line -1]
sage.f.mouseReleased [null line -1]
gkusnick.sagetv.studio.Hook.FindMenus [Hook.java line 759]
gkusnick.sagetv.studio.Hook.<init> [Hook.java line 52]
gkusnick.sagetv.studio.Inject.HookStudioFrame [Inject.java line 111]
gkusnick.sagetv.studio.Inject.access$200 [Inject.java line 22]

I'm running linux (Ubunut 7.04). Java 1.6. Sage client and Server both running the same box. Any help appreciated.

[GKusnick]

It looks like it's breaking in some tricky code I wrote to get a reference to the right-click popup menu by simulating a right mouse click at init time. Apparently this code isn't working for you, perhaps because right-click isn't the appropriate popup trigger event on your platform, or because the mouse buttons are numbered differently, or something along those lines. (So much for "write once, run anywhere".)

I'm not a Linux user myself and don't have a way of testing or debugging on that platform. In fact you may be the first person to try these tools on Linux. Source is included in the zip file if you want to try tinkering with that code yourself to generate the correct popup trigger.

[stuckless]

Thanks. I looked at the code. I'll check to see if I can provide a fix for Linux. Just wanted to check to see if anyone else has had the problem and fixed it first.

Is there a public cvs repository for the code? If not, do you want me to send you a patch or complete codebase or nothing at all?

- Sean

[GKusnick]

No, there's no public repository. Hopefully any fix you come up with will be no more than a couple of lines of code, and you can just post the change here or PM it to me for inclusion in the next release.

[stuckless]

Greg,

The fix to make your tools work in linux are trivial, so i'll post them here and you can put it back into your original codebase.

In Hook.java, 2 small changes....

private java.util.List<String> LszScanForPlugins() throws java.io.FileNotFoundException, java.io.IOException {

final Log.Block block = log.BlockEnter("ScanForPlugins");

java.util.List<String> lszPlugin = new java.util.ArrayList<String>();

String[] rgszClasspath = java.lang.management.ManagementFactory.getRuntimeMXBean().getClassPath().split(File.pathSeparator);
for (String sz : rgszClasspath) {

// Search only .jar files in the SageTV/JARs directory.
if (sz.startsWith("JARs"+File.separator) && sz.endsWith(".jar"))
ScanJarForPlugins(lszPlugin, sz);

}

block.Exit();
return lszPlugin;

}

The first change, replaces ";" with File.pathSeparator. File.pathSeparator is the cross platform string that resolves to ";" on windows, and ":" on unix.

The second change was replacing "JARs\\" with "JARs"+File.separator. File.separtor is the cross platform string that resolves to "\" on windows and "/" on unix.

These changes should have no impact on your existing windows users.

Thanks for the great toolset. I look forward to utilzing them.

--Sean.

[MeInMaui]

Hi Greg,

I have a quick question. As part of an STVi import, I want to add custom listeners to the 'Global' theme, but I have no a-priori knowledge of whether or not the 'Global' theme exists in the STV. (It doesn't exist in the base version, but it could be added by another import)

Since there can be only one 'Global' theme, what would be your recommendation for creating the theme if it doesn't exist and then adding the listeners? My first thought is that this might be handled the same way you handle adding hooks (where the hooks are created on the fly at import time if necessary), but there wasn't any mention of this in the documentation. I'm guessing the only alternative would be to put the logic into the STVImported hook the old fashioned way.

I would appreciate any advice you can give.

Aloha,
Mike

P.S. Thanks for these indespensible tools!!!

[GKusnick]

No, there's no logic in place to implicitly create the Global theme. Here's what I'd suggest as a workaround:

1. Create the Global theme manually in the stock STV and link your listeners to it using the usual backref mechanism.

2. Put code into your STVImported hook to check for the Global theme and create it if not present (but don't add any additional logic to link up your listeners).

3. Export As STVI.

4. Load up the generated STVI for editing and manually move your check-and-create code up to before the call to ProcessImport. That way when ProcessImport runs, the Global theme is guaranteed to exist and your backref links will link up properly.

5. Remember to delete the spurious Main Menu before saving.

Disclaimer: I haven't actually tried this, but it seems like something along these lines ought to work, if you don't mind hand-massaging the STVI after it's been generated.