Sounds good. I would have to look at an actual example to be sure.
host-ip_scriptname_latest.log wouldn't work for me as all my DVR's have the same IP address and different ports.
Would need host-ip-port_scriptname_latest.log
We're on the same page -- that's what I meant to write, host:port_scriptname_latest.log.
Seems like this will be a good approach.
1 Like
I know you really mean host-port_scriptname_latest.log 
Windows doesn't allow the colon character in a filename.
Doh! Yes, absolutely.
This might be useful if someone is remote and has remote access to OliveTin for Channels and needs to restart or stop their Channels DVR service.
I'll leave it up to you if you want to include it or not.
I just run it from a command line when needed.
I would show a warning before running it that anyone using it should know what they're doing and accept the consequences of continuing. It will stop anything in progress, including recordings.
Another excellent suggestion!
I've done a build under the :test tag, and it includes the following new or updated OliveTin Actions:
Restart or Shutdown a Channels DVR Server - Restart or shutdown a DVR the easy way!
Remove Comskip Markers from a Recording - If you've edited a recording to remove the commercials, or had Comskip run on a recording where there are no commercials, this action removes all commercial markers from the DVR for the recording.
List Channels with Comskip Off - This action has been updated to show the DVR name in stdout, and the most recent run of this command will be available as host-port_listcomskipignore_latest.log in the /config directory.
Mark an Episode for Re-recording - This action has been updated to show the DVR name in stdout, and the most recent run of this command will be available as host-port_markforrerecording_latest.log in the /config directory.
And, the current suite of OliveTin Actions:
In the next build, I'll be adding DVR name output to the stdout of all actions where it makes sense -- as well as producing log files in the form host-port_scriptname_latest.log. These will survive restarts, and allow for a quick check of recent results.
Container crashes.
Docker log for the container only shows this as STD OUT
standard_init_linux.go:230: exec user process caused: no such file or directory
And there is nothing in the /config directory.
Thanks for letting me know. I'm in Portugal, so I'm doing a bit of a funky multi-arch build with my laptop here as one node and the ARM node back in the US.
Probably something not quite right with the setup. You should be able to revert to :latest while I chase down the problem.
OK, if it matters, I had removed the :latest build container and image and emptied the /config mapped directory before installing this :test version. So it's a fresh install using the same environment variables I was using before.
docker pull bnhf/olivetin:test
docker run \
-d \
--name=olivetin \
--network=cdvr-net \
-p 192.168.1.3:1337:1337/tcp \
--restart=unless-stopped \
-v /volume1/docker/olivetin:/config \
-e "TZ=America/Los_Angeles" \
-e "UPDATE_SCRIPTS=true" \
-e "UPDATE_YAMLS=true" \
-e "CHANNELS_DVR=192.168.1.4:8489" \
-e "CHANNELS_DVR_ALTERNATES=192.168.1.4:8389 192.168.1.4:8089 192.168.1.4:8189 192.168.1.4:8289" \
bnhf/olivetin:test
@chDVRuser :test build should be good-to-go now. I pulled it here, and seemed fine in some quick testing. I'll work on adding additional log files to actions that could benefit from them next.
Here's my current recommended docker-compose for this project:
version: '3.9'
services:
olivetin:
image: bnhf/olivetin:${TAG} # Add the tag like latest or test to the environment variables below
container_name: olivetin
dns_search: ${TAILNET} # For Tailscale users using Magic DNS, add your Tailnet (tailxxxxx.ts.net) to use hostnames for remote nodes
ports:
- 1337:1337
environment:
- CHANNELS_DVR=${CHANNELS_DVR} # Add your Channels DVR server in the form hostname:port or ip:port
- CHANNELS_DVR_ALTERNATES=${CHANNELS_DVR_ALTERNATES} # Space separated list of alternate Channels DVR servers to choose from in the form hostname:port or ip:port
- CHANNELS_CLIENTS=${CHANNELS_CLIENTS} # Space separated list of Channels DVR clients you'd like notifications sent to in the form hostname or IP
- UPDATE_YAMLS=${UPDATE_YAMLS} # Set this to true to update config.yaml
- UPDATE_SCRIPTS=${UPDATE_SCRIPTS} # Set this to true to update all included scripts
- TZ=${TZ} # Add your local timezone in standard linux format. E.G. US/Eastern, US/Central, US/Mountain, US/Pacific, etc
volumes:
- ${HOST_DIR}/olivetin:/config # Add the parent directory on your Docker you'd like to use
- ${DVR_SHARE}:/mnt/dvr # This can either be a Docker volume or a host directory that's connected via Samba or NFS to your Channels DVR network share
restart: unless-stopped
#volumes: # use this section if you've setup a docker volume named channels-dvr, with CIFS or NFS, to bind to /mnt/dvr inside the container
#channels-dvr:
#external: true
And, sample environment variables:
TAG=latest
TAILNET=tailxxxxx.ts.net
CHANNELS_DVR=media-server6:8089
CHANNELS_DVR_ALTERNATES=utheater-pc:8089
CHANNELS_CLIENTS=appletv4k firestick-master
UPDATE_YAMLS=true
UPDATE_SCRIPTS=true
TZ=US/Mountain
HOST_DIR=/data
DVR_SHARE=/mnt/dvr
:test build working here now.
Tried a couple things and enabled channel change notifications again.
New :test build available, with a couple of new features to validate:
- Ping Channels DVR Server - I've been using this for a few days myself, and I really like it. This allows one to setup a scheduled ping of one or more servers -- with or without a healthchecks.io tie-in. If you're an Organizr user, there's a homepage integration for healthchecks.io:
And the second change (as requested by @chDVRuser) is the addition of:
- Support for use of a saved file with the "Generate Filtered Channels DVR Log" Action. Save a file in the /config directory with a .grep extension, and then reference it as file://your_saved_filter.grep in the filter field. NOTE: Any special characters in the saved grep search file will be escaped for you!
BTW, healthchecks.io supports lots of different integrations, so if you want push notifications on your phone instead of (or in addition to) e-mails you can set that up through healthchecks.io:
2 Likes
Thanks.
Working great.
Although it's easier to open the file with my grep parameters, copy & paste it than it is to key in
file://recordings.grep or file://scheduler.grep
Well shoot, sounds like we missed the mark then.
EDIT: Looking at the script, it appears the file:// part can be used or not -- the .grep at the end of the filename is the important part.
Much better!
It does work by entering the filename scheduler.grep
Remove Comskip Markers from a Recording timed out and failed.
Ran my windows command script on the file and it worked.
Here's an earlier run on a different recording that worked.
We need to increase the timeout from the default then. I'm thinking maybe 20 seconds? Depends on the max size of recordings that are being processed I'd imagine. If you could add a timeout to this section of the config.yaml, and if it seems adequate, I'll change it permanently. Make it the last line of the section, and be sure it lines up in the same column as title, icon, shell and arguments:
- title: Remove Comskip Markers from a Recording
icon: '<img src = "https://community-assets.getchannels.com/original/2X/5/55232547f7e8f243069080b6aec0c71872f0f537.png" width = "48px"/>'
shell: /config/marknocommercials.sh "{{ dvr }}" {{ file_id }}
arguments:
- name: dvr
description: Channels DVR server to use.
choices:
- title: media-server6:8089
value: media-server6:8089
- title: utheater-pc:8089
value: utheater-pc:8089
#lastchoice dvr default
- name: file_id
type: int
description: The File ID can be found using Library - TV Shows / Movies - <show name> - <episode name> - Options - View Details - File ID.
timeout: 20
That will most likely fix it, but it will take a week or so to be sure since I only do a few of these per week.
If the timeout is for the action, then since this one issues 3 curl commands and each response is the whole file json, it might be exceeding the default timeout.
What is the default timeout value?
I read somewhere that it's 3 seconds -- though my sense is that it's actually a second or two more than that.
I would say make the change permamnent.
I can't see it taking more than 20 seconds.
The thing that takes the longest is regenerating the video index, but the curl command returns as soon as that starts and doesn't wait for it to complete, as evidenced by the DVR log.
2023/11/04 21:28:15.724242 [IDX] Generating video index for file-2517: TV/Planet Earth III/Planet Earth III S01E01 Coasts 2023-11-04-1700.mpg
2023/11/04 21:28:32.765977 [IDX] Finished video index generation for file-2517 in 17s