rix

Hi, I have tried to set up the epicgames-freegames container in combination with an nginx reverse proxy at /epicgames. That does not work however. Any hints how to set up a subfolder?

Thanks for the quick fix!

I do not own two optical disk devices. From what others have reported, this should work though.

I do like this. Did I set this up right? https://github.com/rix1337/docker-templates/blob/master/rix1337/ca_profile.xml

Sure, I am also interested in a fix. Please let me know if you find a modification that I can then place in ripper.sh for all users. Haven't come across this error and google does not yield anything useful as well. If you find a reason I'll try to fix this, if you solve it yourself please let us know so I can improve the docker image. Thanks for yor posts and sorry I cannot help with solving the issues you have come across.

Thats reasonable. Ill look into adding some jre.

Are you sure you are posting in the right Thread? My ripper uses ripit for audio cds. cdparanoia is AFAIK not part of the script/image.

Video encoding is out of scope of this project. Please look elsewhere.

We just received a PR that should resolve this. https://github.com/rix1337/docker-ripper/pull/52

Yup, had to update to 0.15.2 which results in a builderror for libmakemkv. Issue on github is open. I have currently no idea how to fix this. https://github.com/rix1337/docker-ripper/issues/51

Freedb is down. Fortunately a few days ago a beta of ripit was pushed that now uses gnudb for ripit. This commit should resolve issue #1: https://github.com/rix1337/docker-ripper/commit/55c38cf841126595072cb40b817bf80b345cfd0d Your second issue I have no idea how to fix. Sounds like a hardware issue if it is not caused by #1. EDiT: Build with the new ripit version is up. Update and enjoy!

Yeah, maybe someone savvy will be able to do it directly, but you can automate stripping the isos by modifying your ripper.sh So at least the whole thing is automated. What those commands are, you will have to find out yourself.

As far as I can tell the exception you are seeing is thrown by gphotos. Please open an issue at their github repo, since I will likely not be able to fix this. Just to be sure, check again if you have followed the Readme to the letter: https://hub.docker.com/repository/docker/rix1337/docker-gphotos-sync 1. Start the container with the "Run" part (not using -it) 2. Create and place the client_secret.json at /config 3. Run the "Syncing" command while the container is still running (this time using -it) 4. Follow the instructions to log into your account. From now on "Syncing" should be callable through cron and work.

Ripping to ISO is a trivial task, mounting and directly copying over files is not - since that was never my goal, you will have to solve this yourself. If you want to try something simple, why not extract the iso with something like https://www.tecmint.com/extract-files-from-iso-files-linux/ and then deleting the iso when the copying is done. That should be fairly straightforward but you'll have to spend some time trying it out. I will unfortunately not invest more time into this.

Best of luck

Ripper is able to rip Data drives by itself, what are you trying to do with the above?

You should be able to easily fix this by adding a timestamp to the target path. Try adding this to the STORAGE_CD variable in your ripper.sh: $(date +%s) Should be line 15 https://github.com/rix1337/docker-ripper/blob/64b17f6cacda1bdabe9a8d05f5b6476e2cb705d6/root/ripper/ripper.sh#L15 so it looks like STORAGE_CD="/out/Ripper/CD/$(date +%s)" This should produce different subfolders for each run

The default password from https://github.com/rix1337/docker-google-musicmanager/blob/master/README.md should work.

Use any vnc client. Default port is 5900

Not without much more info. A log would be a great starting point.

For me it is working. AFAIK there appear to be issues if the app cannot read your mac address. No idea why it would not run on your end. Mine is working right now, but I have not relogged in for a few years.

Let me know, if you find out what caused this.

I am afraid "eject" will not work from within docker for your external drive. You need to find an alternative and replace the eject command in ripper.sh

Please make sure you have read the readme. https://github.com/rix1337/docker-ripper/blob/master/README.md#makemkv-needs-an-update I have just triggered a build that should update to the latest release.

I will only support ripit. You can however modify ripper.sh to your liking. A pending PR will switch the ripit backend to musicbrainz, so no reason to move to another tool afaik.