I would love to start developing packages but where to start

OS1

New Member
I've looked at the getting started guide but I would like to go further than Hello World. I know there's no API but it's clear you can do a lot more with packages, but how! Do I need to trawl through the Humax open source downloads? Please could someone give me a leg up?

Thanks,
 
Not sure what you have read up to now but if you haven't had a look at the WiKi Create packages page, it's worth a look, link HERE, this page will show you how to construct a package for the Humax and also how to examine the packages in the package list HERE, there is also the WiKi Compile Software page HERE
 
  • Like
Reactions: OS1
What sort of things do you want to develop?
The main types of customisations that we have are:
  • The web interface (which is traditional HTML, CSS, Javascript etc. with the server-side scripting language being Jim (a lightweight TCL variant). Any web development skills should transfer over fairly easily. The web interface provides object-oriented APIs into several things like the schedule, the EPG etc.
  • Third party packages built for the Humax such as Samba, Transmission etc.;
  • Some low-level extensions which hook into the Humax software via interposition or ptrace. They tend to require a good level of experience with assembly language to develop.
 
  • Like
Reactions: OS1
Is it possible to display a popup over the current tv show - with image - from a custom application?

My thoughts are to install ncid, this gets the caller id from an incoming phone call - (can be found in sourceforge projects) - but with some changes, so that if a number is know display an image.

Thanks
 
thanks, that saved some time, I'll just use a rasp pi instead. It would have been nice just to have one box do everything.
 
They do, but this was to be for my dear silver haired old mother - although she does use linux - who does not use a mobile and has the tv on all day
 
When you say "no" could, for example, the user load the TV portal / custom portal and then a custom app on that, though not necessarily that practical... and no doubt stops changing channel etc?

Likewise is there any way into the MHEG code related to a channel, i.e can the data about a channel be amended maybe to point "Channel A" to MHEG code cached locally? Also there is some trigger which produces those helpful messages about re-tunes that pop up etc. from the broadcasters, are those accessible?
 
You could do it the portal way, and map the channel/volume buttons so that it's not locked out.

Mheg option is a no go afaik.


Sent from my iPhone using Tapatalk
 
Thinking out loud:

If your user doesn't use the TV Portal at all, I guess it would be possible to develop your own custom portal which performed this function only: pop up a screen overlay showing whatever you want, and trigger it with a web interface injection to the ir package simulating a TV Portal button press. The information for the pop-up could be sourced from the system which is interfacing the telephone line (which won't be the Humax!) running a web server (which would also source the ir injection). The user would acknowledge the pop-up and return to normal operation by pressing the Exit button.

As said above, the portal is the only means we have to get anything onto the TV screen. There are two versions of web browser running on HDR-FOX, and they have incompatible requirements, so make sure you know which one you are going to experiment with before you start - either 1.02.xx or 1.03.xx.
 
Downside would be that the box would display "TV PORTAL" all the time regardless of channel - unless you also pass the data across.

I would keep it as an app rather than take over the entire portal - you're asking for trouble doing that, especially debugging.
 
Downside would be that the box would display "TV PORTAL" all the time regardless of channel - unless you also pass the data across.
Not in my scheme it wouldn't. The phone rings, the CLI detector sends a "TV Portal" injection to the ir package via a TCP/IP request to /plugin/ir/remote.jim, and only then does the Humax enter TV Portal mode. The user then cancels TV Portal mode by acknowledging the pop-up with the Exit button.

I would keep it as an app rather than take over the entire portal - you're asking for trouble doing that, especially debugging.
I don't understand that. I had a play in that area (1.02.xx) and found I could substitute my own HTML in place of the standard Humax redirection to the web service, so I see no difficulty in creating and debugging an intermediate portal service web page on the Humax itself, or redirecting the portal access straight to a server on the external interface to the CLI system. Having it as an app rather than the entire portal allows for the other apps to be accessed, but would require more jiggery-pokery to start it up.
 
Not in my scheme it wouldn't. The phone rings, the CLI detector sends a "TV Portal" injection to the ir package via a TCP/IP request to /plugin/ir/remote.jim, and only then does the Humax enter TV Portal mode. The user then cancels TV Portal mode by acknowledging the pop-up with the Exit button.
Yes I'll give you that, but you are losing the entire portal for one function. If that's what you want then fine, but I don't think it'll catch on.

I don't understand that. I had a play in that area (1.02.xx) and found I could substitute my own HTML in place of the standard Humax redirection to the web service, so I see no difficulty in creating and debugging an intermediate portal service web page on the Humax itself, or redirecting the portal access straight to a server on the external interface to the CLI system.
Go on then..
 
Hey, I'm just giving the OP options! It might not be all that straight-forward, but it sounds entirely do-able using some kind of RPi or PIC system externally to intercept the CLI and then interface with the Humax over Ethernet/WiFi.
 
Sounds perfectly plausible to me. Could also display it on the front panel (HDR-Fox T2).
 
Here's an idea: same kind of technique to respond to a doorbell and pop up a picture from a web cam.
 
These are both in XBMC, so a lot of the code can just be ripped from the python packages.
I still say a portal app would be preferable to a portal replacement.
 
I suppose it would only be one extra ir injection, but can the apps be made to run with live TV in the background? I know you can with the main portal page. What would happen if the user was already using the portal when the interrupt came in? For the sake of resolving this type of asynchronous problem it is probably better (my opinion, obviously) to completely replace the portal. Who says the OP's silver-haired old mother uses the portal at all?

I have thought of another hiccup: this isn't going to work if the user is playing a recording at the time.
 
Back
Top