External Command Tuner Plugin for Linux

[tpboyce]

Does anyone know what the handle identifies in the call to MacroTune? I thought that it might be an index to which "Remote" is being called, but whether I use remote 1 or remote 2 by changing the remote device, the handle is always 1. I personally would expect it to be a pointer to the remote. Are there any other varients of MacroTune that might not be in this header?

[bcjenkins]

I am using jpwegas' plugin and the execution from SageTV sends CAN_TUNE $REMOTE and the plugin should return OK as a response.

B

[loonsailor]

Originally Posted by bcjenkins

I am using jpwegas' plugin and the execution from SageTV sends CAN_TUNE $REMOTE and the plugin should return OK as a response.

B

I'm using the jpwegas plugin as well, but I don't think that it's been published yet. Anyway, that doesn't answer the question that tpboyce asked, which is about the API from Sage, not from the jpwegas plugin which rationalizes the Sage interface.

There seems to be no real documentation on how Sage does this, only empirical observations. Here is an explanation that I got from jpwegas, paraphrased from a couple of e-mails:

devHandle is supposed to be a way for the plugin to keep track of which "device" was opened, but it's basically useless for our purposes. In my experience, Sage calls OpenDevice just once (always passing in 0 for ComPort), and the value that OpenDevice returns (an int) is later passed as devHandle by Sage to some of the other functions. However, since OpenDevice is only called once per plugin as far as I can tell, devHandle is not useful.

The reason I think devHandle works this way is:

1. I have had various versions of my tuner plugin running for almost 2 years with 3 remotes and it logs every function the plugin calls, including what devHandle is. I have never seen a value other than "1".

2. By default my tuner plugin has always returned "1" (i.e. true) for OpenDevice. I had always assumed that this was what Sage expected (i.e. "success"). However, if I return something else which doesn't really make sense if devHandle is an index, for example "47", then "47" is the value for devHandle for subsequent calls to PlayCommand and MacroTune, even though there are only 3 remotes in the list.

Originally I thought it was an index too, but the way it was behaving just didn't make any sense for that. It may have originally been this way, but I think this is one of the ways that Sage now behaves differently from the original intent of the irtuner design.

In order to support multiple remotes, I worked around this limitation. I had noticed that Sage calls LoadRemotes two different ways: (1) when Sage first starts and (2) before each tune. For (1) Sage passes in a NULL for the pszPathName. For (2), Sage passes the remote name in pszPathName. I believe in the original API pszPathName was suppose to be the remote's config file, but Sage repurposed it to be the remote's name.

After the initial start, every time Sage tunes, it does:
- LoadRemotes (with a remote name)
- CanMacroTune
- PlayCommand or MacroTune

So I save the pszPathName passed into LoadRemotes and then use it in the other functions to decide which remote should be used. Using this method, the plugin can support multiple remotes, and each remote can independently support macro tuning if desired. That is, you can have a mix of remotes, some of which support macro tuning and some which don't.

The scary thing with that method would be if sage is multi-threaded (which it might be since it's in Java) and different threads were changing channels, for multiple recordings starting at the same time. That would result in a race, where the plugin might get two LoadRemotes, and then two MacroTunes, and thus do both MacroTunes on the latter of the two LoadRemotes received. I have no idea if this could happen, but being an old real-time guy, I notice races and they always scare me. However, jpwegas says he's never seen this, and I've been running it for a few weeks and I haven't seen it either.

I tried writing a new tuner plugin - actually an upgrade of the stuckless plugin - but I couldn't get it to work, and after getting frustrated I tried jpwegas' and it works great. I think he'll be publishing it soon.

BTW, the behavior that I saw with LoadRemotes seemed to be slightly different than what jpwegas describes, but his plugin work and mine doesn't, so take that for what its worth.

[bcjenkins]

Good info on the plugin.

FWIW - I am setting up all remotes as macrotune remotes so that I am able to fire off a list of commands at once. By parsing the channel number to individual digits I can prepend and append commands needed to escape a screen saver, "press enter" to speed up the timeout, etc.

PS - The tuning code is on Google code for those brave enough to download and compile. http://code.google.com/p/customsaget...ricTunerPlugin

B

[jchiso]

Does this tool work w v9? I can run it on 7.x installations, but the tuner does not appear as an option on v9. I used the procedure outlined in the installation instructions ...

[stuckless]

The ExternalTunerPlugin is replaced with the GenericTunerPlugin, and the code/documentation is here.

https://github.com/stuckless/GenericTunerPlugin

In the Releases Tab there is a download for it.

https://github.com/stuckless/Generic...lugin/releases

Also, if you are running Docker/SageTV this is already included in the image (along with comskip and a few other things)

[jchiso]

This utility seems to be an embedded tuner, rather than an external launcher, as the other plugin was. Does something like this no longer exist?

[stuckless]

Originally Posted by jchiso

This utility seems to be an embedded tuner, rather than an external launcher, as the other plugin was. Does something like this no longer exist?

Maybe I'm missing the requirements here... GenericTurnerPlugin is a SageTV Tuner Plugin that delegates the tuning "channel changing" to an external script. So you can use this plugin to tune (channel change) anything that that can be scripted. For example, I use it, along with a custom script to integrate with COmmandIR... I think others have used it to integrate with boxes that support IP based tuning, etc.

Is that not what you are looking for? The ExternalTunerPlugin did something different?

[jchiso]

I was asking about the functionality of the earlier incarnation; the External Command Tuner. I copied the 'ExtTunerPlugin.so' file to the Sage directory but the External Command Tuner does not appear as an option when I tried to set up the video source. The prior plugin required a remotes .cfg file that really required only two arguments: one for a script and another for the channel number.

Is the problem that the ExtTunerPlugin.so file does not work on 64-bit systems? I still have it working on 32-bit v7 ...

[jchiso]

Well, I've read through every thread with the terms " ExternalTunerPlugin", "GenericTunerPlugin", and "ExtTunerPlugin.so" and I've not seen a solution to getting the plugin to appear in the list for v9. I guess I actually should have posted this in the OpenSource subforum, since it refers to a v9-specific problem, but I (foolishly) thought the plugin would be unaffected by the release version.

Unfortunately, I was not able to find anyone who mentioned being able to successfully run this plugin with a 64-bit, v9 system. A few people tried and were only able to declare success by rolling back to a 32-bit version of Ubuntu (or whichever distribution they used). I am already at this point, in that I have a v7, 32-bit setup with the External Tuner, but to move forward and be free of the single-license restriction I would like to get this working with v9.

There must be something simple I am overlooking or, more accurately, am not aware. The other .so files in the tuner plugin directory (DirecTV Serial, Firewire, and IRBlaster[?]) appear as choices in the source setup menu, but the ExtTunerPlugin.so does not.

[stuckless]

SageTV v9 is 64bit, so, any tuner plugins will need to be 64bit.

But again, GenericTunerPlugin is doing what you need, from what I can tell. It's called "Generic" because it will simply run a script and handle the commands.

Let's say you have a script, 'changechannel' that accepts the the channel number 1234, you'd call it from the command line like...

# changechannel 1234

To use this with gentuner, you'd install the gentuner tuner, then create your tuning script that call this. You'd likely start with gentuner.IPSTB and copy it to just "gentuner", then around line 34 of that script, you'd replace the wget call with "changechannel $CHANNEL"

and you are done.

https://github.com/stuckless/Generic...uner.IPSTB#L34

The install part of the README talks specifically about where the gentuner scrip needs to go...

Because "gentuner" is a script, you can test all of this from the command line as well, before you attempt to get sagetv to work (in the README as well).

And, if you have issues creating your script, I'm sure people can help with that as well.

At this point, I'm guessing you've spent more time trying to figure out how to NOT use this, rather just test it out

[jchiso]

Originally Posted by stuckless

SageTV v9 is 64bit, so, any tuner plugins will need to be 64bit.

Okay, so it looks like the External Command Tuner Plugin is 32-bit, so it won't work.

Originally Posted by stuckless

But again, GenericTunerPlugin is doing what you need, from what I can tell.

I tried to install this plugin on two different 64-bit systems and I got fatal errors and compilation terminations. No .so file was created.

The problem is not with my script; it's pretty simple and straightforward, I just cannot get the plugin integrated into Sage as an option ...

[stuckless]

Sorry, I posted to a link to the "releases" of gentuner where I thought it was hosted, but that is just the source..

On linux... you can isntall gentuner (64bit) like this...

cd /opt/sagetv/server
wget -O gentuner.tgz https://bintray.com/artifact/download/opensagetv/sagetv-plugins/GenericTunerPluginLinux/gentuner-1.0.1.tgz
tar -zxvf gentuner.tgz
rm -f gentuner.tgz

That will lay down the genetuner pre-compiled code (64bit) into sagetv. From there, you can follow the steps that posted earlier about modifying the script to have it call your tuning command.

BTW, gentuner is installed by default in the Docker image... and I think it should be included in the standard sagetv release, since, it's the only external tuning option available, on linux.

[jchiso]

I got a "permission denied" error on the wget download ...

[KarylFStein]

Originally Posted by jchiso

I got a "permission denied" error on the wget download ...

Do you have permission to write files in the directory you're running the wget?

[jchiso]

Thanks. Re-ran it with 'sudo'. That did not cross my mind. I thought it was a "read" permissions error on the download attempt ...

[wayner]

Originally Posted by jchiso

Thanks. Re-ran it with 'sudo'. That did not cross my mind. I thought it was a "read" permissions error on the download attempt ...

That's kind of my go-to move with Linux - "If it first it does not succeed, try it again with sudo". Probably not a good security practice but it seems to solve a lot of problems.