MiniClient Information

[Taddeusz]

I've not yet looked at the MiniClient code but I'd like to get an idea of its capabilities. I'm planning on starting a SageTV app for iOS and possibly Apple TV (tvOS). I don't want it to be just a mirror of the Placeshifter. I'd like more of a native interface rather than just the Placeshifter interface on a phone (or tablet).

My question is, can the MiniClient be used to access the API to get information from the server or is it strictly used to create a remote client interface? I'd like to keep things as simple as possible and not have third-party server dependencies (e.g. sagex) but only if that doesn't preclude being able to have a native interface.

Rather than a native app I suppose I could also do a web interface. I realize there is already a mobile web interface but it appears to be effectively abandoned and is not exactly what I would consider modern. It doesn't look great to begin with but also looks horrible on larger devices like iPad.

I may still do an app with sagex dependencies if MiniClient cannot give a native interface.

[stuckless]

Having written an Android App (a couple actually) for SageTV, I actually like the Placeshifter approach vs "native" app with a native look and feel.

As for the miniclient/placeshifter, it is more of a protocol than an API where by the UI is rendered/composited on the server and sent as graphical chunks to the very thin client. The client in turn will send mouse and keyboard events to the server and the server will process those events, and in turn send updates back to the client based on the events. All this happens via a couple of native IP sockets where the payloads are efficient binary blobs.

So, from a web app, you cannot access those apis directly. You could look at writing a WebSocket api bridge, but not 100% sure it would buy you want you want, since it would still be sending you back binary image blobs (for the most part).

Sagex, for the most part, will give you 95% of what you need from a web UI perspective, and I'm not sure (without re-implementing your own web server and API) that you'll get to the point of doing this without plugins.

If you are looking at the web option, then I'd take a serious look at Polymer. I've given this some thoughts as well, and if I were to re-do BMT web UI, I'd use Polymer, and if it's done right, it can run smoothly on a desktop and mobile, auto-adjusting the layouts when on mobile.

If you do go with sagex, feel free to ask questions... I'd be happy to help.

[Taddeusz]

MiniClient on tablet or TV connected devices might not be that bad. However I think it would get crowded on a phone sized screen unless you used a special mobile STV. I just envision trying to poke at the Recordings screen on a phone being a pain.

Come to think of it, for the MiniClient to be used on mobile we would somehow need to translate touch gestures like scrolling. The scrollbar would also be kind of useless on mobile as an interactive control. More useful as a position indicator.

Having used Placeshifter across RDP on my iPad I can tell you from experience that using it on touch is a little awkward. This is my main reason for wanting to do native. I feel that having a native interface would improve usability and provide a iOS user a comfortable way of accessing SageTV from their iDevice.

[stuckless]

Originally Posted by Taddeusz

MiniClient on tablet or TV connected devices might not be that bad. However I think it would get crowded on a phone sized screen unless you used a special mobile STV. I just envision trying to poke at the Recordings screen on a phone being a pain.

Come to think of it, for the MiniClient to be used on mobile we would somehow need to translate touch gestures like scrolling. The scrollbar would also be kind of useless on mobile as an interactive control. More useful as a position indicator.

Having used Placeshifter across RDP on my iPad I can tell you from experience that using it on touch is a little awkward. This is my main reason for wanting to do native. I feel that having a native interface would improve usability and provide a iOS user a comfortable way of accessing SageTV from their iDevice.

Yeah, I agree... the phone would be crowded... I suggested that someone create a Mobile STV, since I can't do that.

As for the mouse to touch events... certainly the touch to click would be easy, but also the Placeshifter protocol supports mouse-wheel and mouse motion events. I suspect that vertical up down gestures can be translated into mouse wheel simulated events. Or, worse case scenario, we udpate SageTV core to support gestures on the back end. For TV, it suspect it will be pretty easy since the remote buttons can be mapped to keyboard events.

[Fuzzy]

I also feel miniclient would still be the best approach for a mobile platform, with just a new mobile centric STV. This could leverage many already existing concepts, like the ADM menu manager, fanart libraries, and even the Phoenix/Gemstone views much easier than trying to implement all of this on the front end. It would also allow the same 'mobile' stv to be utilized on any mobile platform we extend miniclient to.

Plus, the porting of miniclient (which is a very simple protocol) is likely the quickest approach to get a working system. Even if it had to be written completely from scratch, there are two working miniclient sources to duplicate it from, one Java, and one C. Essentially, you need to have a system where you can decode video to a specific region of the screen, you need to be able to draw graphic chunks to the screen, you need to handle inputs, and you need to have a network layer to transfer this information to and from the server. You would not need to implement any metadata information, database management, etc.

[Narflex]

I would also recommend the Placeshifter approach; and ideally with a modified STV. When we did it before; we had special touch actions correlate to different events. Like a swipe with 2 fingers corresponded to a paging command. And then a triple touch was the Home command. But this was far from obvious for anybody who would have used it.