Studio Tools for SageTV V7

[stuckless]

Originally Posted by 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.

hmmm... I was wrestling with an issue this past weekend where the MediaFile was looking like it was being converted to an int.... (which looks like what your particular problem was as well)... I never thought that another plugin could modify the contents of the Map... there's goes a perfectly good weekend

[GKusnick]

As a matter of general programming style, it's usually considered bad form for a function to modify the parameters passed in to it, even if they're not shared references. You generally want to preserve a record of how the function was invoked for debugging purposes.

That said, we do have a fair number of amateurs here who aren't familiar with all the niceties of gentlemanly programming. So it's probably appropriate for the core to be a bit more defensive in guarding against plugin misbehavior.

[Slugger]

Yeah, those new to Java may not realize that an object as an arg is just a reference (pointer for our C++ friends) to the object so modifying the object in the method indeed modifies the caller's reference as well, whereas with primitives as args, you're dealing with a copy of the actual value so modifying that locally doesn't affect the caller's value. (Remember, a copy of a reference to an obj is still referencing the same obj, which is why you end up modifying the caller's object). And as GKusnick says, it's best to simply not modify the args of a method unless you're well aware of what the side effects are. (And the core still needs to protect the arg map/reconstruct it for each listener invocation anyway because even the most seasoned Java coders can muck up the map and not realize it leaving the rest of us to try and figure out what's going on.)

Something else I've been thinking about since this was discovered is, should a listener be able to modify an actual object (i.e. the MediaFile instance itself) before all listeners are invoked? The Sage API makes no mention of what state the object will be in when the listener is invoked so, technically, I suppose there's no right or wrong answer here, but there's a race condition created by the event queue thread in that if Plugin A is going to take the MediaFile arg and do something with it (maybe even delete it for whatever reason) then Plugin B is going to end up with a reference to a non-existent MediaFile object when it gets invoked. Even worse is that it's not consistent because if Plugin B happens to register for the event before Plugin A next time (maybe Plugin A registers/unregisters itself dynamically at run time) then now Plugin B will get a valid MediaFile obj to handle before Plugin A gets a hold of it and deletes. Talk about a debug nightmare!! I don't think there's a good solution here other than to warn plugin authors that you cannot know/trust the state of the args when you receive them to process, but the core can (and should) guarantee the state and contents of the arg map it's passing to the invoked event listeners.

[tmiranda]

Us (We?) noobs are learning all the time thanks to you pros

To be fair to Sage, I looked at the comments for the sageEvent() method and it clearly says that the args should not be modified.

[Slugger]

I'm running Tools Lib 1.2.31, which says is current for core 7.0.12, but it's missing the PluginAPI.IsPluginStartupComplete() call, which, according to the release notes, was introduced in core 7.0.12. Just wondering if this call made its way into your 1.3 wrappers? I'm just calling the underlying SageTV.api() call for this method because I don't want 7.0.12 users to have to move to 7.0.15 just so I can get this one wrapped call. But just thought I'd mention it in case the call still doesn't appear in 1.3 of your wrappers.

[GKusnick]

According to my zip archives and SVN logs, IsPluginStartupComplete() is in 1.2.31, unless the JAR somehow got out of sync with the source.

In any case, it's definitely in 1.3.

[stuckless]

Greg, I'm not sure if I mentioned this before... But in Linux, I can't install your tools because it requires "DesktopOnly". I realize that in most cases, it is a DesktopOnly plugin, but in linux, the server is the desktop... and the only way to access the server in linux is via the placeshifter (or a windows desktop). Is there any chance that you'd change the restriction on the plugin to allow it to be installed on Linux?

If there are other Linux devs... How are you installing Greg's tools?

[PLUCKYHD]

Originally Posted by stuckless

If there are other Linux devs... How are you installing Greg's tools?

The better question is what the heck is stuckless doing in studio.

[stuckless]

Originally Posted by PLUCKYHD

The better question is what the heck is stuckless doing in studio.

Not very much... that much is certain To be honest, I just want to make some small changes, ie, use phoenix_media_GetFormattedTitle, and a simple smart sorter... But I need to "find" the locations that need updating... from what I recall, I think Greg's tools have better "Find" abiities than the core studio... especially since "Find" in core studio never returns any results for me (I have tried to simply do this using vim, but the Xml is a little hard to read outside of studio, although it's hard enough for me to read it in studio as well )

[tmiranda]

Originally Posted by stuckless

If there are other Linux devs... How are you installing Greg's tools?

I do all Studio work on a Windows SageClient, but I'm hoping Greg will make the tools available on Linux as well.

[GKusnick]

Originally Posted by stuckless

Greg, I'm not sure if I mentioned this before... But in Linux, I can't install your tools because it requires "DesktopOnly". I realize that in most cases, it is a DesktopOnly plugin, but in linux, the server is the desktop... and the only way to access the server in linux is via the placeshifter (or a windows desktop). Is there any chance that you'd change the restriction on the plugin to allow it to be installed on Linux?

Yes, this has come up before, and as I recall it has to be Desktop in order to install properly on Windows in service mode. I'll do some more testing this afternoon, but I'm not sure I can fix it for you without breaking it for someone else.

As a workaround, here's a modified manifest with Desktop set to false. Paste this into SageTVPluginsDev.xml and it should work for you.

[stuckless]

Originally Posted by GKusnick

Yes, this has come up before, and as I recall it has to be Desktop in order to install properly on Windows in service mode. I'll do some more testing this afternoon, but I'm not sure I can fix it for you without breaking it for someone else.

As a workaround, here's a modified manifest with Desktop set to false. Paste this into SageTVPluginsDev.xml and it should work for you.

Thanks Greg. That was going to be my work around plan, if you were not able to make the change, so thanks for providing it.

[stuckless]

Just an FYI... When I added Greg's plugin to dev plugins xml, SageTV still would not let me install it. It's almost as if sagetv "merged" the data of the two, and it did not set the Desktop to false. I ended up renaming greg's plugins in the xml (I just added an 'x' to the plugin id), and then I could install it... and yeah, the search facilities in Greg's plugin is much better than the standard, which I suspected.

[PLUCKYHD]

Originally Posted by stuckless

Just an FYI... When I added Greg's plugin to dev plugins xml, SageTV still would not let me install it. It's almost as if sagetv "merged" the data of the two, and it did not set the Desktop to false. I ended up renaming greg's plugins in the xml (I just added an 'x' to the plugin id), and then I could install it... and yeah, the search facilities in Greg's plugin is much better than the standard, which I suspected.

Agreed it Is 100% better and it's find and replace by widget type is unreplaceable to me.

Thanks Greg for this addin !!

[GKusnick]

Originally Posted by stuckless

Just an FYI... When I added Greg's plugin to dev plugins xml, SageTV still would not let me install it. It's almost as if sagetv "merged" the data of the two, and it did not set the Desktop to false.

Whoops, I guess I forgot to bump the version number in the Dev manifest, so it failed to override the one in the repository. I've updated the attachment in the earlier post with new version numbers.

[Fonceur]

For the MediaFile methods that return a MetaImage (like GetFullImage or GetThumbnail), you are returning an Object. Is there an easy way to get to the underlying image? Essentially, I'd like to get the bitmap and convert it to a byte array to send over TCP. Since I want those for photos/videos/recordings/songs/etc., it gets tricky just using the filename from airing.GetMediaFileForAiring().GetSegmentFiles()[0]...

[GKusnick]

As a rule, my wrapper methods return Objects wherever the documentation indicates a return type of sage.T (for some value of T). This is because the vast majority of sage.T types are obfuscated and not accessible to Java plugins. As far as I can tell, sage.MetaImage appears to be one of the obfuscated types.

If it turns out not to be obfuscated, you're free to cast the returned Object to sage.MetaImage and call whatever methods it exposes. But I don't know what those methods are, and in any case they're beyond the scope of my wrapper library.

I've looked at changing my wrapper generator to allow unobfuscated types through explicitly instead of casting them all to Object. However that would change the type signature of my library in a way that would require dependent plugins to be recompiled, so I chose not to go ahead with that. So if you can find an unobfuscated definition of sage.MetaImage, use the cast trick above as a workaround.

[Fonceur]

OK thanks, I was afraid that might be the answer.

[GKusnick]

Just uploaded version 1.4.6 of the Tools Library with a refresh of the API wrappers for SageTV V7.1.5.

[GKusnick]

V1.4.7 uploaded to correct some misnamed method wrappers.