"Accessible" TV Interface via TV Portal?

[Black Hole]

(This thread has been split from where it started)

CF's Webshell doesn't use the documented port 4200, just 80 as normal. If you use that, you can get a Webshell page displayed in the TV Portal, and auto-magically the PIN entry comes with the RC data entry widget that everyone will know from setting WiFi passwords, etc. But I couldn't find an easy way to get it back, so although I could display the telnet menu there was no way to select any of the options. Less critically and presumably fixable, the cursor was shown several characters to the left of its correct position, and the font was only really readable from less than two screen widths away. So clearly there is also some scope for experimentation with the entire WebIf. However being able to get the telnet menu up on the screen and enable the one-shot commands, even without cli, could be very useful.

<snip>

Query: does this provide scope to build an ultra-accessible user interface just for normal TV?

Example: a page presents on "TV PORTAL" command, showing nine boxes on-screen pre-loaded with the main channels, with one highlighted. Use cursors to move the highlight, press OK to select.

Example: The screen shows current channel and current programme. Press cursors to index channel, press OK to select.

 

[/df]

Query: does this provide scope to build an ultra-accessible user interface just for normal TV? If so, I'll pursue this in a dedicated thread.

Example: a page presents on "TV PORTAL" command, showing nine boxes on-screen pre-loaded with the main channels, with one highlighted. Use cursors to move the highlight, press OK to select.

I think this could be possible.

In theory one should be able to write an entire UI for selecting broadcast channels and playing media using JavaScript (hbbTV), but that would need a lot of research on possibly incomplete APIs. Instead, using new-portal, a local portal app could be installed for each main channel and each would have to have some way of exiting the Portal and passing back a channel selection command: that would have to be developed.

Example: The screen shows current channel and current programme. Press cursors to index channel, press OK to select.

It might be possible to create a special-purpose portal based on new-portal to do this.

 

[Black Hole]

I was thinking to simply to inject through ir, in response to "clicks".

 

[/df]

I presume that the fake commands would go to the Portal like the actual ones, so you wouldn't be able to change anything about the underlying system state, except Exit the Portal.

 

[Black Hole]

Couldn't it exit the portal and then (for example) change channel?

 

[/df]

The problem is how to persist the selected channel across exiting the Portal.

A local portal app could control the system by invoking a Jim CGI script through the lighttpd web server, similar to what happens when you click "Perform decryption" in the WebIf>Opt+>Decrypt dialogue. Parameters, such as selected channel number, would be sent in the URL using the familiar ?param1=value1&param2=value2 suffix. For instance, such a script could send IR Exit (to close the Portal), wait for it to close, then send IR <channel num>.

 

[prpr]

The problem is how to persist the selected channel across exiting the Portal.

How does it know where to go back to anyway?
Perhaps it remembers where it came from, or perhaps it re-reads it from the setup.db database.
Might be worth a test.

 

[Black Hole]

Okay, I admit to being unfamiliar with exactly how all this works and what the limitations are, but my original naive thinking was that if we can build our own locally-hosted set of web pages and present them by repurposing TV Portal (the original function would not need to be retained), and get some kind of user interaction via the remote control handset, it ought to be possible to trigger sequences of events by stuffing the ir command buffer.

Are you saying that the portal processes operate in isolation, and cannot affect the system outside the portal? Surely there is a way to spawn another process with its own permissions and it's own independent "life", or queue some data somewhere which gets enacted on "exit"?

Yes, it would be much cleaner if we had the APIs so that it was seamless, but in their absence just automating the IR command sequences would be a start.

 

[/df]

The Portal is like a web browser client subroutine called in the set-top binary. There may possibly be different versions according to the Humax firmware version; I'm looking at the 1.03 versions and their subversionenhancement by new-portal. Each Portal app is just some JavaScript in, or loaded from, the Portal web page.

The humaxtv set-top binary is linked with a library version of the Opera browser. This is the proper Opera browser with the Presto rendering engine before they gave up and made it a Chrome clone.

The Opera browser is called and loads the URL in /usr/browser/opera_dir/url/url.txt. When Opera exits (if there's a way for an app to do that -- maybe window.close() works here) or the system sees the Exit IR command, the browser is closed and the system goes back to what it was showing before. The command nm -D /usr/bin/humaxtv | grep 'U op_' shows all the informatively named ways in which the set-top binary controls the browser.

(Possibly other parts of the system UI are created as web pages: there seem to be Open IPTV and hbbTV interfaces provided and called by the set-top binary.)

So with new-portal, the system opens the provided web page http://localhost/portal/newPortal.html with its included and loaded JS. At this point user input including fake IR commands is being handled by the Portal's browser instance.

In the Portal context, programming functions available are limited to JS. (But this might not be very limiting if one knew how to instantiate and manipulate the objects that appear to be available in the /usr/browser/lib directory.) Basically we can rewrite the web page, respond to UI actions, and so on, but to control the set-top box itself, write files, access databases, etc, the page JS has to call functions from elsewhere. One way is to use some sort of JS-wrapped external object as in the OIPF/hbbTV stuff, similar to invoking Adobe Flash Player. As I suggested above, a simpler general solution in this (HD/R CF, WebIf) context is to define an API comprising the needed operations, implement each operation with a Jim CGI script, and invoke the operation by GETting the corresponding CGI script. For example, the directory /mod/webif/html/sched/rpc contains such operations used in the WebIf Schedule function.

 

[Black Hole]

Not so easy then. Ho hum. Plan B is a cheap Android tablet running a customised web page into ir.

 

[MymsMan]

Not so easy then. Ho hum. Plan B is a cheap Android tablet running a customised web page into ir.

That definitely sounds doable without requiring significant programming skills, essentially you just want the channel shortcuts part of the ir web page without the rest,

Another option would a smart speaker if your supported user would be OK talking to the telly!

 

[Black Hole]

I've discovered one of the problems: supported user holds the buttons down too long. Maybe there's a way to conquer that through ir.

 

[prpr]

supported user holds the buttons down too long.

This appears to be a common problem. Rewind and FF is a real comedy (*) as it oscillates about where you were without ever getting to where you wanted to be.

* For some value, not very high, of comedy.

 

[EEPhil]

Rewind and FF is a real comedy (*) as it oscillates about where you were without ever getting to where you wanted to be.

I find that you can say the same about skip forward/back. Frustrating is the kindest word I'd use, not comedy.