Add web interface for configuration and troubleshooting.

[enternoescape]

Some very basic progress has been made on the web interface. At the moment you can see an overview of the current status of the capture devices. I am creating this has a WebApp so it can be integrated with SageTV if it ever becomes possible in the future. If anyone has any interest, please take a look at what I have done so far and provide critique if I'm doing things in a laborious unnecessary manner for example. This is my first time doing anything with Jetty, so I'm sure I'm not doing everything the best possible way. A lot of the work isn't even in the interface itself; there's a fair amount of code in place just to set variables on the capture devices via GET with parameters.

Please keep in mind there are no real features integrated right now, so please no comments yet about what the interface needs... it needs a lot. :) I will keep committing so it should shape up eventually, but it will at least be weeks before I would even consider posting a build for people who want to just see it knowing there might be issues.

[CraziFuzzy]

So, with the recent new producers available, I am thinking again of looking into porting OpenDCT over to a Raspberry Pi to allow a Pi to act as a network encoder for things like an HD-PVR. In doing so, I'd like to be able to leverage the web server you've already got partially here to help configure things. What are the major missing bits in this that need to be fleshed out to be usable?

[enternoescape]

I'm working with Tom on testing the JSON interface for use in a SageTV plugin. I stopped working on a formal web interface because work on a new interface for SageTV would be taking off at some point and I wanted to sync my efforts with that effort so users don't need use two different interfaces. If you take a look at Plugin.java, that should give you some ideas on how to discover all OpenDCT servers and their webports. The code overall is still rough, but it works mostly. You can build the "client" part by running "gradlew jsonClientJar"

[CraziFuzzy]

Okay, so the plan on the OpenDCT end is to just have nanohttpd servicing JSON requests as described in NanoServlet.java, and not actually be setup to present a web interface to the user?

[CraziFuzzy]

I do think it might be wise to at least implement IndexHandler, with some sort of informative page that would provide at least an indication that it's OpenDCT you've connected to. Going a bit further with some statuses might be useful. Anything is better than landing on a Hello World! page.

[enternoescape]

I know I realized that was happening a little while ago. I completely agree that it should be changed to something more informative even if it's not really an official way to do anything at the moment.

[enternoescape]

There is now a landing page with some brief information about the capture device states.

[enternoescape]

Also, to be clear, the JSON service was always a part of the plan and even the built in web interface was going to use the JSON service to get it's data. It was not going to take advantage of running on the same code as the program itself. The mock up I wrote last year completely relied on JSON REST calls for it's data, but it didn't see the light of day because as I said I want to merge the configuration with whatever becomes the new SageTV web interface.

[CraziFuzzy]

I think for my purposes, I can just use dirct java calls instead of the java. We'll see. Gotta figure it the way nanohttpd wants index.html handled first.

[enternoescape]

I can set it up to serve actual files from a directory if that would make development easier.

[enternoescape]

I almost forgot. You currently can't do transcoding using 3.0.2 because the FFmpeg project deprecated a lot of things and still doesn't have good documentation on how they expect you to work around it. All of their official tutorials still have you doing things the old way. Because of this, you can crash the JVM and that's a bad enough thing that I will be holding out until that project gets their documentation in order (if ever).

[CraziFuzzy]

Nah, I wouldn't worry about it. I'll probably make the pi encoder a separate fork for now, stripping out a lot of the extra stuff that wouldn't be required (it's only ever be using the mediaserver interface, no need for the HDHR or UPnP stuff, etc. So since it'd be a seperate fork, and I can see how you very easily just added the root route to the server, I can just make a different version of the root class to deal with what I need. remember, this would be a very specific purpose thing, so it doesn't really warrant a bunch of compilation switches to turn that stuff off being added to the main openDCT.