AppleTV 4

[Taddeusz]

Originally Posted by stuckless

While the placeshifter protocol is not overly complicated, it's by no means trivial. And certainly, the rendering part is very complicated, especially if you don't know OpenGL (which I don't -- very well)

Depending on how you feel about writing in Java... you can leverage the existing Java code. RoboVM will take java byte code and transpile it into native iOS instruction code.

In the project that I'm using.. There is a "core" project that contains all the vanilla sagetv io and processing, and there is an "android" project. The Android project is quite small, since it only has to create a server selector, and then a Rendering view to render the client. All the "real" work happens in the Core, and it delegates the rendering to the hardware specific Renderer. I was using this setup to do most of my testing on a PC before moving on to an Android specific implementation.

It is possible to create an "ios" project with the specific implementation for IOS and leverage all the shared code, from the "core". The RoboVM bindings have all the NS widget bindings so you can create a native UI from Java code. What you would need to do natively, is build a Server Selector view, and then a GL Rendering view that implements in the Rendering interface (and obviously pull it together by setting up and tearing down the views, etc). (Still not trivial, but you are shielded from all the sagetv communication code, etc)

In this scenario... this is not Java running on a VM running on iOS... this is native arm code running on iOS, directly on the CPU, no VM at all.

If you don't know Java but you do know Obj-C... then maybe j2objc would be a better choice.

I know some Java. I've written a simple Android app. I'm certainly stronger in Objective C and now learning Swift. The RoboVM looks pretty neat but I don't know that I want to drop $20/mo to use it.

[stuckless]

Originally Posted by Taddeusz

I know some Java. I've written a simple Android app. I'm certainly stronger in Objective C and now learning Swift. The RoboVM looks pretty neat but I don't know that I want to drop $20/mo to use it.

RoboVM is free and open source, even. The $20/month is if you want to use their support and additional tools (ie, they have debbugger and a "robovm studio" app). I used it free in a game I did, no issues there.

But, as I said, if you are stronger in Obj-C, then I'd go the j2objc route and/or just re-implement the code manually.

[Taddeusz]

Originally Posted by stuckless

RoboVM is free and open source, even. The $20/month is if you want to use their support and additional tools (ie, they have debbugger and a "robovm studio" app). I used it free in a game I did, no issues there.

But, as I said, if you are stronger in Obj-C, then I'd go the j2objc route and/or just re-implement the code manually.

I don't really want to re-create the wheel so to speak. Maybe it's my inexperience but I can't get j2objc to work. It spits out errors like that it can't resolve MiniClientConnection to a type, etc. I've tried using the Eclipse plugin as well. Same errors. I'm running j2objc on the MiniClient.java file itself. It doesn't seem to be able to resolve all the dependencies on its own.

[stuckless]

Originally Posted by Taddeusz

I don't really want to re-create the wheel so to speak. Maybe it's my inexperience but I can't get j2objc to work. It spits out errors like that it can't resolve MiniClientConnection to a type, etc. I've tried using the Eclipse plugin as well. Same errors. I'm running j2objc on the MiniClient.java file itself. It doesn't seem to be able to resolve all the dependencies on its own.

I haven't used j2objc myself, but from the errors, it sounds like you need to set -sourcepath and -classpath to ensure that all the source files can be resolved.

http://j2objc.org/docs/j2objc.html

[Taddeusz]

Originally Posted by stuckless

I haven't used j2objc myself, but from the errors, it sounds like you need to set -sourcepath and -classpath to ensure that all the source files can be resolved.

http://j2objc.org/docs/j2objc.html

I guess I'm a bit out of my league with this. Even javac doesn't automatically resolve all the dependencies when I try to run it against MiniClient.java. Even dependencies that are located in the same directory.

[Taddeusz]

I know one probably doesn't exist but it would be nice to have some sort of protocol reference. I know it's not trivial but knowing the protocol it shouldn't be too difficult to construct native code that talks to SageTV in the same way. I just need to know what SageTV expects and what it will send back.

[Taddeusz]

IMHO, all that really needs to be done for native iOS is to create a communications framework. I think all the composition could be done using Metal.

[Fuzzy]

It's not like miniclient.jar is necessarily the 'standard' either. Extenders run a miniclient as well, but they have a completely different bit of software running (native to the architecture) on the client end. Obviously, if we COULD use a single miniclient.jar for all platforms, that would be ideal - but apple doesn't play with Java, and neither did the extender hardware.

[stuckless]

Originally Posted by Taddeusz

I guess I'm a bit out of my league with this. Even javac doesn't automatically resolve all the dependencies when I try to run it against MiniClient.java. Even dependencies that are located in the same directory.

Similar to the other program, if you try to compile using Javac, you'll have to pass the -sourcepath where javac can file the dependent .java files, and the -classpath where javac can find the .jars, etc.

All that being said, the java miniclient code is heavily dependent on AWT, which j2objc will not handle. The first thing I had to do was decouple the AWT stuff and build a 'bridge' so that the code would work without AWT.

It's also not just the protocol which you can decipher if you look at the MiniClientConnection.java combined with the GFXCMD2.java. It's also the interaction protocol of sending events to sagetv. SageTV expects Java AWT key and mouse bindings, so when you send a tap from ios/android, you need to send the AWT values for that, which you don't have in iOS/Android, so you need to manually map it yourself.

[stuckless]

Originally Posted by Fuzzy

It's not like miniclient.jar is necessarily the 'standard' either. Extenders run a miniclient as well, but they have a completely different bit of software running (native to the architecture) on the client end. Obviously, if we COULD use a single miniclient.jar for all platforms, that would be ideal - but apple doesn't play with Java, and neither did the extender hardware.

I thought Jeff said that the miniclient jar was used on the extenders to do all the communication stuff, and that only the UI rendering was done natively... i could have misunderstood, but that's was what I thought.

[Fuzzy]

I thought he stated that they had a complete miniclient in c that ran on the extenders. Of course, I could have misread that as well.

[stuckless]

Originally Posted by Fuzzy

I thought he stated that they had a complete miniclient in c that ran on the extenders. Of course, I could have misread that as well.

I think you are right...
https://github.com/stuckless/sagetv/.../newminiclient

@Taddeusz maybe you can use the C miniclient as a base instead of the java one.

[Taddeusz]

Originally Posted by stuckless

I think you are right...
https://github.com/stuckless/sagetv/.../newminiclient

@Taddeusz maybe you can use the C miniclient as a base instead of the java one.

Yeah, I was looking at that code earlier. Since MiniClient is built to be an executable I think I'd have to somehow repackage it as a static library to make it useful.

[Taddeusz]

I think I can use it but the code looks incomplete. Probably had the Silicon Image proprietary stuff stripped. Maybe my C is a bit rusty but as an example I can see the header, gfxcalls.h, where all the graphics stuff is defined but there doesn't appear to be any implementation for it anywhere. There are several header files like that (gfxcalls.h, mediacalls.h, inputcalls.h). Just definitions without implementation.

[Fuzzy]

Yeah, he said he had to rip those out. That's all the parts that you'd have to implement for your platform anyway.

For the most part, that's not really any different that what Stuckless is working on implementing on the android side. Those, properly, are in separate libraries, so they can be created for each platform - I'm betting SageTV had different libraries for the HD200 and HD300 as well.

[reggie14]

I'm really interested to see what people come up with.

I know Jeff was pushing the miniclient-port route, but I'm a bit skeptical of that route. At least, I'm skeptical for mobile devices where touch, rather than remotes, will be the primary input device.

For phones/tablets, I really wonder how input will work, and I wonder how responsive it will be.

The Phoenix Android app was/is great, albeit limited. I don't think mobile device clients need to be full-featured, but I'd love to be able to stream recordings/live TV to my Nexus tablets (with pause/FF/RW functionality).

[Taddeusz]

Originally Posted by reggie14

I'm really interested to see what people come up with.

I know Jeff was pushing the miniclient-port route, but I'm a bit skeptical of that route. At least, I'm skeptical for mobile devices where touch, rather than remotes, will be the primary input device.

For phones/tablets, I really wonder how input will work, and I wonder how responsive it will be.

The Phoenix Android app was/is great, albeit limited. I don't think mobile device clients need to be full-featured, but I'd love to be able to stream recordings/live TV to my Nexus tablets (with pause/FF/RW functionality).

Yeah, I'm a bit torn myself. While I think the miniclient route would be great for AppleTV or other TV connected device I don't think it would work well for a mobile app. Input is a major concern for me. I don't want swiping to scroll to equal paging. That's just awkward and inelegant.

As neat as it would be to implement miniclient on iOS I'm leaning more towards using sagex for api access and create a native look & feel. Personally, I think AppleTV should also take a more native approach.

My personal feeling about the SageTV look & feel has always been that it feels dated. I can't exactly put into words why, but it just looks tired and not modern to me. Quaint might be a better word. v7 was certainly a huge step up from the old interface but it still retains essentially the same basic UI components. Just in different dress with more translucency. I mean no offense to Jeff or Opus. It has all worked fairly well. I just think that SageTV needs a modernization effort with a deeper visual overhaul that means more than just adding some translucency here and there.

[reggie14]

Originally Posted by Taddeusz

As neat as it would be to implement miniclient on iOS I'm leaning more towards using sagex for api access and create a native look & feel. Personally, I think AppleTV should also take a more native approach.

Makes sense to me. I don't have a good intuition for the level of difficulty of getting playback controls working, though. I don't know if porting the miniclient takes care of a lot of that, or if the hard part is just hooking up to the native video APIs.

Originally Posted by Taddeusz

My personal feeling about the SageTV look & feel has always been that it feels dated. I can't exactly put into words why, but it just looks tired and not modern to me. Quaint might be a better word. v7 was certainly a huge step up from the old interface but it still retains essentially the same basic UI components. Just in different dress with more translucency. I mean no offense to Jeff or Opus. It has all worked fairly well. I just think that SageTV needs a modernization effort with a deeper visual overhaul that means more than just adding some translucency here and there.

Agreed, although certainly going native doesn't necessarily mean they'll be a great interface. It just means you'll be entirely in control of the interface.

You can fix a lot with a mobile-friendly STV, but it still wouldn't be good if 1) Sage isn't touch-aware (for scrolling, in particular) or 2) the miniclient route adds noticeable latency (again, scrolling is where I could see this being ugly).

Tangent: I vaguely remember a post that alluded to a failed effort to re-write the Sage UI between 6 and 7. That is, Sage paid someone to re-design the UI, but for whatever reason, it didn't go well. We ultimately got a refresh, but I don't think it was the redesign that was originally planned. This may have been the cause of the relatively long delay between v6 and v7.

Is there more of a story there? Were mock-ups ever developed?

[Fuzzy]

Originally Posted by reggie14

Makes sense to me. I don't have a good intuition for the level of difficulty of getting playback controls working, though. I don't know if porting the miniclient takes care of a lot of that, or if the hard part is just hooking up to the native video APIs.



Agreed, although certainly going native doesn't necessarily mean they'll be a great interface. It just means you'll be entirely in control of the interface.

You can fix a lot with a mobile-friendly STV, but it still wouldn't be good if 1) Sage isn't touch-aware (for scrolling, in particular) or 2) the miniclient route adds noticeable latency (again, scrolling is where I could see this being ugly).

Tangent: I vaguely remember a post that alluded to a failed effort to re-write the Sage UI between 6 and 7. That is, Sage paid someone to re-design the UI, but for whatever reason, it didn't go well. We ultimately got a refresh, but I don't think it was the redesign that was originally planned. This may have been the cause of the relatively long delay between v6 and v7.

Is there more of a story there? Were mock-ups ever developed?

Honestly, I think the short term goal for most is to get full sage functionality back to the general public. The hold up currently is the costly extenders (which will likely run out soon) that are far more expensive than many of the much cheaper devices on the market, with their only advantage being a native sagetv display. This is why I feel the best goal for starters is just that, getting a native display onto these cheap and plentiful devices, for viewing and interaction on a standard screen, with a standard remote. That's where the Android and ApplyTV projects should focus first.

Secondly, is the mobile usage. This can be handled with either a native approach, in which case, it will be a separate UI, likely different between iOS and Android, due to being developed independently, and only done so because the core STV functionality lacks good touch capabilities. Personally, I'd much rather see this fixed by adding proper touch capabilities to STV than by segmenting the UI's between platform. Remember, we HAVE the core code now, so we can add new input commands. Once added to the core, it will obviously also require tweaks to the STV itself to handle those inputs, but this will allow touch capability on non-mobile (touchscreen desktops for instance) as well. It will also allow STV plugins, tweaks and improvements to be felt across the entire 'product line'.

[stuckless]

Originally Posted by Fuzzy

Honestly, I think the short term goal for most is to get full sage functionality back to the general public. The hold up currently is the costly extenders (which will likely run out soon) that are far more expensive than many of the much cheaper devices on the market, with their only advantage being a native sagetv display. This is why I feel the best goal for starters is just that, getting a native display onto these cheap and plentiful devices, for viewing and interaction on a standard screen, with a standard remote. That's where the Android and ApplyTV projects should focus first.

Secondly, is the mobile usage. This can be handled with either a native approach, in which case, it will be a separate UI, likely different between iOS and Android, due to being developed independently, and only done so because the core STV functionality lacks good touch capabilities. Personally, I'd much rather see this fixed by adding proper touch capabilities to STV than by segmenting the UI's between platform. Remember, we HAVE the core code now, so we can add new input commands. Once added to the core, it will obviously also require tweaks to the STV itself to handle those inputs, but this will allow touch capability on non-mobile (touchscreen desktops for instance) as well. It will also allow STV plugins, tweaks and improvements to be felt across the entire 'product line'.

I totally agree with this. While I'm writing and testing the android part of this on a mobile phone, I'm not sure anyone would seriously use it on a phone, but the architecture is the same as the Android TV, which people will use. So, writing it for TV as a side benefit that people can, in a pinch, run it on a phone/tablet.

I think that there is a place for native apps that can interact with SageTV, and possibly play media etc. I'm don't think that I'll be doing much more with my original SageTV app, but I do use it daily. Creating a native app that has feature parity with a sagetv cient is a huge undertaking. Even doing something as simple as scheduling a favourite recording takes a huge amount of effort to implement all the feature of how you an do it on the client.

Once I get the Android placeshifter/client completed, if no one has gone down the native cient on iOS, I'll likely use RoboVM and take a stab at this, if no one has done it. I have iOS devices as well, and I'd like to see a placeshifter client on those as well.

And lastly, my biggest challenge (if someone doesn't do it first), is to write a placeshifter in BrightScript and be able to run it on Roku3 (which supports opengl).

I suspect that at some point in time we will have to add better touch support to the core, but I'm not sure we'd ever get to the point where a placeshifter experience feels like a native app... nor do I think we should try. I'm not a huge fan of "emulating" native experience... it's one of the reasons why I hate JavaScript/HTML apps on mobile that try to emulate a native feel... they generally fall short, and you can tell immediately.