Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Dockerized Deployment V2 #403

Closed
wants to merge 6 commits into from

Conversation

Jamalarm
Copy link

@Jamalarm Jamalarm commented Oct 5, 2024

Hey @vicwomg!

So I'm just taking a stab at this. I'm no expert in Python so I'm running into a few problems but I think the image is building mostly correctly. I made a few changes from the other PR:

  • I decided to go with one of the official Python debian-based images (python:3.12-slim-bookworm) as most of your setup scripts and instructions assume you're on Debian
  • I'm copying in the code directly from the repo, rather than pulling it from git. This is because eventually we should set up a Docker publish step as part of the Github release. Pulling the code from the local repo ensures that the published version matches and doesn't accidentally pull in code from a different release.
  • I borrowed the same entrypoint.sh script from the other PR, but I changed it to call python3 /pikaraoke/pikaraoke/app.py directly rather than using the pikaraoke.sh script.

This is not currently working, as the app startup fails with:

Traceback (most recent call last):
2024-10-05T11:25:28.943391217Z   File "/pikaraoke/pikaraoke/app.py", line 36, in <module>
2024-10-05T11:25:28.943393384Z     from pikaraoke import VERSION, karaoke
2024-10-05T11:25:28.943394842Z ModuleNotFoundError: No module named 'pikaraoke'

Unfortunately this is where I run into the problem of not really knowing Python that well!

@vicwomg
Copy link
Owner

vicwomg commented Oct 6, 2024

python3 /pikaraoke/pikaraoke/app.py is not the recommended way to launch pikaraoke from source locally. You can try installing poetry and running it that way. See: https://github.com/vicwomg/pikaraoke?tab=readme-ov-file#developing-pikaraoke

@Jamalarm
Copy link
Author

Jamalarm commented Oct 7, 2024

Ok, adjusted it to use poetry and seems to be starting properly. The app now fails on any GET with:

Traceback (most recent call last):
2024-10-07T10:17:16.732223382Z   File "/root/.cache/pypoetry/virtualenvs/pikaraoke-dQFMxTlB-py3.12/lib/python3.12/site-packages/flask/app.py", line 2529, in wsgi_app
2024-10-07T10:17:16.732225340Z     response = self.full_dispatch_request()
2024-10-07T10:17:16.732226757Z                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
2024-10-07T10:17:16.732228090Z   File "/root/.cache/pypoetry/virtualenvs/pikaraoke-dQFMxTlB-py3.12/lib/python3.12/site-packages/flask/app.py", line 1825, in full_dispatch_request
2024-10-07T10:17:16.732247090Z     rv = self.handle_user_exception(e)
2024-10-07T10:17:16.732249048Z          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
2024-10-07T10:17:16.732250340Z   File "/root/.cache/pypoetry/virtualenvs/pikaraoke-dQFMxTlB-py3.12/lib/python3.12/site-packages/flask/app.py", line 1823, in full_dispatch_request
2024-10-07T10:17:16.732252048Z     rv = self.dispatch_request()
2024-10-07T10:17:16.732253298Z          ^^^^^^^^^^^^^^^^^^^^^^^
2024-10-07T10:17:16.732254548Z   File "/root/.cache/pypoetry/virtualenvs/pikaraoke-dQFMxTlB-py3.12/lib/python3.12/site-packages/flask/app.py", line 1799, in dispatch_request
2024-10-07T10:17:16.732256132Z     return self.ensure_sync(self.view_functions[rule.endpoint])(**view_args)
2024-10-07T10:17:16.732257507Z            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
2024-10-07T10:17:16.732259090Z   File "/pikaraoke/pikaraoke/app.py", line 502, in splash
2024-10-07T10:17:16.732260632Z     status = subprocess.run(["iwconfig", "wlan0"], stdout=subprocess.PIPE).stdout.decode(
2024-10-07T10:17:16.732262507Z              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
2024-10-07T10:17:16.732263965Z   File "/usr/local/lib/python3.12/subprocess.py", line 548, in run
2024-10-07T10:17:16.732265423Z     with Popen(*popenargs, **kwargs) as process:
2024-10-07T10:17:16.732266715Z          ^^^^^^^^^^^^^^^^^^^^^^^^^^^
2024-10-07T10:17:16.732267965Z   File "/usr/local/lib/python3.12/subprocess.py", line 1026, in __init__
2024-10-07T10:17:16.732269298Z     self._execute_child(args, executable, preexec_fn, close_fds,
2024-10-07T10:17:16.732270632Z   File "/usr/local/lib/python3.12/subprocess.py", line 1955, in _execute_child
2024-10-07T10:17:16.732272007Z     raise child_exception_type(errno_num, err_msg, err_filename)
2024-10-07T10:17:16.732273298Z FileNotFoundError: [Errno 2] No such file or directory: 'iwconfig'

iwconfig seems to be something for getting WLAN specific information about network adapters. I also found something about iwconfig being moved to /sbin in Buster onwards. I tried to fix this by adjusting the path but it doesn't seem to be working. Before I keep hitting my head against this, is iwconfig definitely needed in the image?

@vicwomg
Copy link
Owner

vicwomg commented Oct 7, 2024

Not sure if I don't understand docker, but why don't you install pikaraoke via pip instead of pulling the source?
pip install pikaraoke

Then to run: pikaraoke

As for iwconfig, I don't know the exact reasoning behind it. Looks to have something to do with Wifi ap mode detection in raspberry pi devices only. Best to leave it in.

If your docker image doesn't have iwconfig, can't it simply be installed?

@Jamalarm
Copy link
Author

Jamalarm commented Oct 7, 2024

why don't you install pikaraoke via pip instead of pulling the source

So if we eventually end up publishing the image to Docker Hub, you'll want to be publishing the specific version/code you're releasing on Github. If you look at something like MariaDB you can see all the version-specific tags like 11.1.6 and so on.

The way they do this is they'll have a CI pipeline that builds the source, packages it as an image, and then publishes it to Docker Hub all as part of the same pipeline. If you start pulling down from some remote package manager (like pip) at this point, you won't get the changes are currently releasing, so effectively the Docker build would be at least one version behind the whole time.

If your docker image doesn't have iwconfig, can't it simply be installed?

It does have it, but it looks like in later versions of Debian linux iwconfig is only available to sudo by default so it isn't on the regular PATH. I can probably get it working but was just checking if you happened to know if it was needed, though now as I look at it I realise that's actually being called from /usr/local/lib/python3.12/subprocess.py which I guess is some kind of core Python library and nothing to do with your code!

@vicwomg
Copy link
Owner

vicwomg commented Oct 7, 2024

Got it that makes sense in regard to the versioning.

One could make the case that you could deploy to docker only after the version is released to pip, then have the docker config pull the proper version via pip install pikaraoke==X.X.X where X.X.X the newest version number. That would just be a CI pipeline configuration. But if this is more self-contained then great.

Regarding iwconfig It is being called by subprocess library, but this is indeed being done by pikaraoke. The underlying issue is iwconfig is either not in the PATH, or not installed. My suggestion would be to determine what directory it is installed to, and add that to the PATH variable in the docker config. If it's not installed, then have docker install it somehow where it can be accessed from the PATH.

@Jamalarm
Copy link
Author

Jamalarm commented Oct 8, 2024

I've fixed the iwconfig problem. The interface now loads!

Video playing is not functioning. I thought at first it was because the 5556 port wasn't exposed, but it still isn't working after that.

image

It looks like something is assembling weird URLs (http://localhost:5555/://None:5556/1728380127) when specifying the -u localhost argument for local testing.

Omitting the -u argument results in what looks like a valid URL, but the host is the internal Docker hostname and isn't accessible outside of Docker:

image

@vicwomg
Copy link
Owner

vicwomg commented Oct 8, 2024

-u / -url overrides the webserver url (splash screen and endpoints). There --ffmpeg-url parameter to override the stream url. Normally these are auto-detected, however in a containerized installation, as you noticed the IP address is invalid.

You'd need to ensure that both of these are a set to valid LAN IP address in order for other clients to connect. And that the port forwards correctly.

There was some discussion about this here. I think it involved some proxying of the two urls into a single endpoint. maybe you can dig up the solution.
#293

@Jamalarm
Copy link
Author

Jamalarm commented Oct 8, 2024

Ok! Getting somewhere.

I can now access and display the /splash screen locally and on my smart TV's web browser over the network. My phone can successfully open the remote control app as well.

On my local web browser the video and sound plays perfectly, on my smart TV the interface displays properly and the sound plays for each video, but the video is black. I'm assuming this means the network is ok (otherwise we would get no sound) but probably some issue with the codec that is being streamed over to the browser?

I'm going to try tinkering with some settings to see if I can make it use a more basic codec format that may be supported by more embedded browsers.

Edit: adding --high-quality doesn't fix it.

@vicwomg
Copy link
Owner

vicwomg commented Oct 8, 2024 via email

@Jamalarm
Copy link
Author

Jamalarm commented Oct 8, 2024

Yep, that makes sense.

Would you like to be the owner of the Docker Hub repo? I feel like that makes sense given you own the Github repo too. In which case could you do the setup steps here when you have a moment?

Once we have the repo we can add the Github Actions definition to build and publish the image on release.

@vicwomg
Copy link
Owner

vicwomg commented Oct 8, 2024

Yup, I can own that.

In the meantime can you write up some basic instructions on how I can test this myself from your branch? Not too familiar with docker, but I do have it installed.

@Jamalarm
Copy link
Author

Jamalarm commented Oct 8, 2024

Basic instructions to spin it all up locally:

  1. Open a terminal at the repo root
  2. Build and publish the docker container to your local repo with docker build --tag pikaraoke:latest (this takes a little while)
  3. Modify docker-compose.yml, setting URL to either localhost (to test on the same machine) or whatever IP your dev machine has on your local network
  4. In your terminal, run docker-compose up

Once the remote repo is up and running, only steps 3 and 4 will be required (and you won't need the repo cloned locally of course). Docker compose will automatically trigger an image pull from Docker Hub for whatever the latest version you published.

@vicwomg
Copy link
Owner

vicwomg commented Oct 9, 2024

I had a look. Couldn't get it to work initially, but this command did it (add a .) : docker build . --tag pikaraoke:latest

I'm now able to run a headless server on localhost in docker. That seems to work fine.

However, is there a way to automatically pass the host LAN IP to the entrypoint command in the event of the absence of the URL? Ideally that would all be handled automatically and not be a manual configuration. Running headless server and client on localhost is not a common scenario.

@Jamalarm
Copy link
Author

However, is there a way to automatically pass the host LAN IP to the entrypoint command in the event of the absence of the URL?
Yeah I was trying to figure that out. I think there's two options:

  • Try and figure out some clever docker compose syntax that figures it out automatically and sets the environment variable
  • Use a native docker networking feature. I think it might be possible with the macvlan network driver but I haven't used this before so need to do some experimentation.

Side point: I'm moving house over the next week so likely won't have time to make progress on this myself in that time. Will pick it up again when things calm down.

@vicwomg
Copy link
Owner

vicwomg commented Oct 10, 2024

Thanks for the update, we're definitely close here.

I also saw this entry on a promising host.docker.internal reserved dns name that might achieve that. I tried plugging it in to entrypoint.sh and it didn't work though. Might not be accessible in sub scripts
https://docs.docker.com/desktop/networking/#i-want-to-connect-from-a-container-to-a-service-on-the-host

@vicwomg
Copy link
Owner

vicwomg commented Oct 24, 2024

FWIW, I have a WIP branch where I'm trying to have pikaraoke run on a single port 5555, including ffmpeg streams. That would solve these issues.

I recall I got mostly there, but forget where I left off. Will revisit when I have the time.

@Jamalarm
Copy link
Author

Jamalarm commented Oct 25, 2024

to have pikaraoke run on a single port 5555

Tbh I'm not sure this is really a problem. Docker is perfectly happy to expose as many ports as you like.

Apologies for not following up on this. I'm still in the chaos of setting up my new apartment so don't have any free time to play around with this stuff.

@Jamalarm
Copy link
Author

Hey @vicwomg!

Sorry about the radio silence for the last couple of months. Moving apartment is all-consuming!

Coming back to this now and I have good news. In the meantime I have learned about networkMode: host in Docker. Basically what this does is that it allows the container access to the same network stack as if it wasn't containerised. The practical effect of this is that all the existing code for determining the local IP address appears to just work!

I've tested this by pushing the image to my personal docker repo and deploying it to my pi at home. I can successfully open and interact with the app all without having to tell docker-compose.yml anything about an IP address.

I think we should be good to move ahead and merge this and start working on the publishing pipeline for images?

@vicwomg
Copy link
Owner

vicwomg commented Dec 21, 2024

I'm seeing this error when trying to run docker-compose up, any idea?

➜  pikaraoke git:(feature-293-dockerised) ✗ docker-compose up      
service "pikaraoke" refers to undefined volume pikaraoke-songs: invalid compose project


# Run pikaraoke with necessary parameters
cd pikaraoke
poetry run pikaraoke -d /pikaraoke-songs/ --headless --high-quality
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would prefer not to force the --high-quality flag. Not sure if there's a way to passthrough command line parameters using docker, but that would be preferred

Copy link
Author

@Jamalarm Jamalarm Dec 21, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We can definitely do that, the way you specify features like that is usually via environment variables (the env: block that is currently not included). Question is, do we want to just have one environment variable that contains all the extra params, or do you want one for each option?

so we'd either have

env:
    LAUNCH_OPTIONS: '--high-quality'

or

env:
   HIGH_QUALITY: true

@vicwomg
Copy link
Owner

vicwomg commented Dec 21, 2024

I'm seeing this error when trying to run docker-compose up, any idea?

➜  pikaraoke git:(feature-293-dockerised) ✗ docker-compose up      
service "pikaraoke" refers to undefined volume pikaraoke-songs: invalid compose project

I was able to fix it by manually specifying the path to my local pikaraoke-songs dir. But I'm not sure what a more universal cross-platform solution would be.

services:
  pikaraoke:
    image: pikaraoke:latest
    container_name: PiKaraoke
    network_mode: host
    volumes:
      - /etc/hostname:/etc/host_hostname:ro
      - ~/pikaraoke-songs:/pikaraoke-songs
    restart: unless-stopped

Also, after launching, it reports my splash screen URL to: http://192.168.65.3:5555/splash, but I cannot actually connect to it. Is that some kind of docker internal virtual IP? I also cannot connect to http://<my_lan_ip>:5555/splash

@Jamalarm
Copy link
Author

Jamalarm commented Dec 21, 2024

Are you running this on your laptop? I had the same problem on my mac, but it worked fine on my Pi. My best guess currently is that the logic that tries to guess the IP is currently misinterpreting information on OSX when running inside docker, but is fine on pi.

The IP should definitely be available in host mode, so we probably just need to tweak the logic that guesses the IP? Probably in a separate PR though?

If you want to test it on a remote machine, I've published the image to my own repo at jamalarm/pikaraoke:test3, you can just modify the docker compose file to pull that image.

I was able to fix it by manually specifying the path to my local pikaraoke-songs dir. But I'm not sure what a more universal cross-platform solution would be.

So this isn't really something we need to fix I think. It's established with docker containers that you can either:

  1. Not specify a mount and everything is just ephemeral (so in this case you would lose the downloaded songs if you delete the container)
  2. Specify a mount/volume if you want something to be durable outside the container. (for example if you look at the Usage section here, you specify volumes for the bits you want to exist somewhere outside, like the config files).

@samuelkyl
Copy link

samuelkyl commented Dec 23, 2024

I just wanted to pop in here and thank you both. I tried this on a Synology NAS docker server, Chromecast with Google TV client setup and it worked great!

Some notes:

  • I'd keep the option to pass in the URL env var through to --url $URL:5555 --ffmpeg-url $URL:5556, it's quite useful
    • for example my router auto-assigns local dns names to hostnames so it's nice to pass in something like URL: http://nas.local (I saw an attempt to use the hostname but not all routers would do that for you)
    • trying to guess the correct host lan ip is always going to be tricky. If you have multiple ip addresses from different interfaces, vpns, you'll have to make a guess, so might as well give people a way to override
    • fyi I think in the past host network mode was considered insecure and discouraged, but I don't see current documentation calling that out - maybe they fixed the security problems, but either way, I like the port forwarding which isn't available in host mode so I can see what ports are going to this container
  • You probably want to rm -rf /var/lib/apt/lists/* after you are done with apt-get to save some space in the image, like https://github.com/docker-library/python/blob/23c83c5a82646e123df33d056f7dfbe1d78cfc8b/3.12/slim-bookworm/Dockerfile
  • I had some problems with having apt-get update stuck on like the 4th line reaching the debian repository for some reason and I gave up trying and fyi alpine works with some minor tweaks
FROM python:3.13-alpine

# Install required packages
RUN apk add --no-cache --virtual=build-dependencies \
		figlet \
		ffmpeg \
		chromium \
		chromium-chromedriver \
		gcc python3-dev musl-dev linux-headers \
	;

# Copy contents of the project into the image
RUN mkdir pikaraoke
COPY pikaraoke pikaraoke/pikaraoke
COPY pyproject.toml pikaraoke
COPY scripts/entrypoint.sh pikaraoke/

# Install Poetry
RUN pip install poetry

# Install dependencies
RUN cd pikaraoke && poetry install

# Make entrypoint script executable
RUN chmod +x pikaraoke/entrypoint.sh

# Set Entrypoint
ENTRYPOINT ["pikaraoke/entrypoint.sh"]

@vicwomg
Copy link
Owner

vicwomg commented Dec 23, 2024

Are you running this on your laptop? I had the same problem on my mac, but it worked fine on my Pi. My best guess currently is that the logic that tries to guess the IP is currently misinterpreting information on OSX when running inside docker, but is fine on pi.

The IP should definitely be available in host mode, so we probably just need to tweak the logic that guesses the IP? Probably in a separate PR though?

I would prefer not to merge a PR that has known incompatibility with one of the major supported OS. Unless that incompatibility is clearly communicated on runtime.

So this isn't really something we need to fix I think. It's established with docker containers that you can either:

  1. Not specify a mount and everything is just ephemeral (so in this case you would lose the downloaded songs if you delete the container)
  2. Specify a mount/volume if you want something to be durable outside the container. (for example if you look at the Usage section here, you specify volumes for the bits you want to exist somewhere outside, like the config files).

Admittedly I'm not familiar with the conventions. All I know is that the checked-in compose file defaults to /pikaraoke-songs which causes an error in my default configuration, and I imagine it would do the same most other people too. I don't know if a data directory at the hosts' fs root is a recommended unix convention, is that a sensible default value? Should it default to unspecified, with a comment to replace this with an existing directory for durability, or do most docker users just know that this is the case?

Just to give you a sense of where my head is at with both of these issues, with any release I immediately think of the support questions and tickets that will be filed from first-time users, and how to best avoid them.

To answer your other question about CLI parameters, I think they should be all specified in one variable, as parting them out to discrete options will ultimately always be a catch up game.

@Jamalarm
Copy link
Author

Admittedly I'm not familiar with the conventions. All I know is that the checked-in compose file defaults to /pikaraoke-songs which causes an error in my default configuration, and I imagine it would do the same most other people too. I don't know if a data directory at the hosts' fs root is a recommended unix convention, is that a sensible default value? Should it default to unspecified, with a comment to replace this with an existing directory for durability, or do most docker users just know that this is the case?

Ah I see your point, sorry I didn't realise the docker compose was actually broken (it definitely shouldn't be expecting something at the root of the users fs). Will fix it.

To answer your other question about CLI parameters, I think they should be all specified in one variable, as parting them out to discrete options will ultimately always be a catch up game.

Ok will make this change 👍

I would prefer not to merge a PR that has known incompatibility with one of the major supported OS. Unless that incompatibility is clearly communicated on runtime.

Understandable. The main issue here is that I don't actually know any Python so it is tricky for me to debug what is going on here and fix it. I can have a go but I may need your help tracing it through. My best guess is that the OS utility currently being called (on OSX) is giving the IP addresses in an unexpected order (first the internal Docker one, then the local network one).

@Jamalarm
Copy link
Author

Pushed a few changes:

  1. EXTRA_ARGS now available via the environment:
  2. Made the song storage path much more obvious that it needs to be replace. I followed the same convention the linuxserver project uses for its sample Docker compose files
  3. Removed chromium and chromium-driver as dependencies for the image (to save about 500mb space). I tested and these do not seem to be required when the server is running headless.

@vicwomg
Copy link
Owner

vicwomg commented Dec 23, 2024

Understandable. The main issue here is that I don't actually know any Python so it is tricky for me to debug what is going on here and fix it. I can have a go but I may need your help tracing it through. My best guess is that the OS utility currently being called (on OSX) is giving the IP addresses in an unexpected order (first the internal Docker one, then the local network one).

Here's the relevant line of code:

else:
# Other ip-getting methods are unreliable and sometimes return 125.0.0.1
# https://stackoverflow.com/a/28950774
s = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
try:
# doesn't even have to be reachable
s.connect(("10.255.255.255", 1))
IP = s.getsockname()[0]
except Exception:
IP = "127.0.0.1"
finally:
s.close()
return IP

IP is fetched from the socket library.

It seems clear from the comment that reliable host IP-fetching can be elusive. I can probably help investigate, but it would be helpful to know what this SHOULD be reporting vs. what it actually is. I'm seeing a LAN address in the 192.168.65.X range, which doesn't exist on my network.

Perhaps @samuelkyl 's comment about allowing the IP overriding is right. We can't be sure what the DNS configuration of the host will be, best to allow folks to configure it manually.

@Jamalarm
Copy link
Author

Perhaps @samuelkyl 's comment about allowing the IP overriding is right. We can't be sure what the DNS configuration of the host will be, best to allow folks to configure it manually.

Yep, makes sense. This is already possible with the EXTRA_ARGS: --url <something> option I just added, I tested it by passing http://pi:5555/ to my deployment and it worked fine. I would still like to get the auto-detection working at some point though.

I think we can do this in stages maybe? Nobody is going to be able to use the docker container anyway until we:

  1. Create the docker repo
  2. Set up the Github publish pipeline

So we can work on those things in parallel maybe?

@Jamalarm
Copy link
Author

It seems clear from the comment that reliable host IP-fetching can be elusive. I can probably help investigate, but it would be helpful to know what this SHOULD be reporting vs. what it actually is. I'm seeing a LAN address in the 192.168.65.X range, which doesn't exist on my network.

Yeah digging a bit deeper I'm not sure where that IP address is coming from. I looked at the docker network config (which shouldn't even really apply anyway as we're in host mode) but the subnets for the bridge network are 172.17.0.0/16 which isn't matching the IPs we're seeing.

This answer from ChatGPT might explain it actually:

  1. Docker's Virtual Network Interface on macOS/Windows
    If you're running Docker Desktop on macOS or Windows, Docker uses a virtual machine to host the Docker engine. In such setups:
    Docker creates a virtual network interface that connects the host system to this virtual machine.
    This interface often uses the subnet 192.168.65.0/24 or similar (e.g., 192.168.64.0/24).
    This IP (192.168.65.123) likely belongs to the Docker virtual network bridge connecting the host system to the Docker VM.

@vicwomg
Copy link
Owner

vicwomg commented Dec 24, 2024

I took a much needed deep dive into Docker yesterday. I think I have a better understanding of the ecosystem. I may open a new PR with some restructuring and enhancements, in which I'll be sure to credit you.

  • I was able to remove the poetry dependency, turns out pip can install directly from a poetry project's root directory. Doing so installs pikaraoke to the root filesystem. This also removes all the launch warnings
  • I will move the compose file to a docker-compose.yml.example so it's clear that it needs to be modified.
  • I was not able to solve the mac OS IP issues. I think manual IP configuration is the only way. I believe this is a limitation of OSX's virtualization stack: https://stackoverflow.com/questions/46286741/is-there-a-workaround-to-use-the-hosts-network-in-docker-for-mac
  • These changes cut the image size down about 100MB

I have discovered some more complications that will hold this project up

  • ARM and X86 cpus will require separate images
  • A docker image will likely not honor the raspberry_pi detection routines in pikaraoke, since they depend on key files existing in the fs. So pi-specific features, such as hardware h264 encoding, essential for speedy transcoding in pi4 and below, are lost
  • Python slim base images will not install ffmpeg > 5.0 meaning pitch shift does not work

Investigating these things in a separate branch which I will share soon

@vicwomg
Copy link
Owner

vicwomg commented Dec 24, 2024

New PR opened: #439

I found that the python bullseye slim base image can install a version of ffmpeg that supports transposition. It is also 200MB smaller, so there's that!

@vicwomg
Copy link
Owner

vicwomg commented Dec 25, 2024

I think I have the CI pipeline working! Builds both arm64 and amd64, though I haven't tested the latter.

https://hub.docker.com/repository/docker/vicwomg/pikaraoke/general

The dockerhub page has a more up to date docker compose file to use

@Jamalarm
Copy link
Author

Wooo exciting!

Thanks for getting that all sorted.

One comment looking at the docker page currently, I think you might just be pushing :latest currently. It would probably be good practice to push images with two tags (you can put many tags on one image), one with :latest and one with whatever the current concrete version number is, then people can choose to pin the verison if they wish. Otherwise Docker can decide to pull a newer version of the image in certain cases.

@Jamalarm
Copy link
Author

Closing this PR as the changes were rolled into #439

@Jamalarm Jamalarm closed this Dec 25, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants