Docker container

[coppit]

This is a work in progress

Basic connectivity and streaming with a HD300 works. Some important things are still broken. See the end of this thread for details.

In case anyone wants to try it out: http://hub.docker.com/r/coppit/sagetv-server/

---Original post below---

When I get a minute, I'm going to start working on a Docker container for SageTV. Is anyone else already working on one?

I was thinking of using the Phusion base (which IIRC is based on 64-bit Ubuntu), along with the latest version of Java.

My tuners are all HDHomeRun network tuners, so I'll need some help figuring out and testing local HW tuners.

[stanger89]

From what I read, I suspect local tuners are not possible due to the need for the host OS to have the drivers installed for them, which unRAID doesn't.

[matt91]

a docker that runs under unRaid - even if it supported only network tuners - would be great.

[BobPhoenix]

Originally Posted by stanger89

From what I read, I suspect local tuners are not possible due to the need for the host OS to have the drivers installed for them, which unRAID doesn't.

Not necessarily. If you use this build of unRAID http://lime-technology.com/forum/ind...?topic=40705.0

[PiX64]

Would love to see this. I currently use docker on my unraid 6 for plex media server as well as subsonic... a SageTV docker image would be killer!
Im happy to test and debug if needed.

[coppit]

Hi all,

I got the server built, but I can't connect to it:

1) The client is built but crashes on connect (see below)

2) My HD300 and Mac Placeshifter complain that the server doesn't have any user configured.

3) My Windows client won't connect due to version mismatch.

Here are my repos. Once things are stable I'll set up a build on Docker hub and a template for UNRAID.

https://github.com/coppit/docker-sagetv-server
https://github.com/coppit/docker-sagetv-client

The client is complaining as below. It makes me wonder if maybe some C component of the client was built with the wrong architecture. Maybe I need to set a compiler flag somewhere...

Starting MiniClient
Fri 8/14 3:22:15.806 Detecting cryptography support...
Fri 8/14 3:22:16.152 Sending out discovery packets to find SageTVPlaceshifter Servers...
Fri 8/14 3:22:16.154 Starting SageTVPlaceshifter Client
Fri 8/14 3:22:16.156 Starting main loop
Fri 8/14 3:22:16.156 StorageDeviceDetector started...
Fri 8/14 3:22:16.161 Discovery packet received:java.net.DatagramPacket@38a6de20
Fri 8/14 3:22:16.164 Added server info:192.168.1.100 192.168.1.100
Fri 8/14 3:22:16.201 Discovery packet received:java.net.DatagramPacket@38a6de20
Fri 8/14 3:22:16.204 Added server info:192.168.1.102 192.168.1.102
Fri 8/14 3:22:20.527 Attempting to connect to server at 192.168.1.102:31099
Fri 8/14 3:22:20.544 Connection accepted by server
Fri 8/14 3:22:20.544 Connected to media server
Fri 8/14 3:22:20.545 Connection accepted by server
Fri 8/14 3:22:20.545 Connected to gfx server
Fri 8/14 3:22:20.646 Testing to see if server can do a pull mode streaming connection...
Fri 8/14 3:22:20.648 Server can do a pull-mode streaming connection.
Fri 8/14 3:22:20.648 Max screen size=java.awt.Dimension[width=1280,height=800]
Fri 8/14 3:22:20.650 Loaded
Type size error: sizeof(jint) < sizeof(size_t)
Type size error: sizeof(jint) < sizeof(ssize_t)
Type size error: sizeof(jint) < sizeof(ino_t)
Type size error: sizeof(jint) < sizeof(nlink_t)
Type size error: sizeof(jint) < sizeof(blksize_t)
Type size error: sizeof(jint) < sizeof(nfds_t)
Type size error: sizeof(jint) < sizeof(msgqnum_t)
Type size error: sizeof(jint) < sizeof(msglen_t)
Type size error: sizeof(int) < sizeof(ino_t)
Jtux error: Java native types don't match POSIX/SUS types.
Fri 8/14 3:22:20.651 Staring video server
Fri 8/14 3:22:20.652 Error w/ Media Thread: java.net.SocketException: Socket closed
java.net.SocketException: Socket closed
        at java.net.SocketInputStream.socketRead0(Native Method)
        at java.net.SocketInputStream.socketRead(SocketInputStream.java:116)
        at java.net.SocketInputStream.read(SocketInputStream.java:170)
        at java.net.SocketInputStream.read(SocketInputStream.java:141)
        at java.io.DataInputStream.readFully(DataInputStream.java:195)

[coppit]

Originally Posted by PiX64

Would love to see this. I currently use docker on my unraid 6 for plex media server as well as subsonic... a SageTV docker image would be killer!

I'm with you brother! That's why I'm working on it. The only reason I have left to run my Windows VM is for Blue Iris (security cam software).

[stanger89]

Originally Posted by coppit

3) My Windows client won't connect due to version mismatch.

You should be able to just update the jar file on the client to V9 and it should connect.

The client is complaining as below. It makes me wonder if maybe some C component of the client was built with the wrong architecture. Maybe I need to set a compiler flag somewhere...

I may be way off base here, but I doubt client will work in a Docker, at least not a normal one, client/placeshifter isn't meant to be run headless, it needs a display.

[Narflex]

Originally Posted by coppit

Hi all,

2) My HD300 and Mac Placeshifter complain that the server doesn't have any user configured.

If you look in MiniClientSageRenderer.java, you can find in there that it looks at the subnet of the connecting IP relating to the IP of the system SageTV is running on. If they do not match..then it assumes its an external connection and requires authentication. There's a setting to force it to always prompt...but not the other way around. It's around line 4141 in that file.

So your problem should be solvable by just ensuring they are both on the same subnet. You'll also notice how ugly the subnet mask code is...it could use some kind of update if anyone is interested.

[coppit]

Originally Posted by stanger89

You should be able to just update the jar file on the client to V9 and it should connect.

Cool. I'll try that.

Originally Posted by stanger89

I may be way off base here, but I doubt client will work in a Docker, at least not a normal one, client/placeshifter isn't meant to be run headless, it needs a display.

I'm not running it headless... I'm running it in X11, with RDP and Guacamole connectivity. So from my Mac I connect via RDP and can see the client UI. Performance probably stinks, but I thought it would be a useful way to test.

Originally Posted by Narflex

If they do not match..then it assumes its an external connection and requires authentication.

Ah, that makes sense. I can have the docker container use host networking, where its IP is the same as that of my docker host's. I had to do that for the client so that it could discover the servers with UDP multicast.

[coppit]

All right, I've been able to connect my HD300 to the server and stream video. Jeff was right about the networking. (But he knew that.) From five minutes of testing, I see a few items already that need work:

P0 = Must have
P1 = Should have
P2 = Nice to have

* P0 Seek bar and FF don't work
* P0 Placeshifter crashes during setup on my Mac. Maybe just an outdated Placeshifter client? (HD300 doesn't crash.)
* P0 Need to test network tuner
* P1? See if we can figure out hardware tuner support.
* P1 See if we can remove the hard-coded default paths
* P1 Fix the "placeshifter mode" detection to allow the server to be run in a container with forwarded ports.

I've created an image on the Docker hub. I'll put details in the first post.

[coppit]

Does anyone know what state gets put on the machine? Docker containers lose everything when they get redeployed, so I'll need to mirror the stuff to a mounted dir.

At first I was thinking about wiz.bin and Sage.properties, but then it occurred to me that there are plugins and STV updates and who knows what else. Seems like the entire /opt/sagetv/server directory needs to be a host-mounted dir, for persistence. Are there any other bits elsewhere on the system to worry about?

Also, since the program binaries are in there, I'll need to be able to deploy new binaries without messing up settings. I guess the .deb package installer knows how to do that. So I need to run the .deb installation on startup, potentially upgrading the previously deployed binaries.

[stuckless]

Originally Posted by coppit

Does anyone know what state gets put on the machine? Docker containers lose everything when they get redeployed, so I'll need to mirror the stuff to a mounted dir.

At first I was thinking about wiz.bin and Sage.properties, but then it occurred to me that there are plugins and STV updates and who knows what else. Seems like the entire /opt/sagetv/server directory needs to be a host-mounted dir, for persistence. Are there any other bits elsewhere on the system to worry about?

Also, since the program binaries are in there, I'll need to be able to deploy new binaries without messing up settings. I guess the .deb package installer knows how to do that. So I need to run the .deb installation on startup, potentially upgrading the previously deployed binaries.

I know for my home server, pretty much everything ends up somewhere on /opt/sagetv/server.

[Narflex]

Yeah, everything (except for your recordings of course) will get put inside /opt/sagetv/server. SageTV never touches anything outside of it's working directory with the exception of /tmp and the configured TV and import directories.

Generally Sage.properties and Wiz.bin/bak are all you need...but there's also the system message file, and then everything relating to plugins which then is best to cover by saving the whole directory structure under /opt/sagetv/server.

The Placeshifter is a little different...but you're probably not asking about that.

[coppit]

Okay, I've removed the build hacks and exposed the entire /opt/sagetv/server directory to the host. For now I'm tracking master's HEAD, until things stabilize.

The hard-coded and unchangeable /var/media paths are annoying. I took a quick look at the code... Is this running in embedded mode for some reason? For now I'm just going with the flow and mapping my host dirs to those paths.

Also, I can't figure out why I'm getting 0-length files in my Recordings directory. From within the container I can echo foo > /var/media/tv/foo.txt and it writes the file fine. I'm using a HDHomeRun, so maybe there's something wrong with that.

Next I'll work on gracefully shutting down the server when the container is stopped.

[stuckless]

Originally Posted by coppit

Also, I can't figure out why I'm getting 0-length files in my Recordings directory. From within the container I can echo foo > /var/media/tv/foo.txt and it writes the file fine. I'm using a HDHomeRun, so maybe there's something wrong with that.

Next I'll work on gracefully shutting down the server when the container is stopped.

I'm pretty sure there was someone else mentioning that HDHomeRun recordings were not working in their 64bit env, but did work in their 32bit env.

The sagetv deb package installs /etc/init.d/sagetv script for start/stop operations hooked into the init system. SageTV should shut down gracefully as long as the container is using a standard linux init system. (side note, I'd like to change the scripts for ubuntu to use upstart, but that's another discussion )

[mwnswiss]

Originally Posted by stuckless

I'm pretty sure there was someone else mentioning that HDHomeRun recordings were not working in their 64bit env, but did work in their 32bit env.

I had the same issue with the docker and on the standard pc. See my other thread "Linux server with HD HOMERUN DUAL DVB-C".

I had success with the dvbhdhomerun kernel module, but that will not work in a docker container. However it works on the standard pc, but faces still some issues on 64bit, runs on the 32bit.

As mentioned in the other, I did not figure out if anyone had success using the build in hdhomerun WITHOUT the dvbhdhomerun kernel module? I saw from the code that it is intended to work without dvbhdhomerun and as all others I can see the tuners, so the discovery works, but all the rest not. This will need some futher debugging and most likely the https://github.com/google/sagetv/tre...o/HDHomeRun2.0 library needs to be adapted to the newest silicondust protocols.

@coppit - good work, many thanks for the docker. I used it to create a shippable CI config, which is similar to jenkins and make a build after each commit of a repo. https://app.shippable.com/projects/5...d7f2c052838318
Of course covers only linux.

[coppit]

Do you think you or someone else will figure out 64-bit + HDHR some time soon? Seems like the fastest path to a working Docker container is to build 32-bit. I was thinking of switching over to that, polishing it a bit, then exploring options for local tuners, or maybe upgrade to 64-bit once it's working for HDHR.

[coppit]

I'm playing around with doing a 32-bit build.

I tried installing i386 versions of the libraries, but quickly got into an unresolvable package conflict.

It may be doomed, as I seem to recall that containers share libraries with the host.

One last ditch effort: Does anyone know how to set up a 32-bit chroot in Ubuntu 14.04?

[stuckless]

Originally Posted by coppit

I'm playing around with doing a 32-bit build.

I tried installing i386 versions of the libraries, but quickly got into an unresolvable package conflict.

It may be doomed, as I seem to recall that containers share libraries with the host.

One last ditch effort: Does anyone know how to set up a 32-bit chroot in Ubuntu 14.04?

If it's just for build testing, you can check out my vagrant images. I have 32bit and 64bit images that I use for build testing. They are not as efficient as Docker, since they user VirtualBox, but they do the trick to be able to create 32bit builds easily on a 64bit environment.