AMD64 based Docker Image with Python3

[pkscout]

AT SOME POINT THE DEFAULT IMAGE STARTING COMING WITH PYTHON3
I'm leaving all this here as a historical artifact mainly.  At some point the default image started shipping with Python3.  As of July 23, 2023 it's Python 3.9.2.  That's a hair out of date, but not horribly so.  I won't be updating the image referenced below any longer.  It's not worth the time to me for a slightly newer version of Python3.

Two things to note.  If you want to install any Python modules, you'll have to install pip3 by doing:

Code:

apt update
apt install python3-pip

No need for sudo, as the image seems to default to the root user.  If you ever update the image, you need to reinstall pip3, but ONLY if you need to install modules again.

Which leads me to the other trick. If youmap the Python userspace to an external volume and then install modules in the userspace, you can avoid having to reinstall your python modules every time you update the image.  To do that, you need to add a line to your Docker run or compose:

Code:

- '/volume1/configs/nextpvr/local:/root/.local'

Then install Python modules using:

Code:

pip install --user <item>

ORIGINAL POST
For anyone who wants to run NPVR5 from a Docker container and also would like to use Python scripts for things like Parallel or Post Processing (or Extra tuners), I've published a Docker container based on nextpvr/nextpvr_amd64table.  There are two different ways you can run this Docker.

The stable tag includes NextPVR, Python 3.9.6, and the following modules:

• requests
  
• xmltodict
  
• websocket-client
  
• opencv-python
  

These are included so two Python scripts I wrote (trigger.kodiscan and iguana-blaster) will work properly in a NextPVR docker container.

The pub tag includes NextPVR and Python 3.9.6. It is setup so that you can map a directory to user level python module installs and install them outside the Docker container. This provides more flexibility if you want to install other modules but don't want to have to redo it every time the image is updated.

Both tags also includes NTP and a couple options to set the timezone for your container. This was added because on certain platforms Docker containers don't seem to be able to get the time/timezone from the host OS. And having accurate times seems important for a DVR. If your Docker container is getting the time correctly from the Host OS, you don't need to include those options.

There's complete information both options (including sample run commands) at:

https://hub.docker.com/repository/docker...vr-python3

NOTE ABOUT COMSKIP:
With the release of 6.x, the NextPVR image is based on Bullseye.  I can't seem to get any of the current(ish) Comskips to build with this, and the version of Comskip included in the apt package manager for Bullseye is pretty old.  So I DID NOT update the two Comskip tags.  They will remain at the last 5.x version of NextPVR, but may not ever be updated again.

[mvallevand]

I made this suggestion to take it from the host https://forums.nextpvr.com/showthread.ph...#pid532506 but your suggestion might be better on a Windows host.

Martin

[pkscout]

I made this suggestion to take it from the host https://forums.nextpvr.com/showthread.ph...#pid532506 but your suggestion might be better on a Windows host.

Martin

I wish I could take credit for this, but I found the answer from some internet search at some point, and I now I can't find the original page again to give the author the credit.  Bad me.  But yes, this solution does appear to be platform independent.  The drawback is that you have to know the right timezone text to put in.  Which is also findable on the internet, so I guess there's that.  '-)

[pkscout]

Image has been updated to NextPVR 5.0.1.200209.

[dsreyn]

I'm not sure what you've been doing to inject Python into the container. But I'm wondering if it would be possible to build it in such a way that it could exist in a separate directory structure outside the container's file system, and then be mounted into the docker file system using the --volume option. As I recall, the Python configure scripts usually have a --prefix=[dir] option that can be used to set the install directory to something other than the standard / default location. Then when you get to the "make install" step, everything gets installed under the directory given by --prefix.

The advantage would be that your distribution would then just need to be the subdirectory structure where Python gets installed, not the full container. And you wouldn't need to put together a new distribution every time Sub puts out a new release. Users would just have the Python package unpacked somewhere outside the container, and would just point the new NextPVR release to that location.

Doug

[pkscout]

I'm just using apt-get to install the Python stuff. It takes like 5 extra minutes to build a new container when sub releases one. And the advantage there is that I then get the most current Python builds at the same time. Your suggestion could certainly work, but I'd probably spend quite a lot of time figuring it out, and then I'd have to do at again whenever a Python update comes out.

[pkscout]

Image has been updated to NextPVR v5.0.2.200322. In addition, there is a tagged stable branch now (to match what sub is doing). Instructions in first post have been updated.

[pkscout]

On the off chance anyone is actually using this, I found a problem with the python3 cv2 module.  The stable branch has been updated with the fixes, so if you pulled it between now and 7 hours ago, you need to pull an updated image.

[pkscout]

Image has been updated to NextPVR v5.0.4.200428.

[pkscout]

Image has been updated to NextPVR 5.0.7.200726.