Android/AndroidTV Placeshifter client (Discussion)

[Fuzzy]

As for the menus, i know you didnt' want to work over what's there, but the ADM implementation in Gemstone supports multiple menu themes. Using that would maintain all the menu configuration options present. There are also icon options for the menu items that are unused in the current theme, but could be utilized nicely on a touch-centric theme (well, they ARE used for the task switched, which I don't think many people use - but I love it!).

[PLUCKYHD]

Originally Posted by Fuzzy

I would think the standard or gemstone ui would be perfectly fine for androidTV or AppleTV. That use scenario is no different than our current scenarios. I only see a slight need for work on the actual mobile touch devices, and most of that would come down to some scaling changes.

Agree to disgree the current UI while it may work on mobile and android it's not a UI that is going to drive more users here (or myself). I love gemstone and the old diamond that was created but to me it doesn't flow correctly on a phone at all. The issue with it on androidtv to me is more of a unification issue in that it's to different from all the other interfaces that users have. (WAF) . My goal in the UI would be what I think other developers ultimate goal is self need followed by drive more users to sage. The more users driven here the more devs that follow.

[tmiranda]

Originally Posted by PLUCKYHD

I have started work on a mobile UI happy to work together if you want? My thinking is it needs to be built for the phone and for the tv (android tv is a bigger use case I believe). I started by nuking all the default menu's to begin with as hacking something together from the existing is less than ideal to me. I have started some prelimary sketch ups of ideas happy to share with you over email if you still have my email. if not hit me up over PM.

I'd love to collaborate with you again I'll email you later.

[wnjj]

Originally Posted by Fuzzy

Unfortunately, SageTV (to my knowledge) does not support click and drag. It was designed for working with a remote control, and button pushes. There would be a lot more work to add a whole new drag mechanism to be able to swipe like you are accustomed to on a touch device.

I looked a little into this. There is currently support for 'keyboard' and 'IR' type commands. It would seem that in a touch-driven world (both desktop and mobile), that extending the core to support a 'touch' interface would make sense. Gestures just don't always plug nicely into keystrokes. I can't imagine it being too difficult to follow the IR model that's already there.

[stuckless]

FYI... Thanks to help from Jeff, I now have a working OpenGL implementation of the miniclient working. Without doing any optimizations (and I have a bit to do), I am seeing 4x-10x increase in performance and the UI is pretty smooth on my phone. (I still need to push to the ATV1 and see what happens there). I think I'm on target to push out an "Alpha2" release this weekend.

[odledm]

Great News! Thanks Stuckless for sticking with it. And Thanks Jeff for helping out. Really interested to see how this plays out.

[tmiranda]

Originally Posted by stuckless

FYI... Thanks to help from Jeff, I now have a working OpenGL implementation of the miniclient working. Without doing any optimizations (and I have a bit to do), I am seeing 4x-10x increase in performance and the UI is pretty smooth on my phone. (I still need to push to the ATV1 and see what happens there). I think I'm on target to push out an "Alpha2" release this weekend.

Thank you Sean and Jeff.

[stuckless]

I did end up posting the code, sooner than I intended, mainly because I needed Jeff's help, and it's hard to help if you can't see the code

https://github.com/OpenSageTV/sagetv-miniclient

The project is divided into 2 projects, "core", and "android". "core" is the core miniclient cient code that handles connections, etc, and the "android" project is the implementation stuff that is specific to Android, where the key part is really the MiniCientGLActivity and the EGLUIManager which does the rendering. The goal of the "core" is facilitate a library that is independent of AWT, so, there is "uibridge" package there that provides a bridge to AWTless environments like Android.

If there are opengl folks in this forum, then feel free to pick apart the code, since I know very little about OpenGL, and I was amazed of how many lines of code it took to actually render a texture (no wonder games take years to create). (I still have to implement shape rendering)

If you look at MiniCientGLActivity you'll see how the entry point to a MiniCient works. Basically need a ServerInfo and a UIManager and pass it to the client... and the rest is complete voodoo, magic, incarnations and spells.

[jm9843]

Originally Posted by stuckless

Without doing any optimizations (and I have a bit to do), I am seeing 4x-10x increase in performance and the UI is pretty smooth on my phone.

Very nice. Based on what I saw of "Alpha1" on the Nvidia Shield Android TV, this kind of boost may put its rendering performance on par with the HD300. If it doesn't exceed it.

[stuckless]

Originally Posted by jm9843

Very nice. Based on what I saw of "Alpha1" on the Nvidia Shield Android TV, this kind of boost may put its rendering performance on par with the HD300. If it doesn't exceed it.

I think we'll eventually reach parity with HD300 (and maybe exceed it). Right now I have some bottlenecks in the code on the opengl side that I know that I have to address at some point. I'm trying to get the point where the UI usable, and then move to Milestone 2 which is get basic video rendering working as well. That's like to take a longer time, but this has been fun

I think once the pieces are hobbled together me (or someone) will need to go back and do some clean up.

[stuckless]

One of nice things about being able to work from home, from time to time, is that I do "fun" stuff during my lunch break

I decided to push the latest build to my Android TV unit and see how it worked. It's much faster than the Canvas implementation, but I'd say, that it's still not as fast as the HD300. That's likely because I need to do some performance tuning, but over all the speed was close to the HD300 which I think is great. I'm also connected via WIFI for the ADT1 unit vs Ethernet for the HD300.

On my phone the performance difference is even more noticeable. I'm also running 1920x1080... I'll play around with lowering the resolution to see if that makes a difference as well. I think the HD300, while it renders at 1080p is not actually creating 1080p buffers, but rather upscaling to 1080p... whereas currently I am creating 1080p buffers and rendering Them.

[Taddeusz]

Originally Posted by stuckless

One of nice things about being able to work from home, from time to time, is that I do "fun" stuff during my lunch break

I decided to push the latest build to my Android TV unit and see how it worked. It's much faster than the Canvas implementation, but I'd say, that it's still not as fast as the HD300. That's likely because I need to do some performance tuning, but over all the speed was close to the HD300 which I think is great. I'm also connected via WIFI for the ADT1 unit vs Ethernet for the HD300.

On my phone the performance difference is even more noticeable. I'm also running 1920x1080... I'll play around with lowering the resolution to see if that makes a difference as well. I think the HD300, while it renders at 1080p is not actually creating 1080p buffers, but rather upscaling to 1080p... whereas currently I am creating 1080p buffers and rendering Them.

Yeah, depending on your firmware the HD300 renders at 1280x720. The older firmwares for the HD300 as well as the older HD200 & HD100 render at a lower resolution. I think 1024xwhatever.

[valnar]

Originally Posted by Narflex

If you do transcoding...there's a few downsides:

1) Reduces quality (although with high enough bitrate H264, this would be negligible)
2) Latency in transport controls (i.e. skipping around is not as fast because the transcoder needs to restart each time you do this)
3) No Smooth Fast Forward or Rewind (technically this could be achieved, but it's very complicated to do it and would require lots of effort)

I agree!..although I just made the mistake of only quoting this post from page 1 without reading the other 8 pages.

Native support for MPEG2 and 1080i for devices that support it are paramount to me. It's one of the most attractive features of the HD300 since skipping around is seamless. I would never move away from an HD300 without it, especially as long as OTA broadcasts stay in MPEG2 format.

[panteragstk]

Very nice work so far. Sean's effort never ceases to amaze. Glad to see Jeff so involved.

The alpha build works just fine on my tetra 3 tablet. Tiny bit slow, but you mentioned that. I'm excited to see development going so quickly.

Thanks again

[tmiranda]

In order to do some STV development I am going to purchase an Android extender. The question is which one?

Sean - Since you have put in so much effort I'd like to know what extender you are most interested in.

[PLUCKYHD]

Originally Posted by tmiranda

In order to do some STV development I am going to purchase an Android extender. The question is which one?

Sean - Since you have put in so much effort I'd like to know what extender you are most interested in.

I wouldn't buy anything but the shield personally for mpeg2 alone

although the nexus has been cheap on group on lately .

[stuckless]

Originally Posted by tmiranda

In order to do some STV development I am going to purchase an Android extender. The question is which one?

Sean - Since you have put in so much effort I'd like to know what extender you are most interested in.

I don't have any mpeg2 content (I think)... so I'm using a developer version of the Google Nexus Player. I haven't really played around too much with the video on it. I know when I was working on the native sagetv android app for Android TV I was able to play back pretty much all of my content on that unit. I actually gave up on it, because it didn't have comskip integration

So, as plucky said, if you have mp2 stuff, you'll want a device that can play that natively without transcoding, and I think the shield will do that. Also the newer Nexus Players from google is "supposed" to have hardware support for mpeg2.

https://www.reddit.com/r/Android/com...g2_decoder_in/

[nyplayer]

Originally Posted by stuckless

I don't have any mpeg2 content (I think)... so I'm using a developer version of the Google Nexus Player. I haven't really played around too much with the video on it. I know when I was working on the native sagetv android app for Android TV I was able to play back pretty much all of my content on that unit. I actually gave up on it, because it didn't have comskip integration

So, as plucky said, if you have mp2 stuff, you'll want a device that can play that natively without transcoding, and I think the shield will do that. Also the newer Nexus Players from google is "supposed" to have hardware support for mpeg2.

https://www.reddit.com/r/Android/com...g2_decoder_in/

Comskip works on my nexus player using Kodi and I can also use the KODI plex plugin as long as you use SMB to access the files directly. So as long as you are using Sage on the same network and accessing the files directly comskip should work.

Also I have no trouble playing the SageTV files using KODI. Without transcoding and comskip works. The Nexus Player is a nice device and I was able to get it at New-Egg for $60.

[stuckless]

Originally Posted by nyplayer

Comskip works on my nexus player using Kodi and I can also use the KODI plex plugin as long as you use SMB to access the files directly. So as long as you are using Sage on the same network and accessing the files directly comskip should work.

Also I have no trouble playing the SageTV files using KODI. Without transcoding and comskip works. The Nexus Player is a nice device and I was able to get it at New-Egg for $60.

Yeah, I installed kodi as well (as a player), but I was trying to get this all to happen within a native Android TV ui... but creating a player that supported comskip was more than i was willing to invest (time wise). Good to know that the standard nexus player works well though. I may end up picking one up, just because the developer player doesn't use a remote, but instead has a controller

[PLUCKYHD]

Ya it's definitely tempting to get a nexus at the prices they are it's all a use case. If you use OTA or any tuner that pulls in mpeg 2 i wouldn't go any route but Shield. if you don't need mpeg 2 then nexus is the winner for sure. Unfortunately my cable company and my OTA are mpeg2 so I require the more expensive option.