Yes, that was it. I haven't had any channel renumbering since I made the change.
Thank you for questioning this. Much better now.
1 Like
@bnhf there is something strange in OliveTin but I guess that's the way it works: the stdout output on the screen in the Logs tab only showed up to a certain point when I started it and then froze:
It hasn't shown anything else since I started it.
By looking around, I finally figured out that everything gets written to the file 192.168.18.120-8089_channels_dvr_monitor_channels_latest.log. I think you probably mentioned it at some point but I forgot.
By the way, this file will keep on growing the longer this script runs.
Is there any kind of automatic cleanup process that limits the size of a file and then will write over?
I always thought that stdout was only visible on the screen so that's the reason why I added the logging option in the script to log only the times when lineup changes are detected.
I don't see the logging option '-l' being used in OliveTin.
I thought about it more and I think I will push a new version with the logging option as a standard feature and not an option anymore.
That will be more suitable for the execution in OliveTin. 
I would prefer it only writes to the log file when changes are detected.
Maybe the no change events can go to stderr and not the log file?
I have to edit the log files every day or they get very long.
I don't want email/text notification.
It's not that it freezes -- stdout and stderr in OliveTin are not live viewers, they strictly reflect what was output to the console (or whatever else I direct there) at the time of the script run. For scripts that run in the background, I use a calling script that terminates, as this is required for OliveTin to function properly.
For those scripts, like yours that produce output on an ongoing basis, that output can be found in a log file -- as you discovered. Those log files are active until the next container or system restart, when they will be overwritten.
I did an "unpublished" env var for @chDVRuser as he wanted these particular logs to survive restarts. I haven't advertised that variable to prevent the log files from growing indefinitely for the average user. I could obviously implement some sort of log rotation system, but that seems a bit over-the-top for this project.
1 Like
I actually don't need log rotation.
I just don't want the log filling up every time it checks and finds no changes.
Since I don't use notifications (email/text) I'm wondering if you get notified every time it runs and finds no changes?
No, only on changes. I actually like knowing it ran even if there are no changes via the log file, but I'm also using the healthchecks.io option -- which notifies me if the script fails to run for any reason.
I would vote for retaining configurability, as we each have our preferences.
I do too.
Having a log file that keeps on growing with no rotation, not so much.
I just had a thought. How about this as a compromise...
- create a file called "last_activity.log"
- when checking for changes, write to this file what was found (or not) at that moment
- on the next check, overwrite the file and write the result of the check at that moment (and it will indicate the next time it will check)
This way, we still get to know if the script is still running, and the size of the activity log file is greatly reduced and managed.
I will also have the other log file that will only contain the lineup changes.
Thanks,
This is what I'm looking for.
If that's not possible, I'll just continue using my curl/jq scripts.
Not only is it possible, but it has already been implemented.
The way I did it though is with an option and this option is currently not being used/available in OliveTin.
I will change it to make it a standard feature without having to select an option.
2 Likes
Thanks. Will try it out when OliveTin for Channels is updated with it.
Version 3.1.0:
[IMPROVED] Typo in the name of the data sub-directory
[CHANGED] Logging the lineup changes is a standard feature now
[CHANGED] The log file will contain the lineup changes of the current year.
A new file is created every year with the year number in the name.[NEW] File "last_activity.log" to log the result of the last check only
@bnhf you can update OliveTin at your earliest convenience.
1 Like
Pushed as bnhf/olivetin:latest and bnhf/olivetin:2024.03.02 -- looks good!
2 Likes
Thanks guys! Looking good here.
Ran a quick test;
- add an M3U source with one channel
- add a second channel
- delete the first channel
- delete the M3U source
- re add the M3U source
It picked up everything except deleting the M3U source (to be expected).
1 Like
If I can detect a new source, I can also detect one that has been removed.
Even though this shouldn't be a surprise to the user since 99.999% of the time, it is the user that removes a source, I will still add it. You never know, if someday there is a critical bug or something, this will detect it.
It doesn't hurt to add this detection. I'll throw it in for the same price. 
That is quite generous of you Sir. I would have thought it'd double the price
When you're parsing /devices, any chance you can skip those with a null Lineup ("Lineup": "")
My HDHR Prime tuner is showing up in /devices on all my servers because Channels DVR sees it on the network.
I only have one of the servers using it where I assigned a guide provider for it.
/devices
[
{
"Provider": "m3u",
"DeviceID": "M3U-Pluto",
"FriendlyName": "Pluto",
"ModelNumber": "HDHRCOMPAT-1",
"Lineup": "XMLTV-Pluto",
"Channels": […]
},
{
"DeviceID": "Redacted",
"DeviceAuth": "123456789012345678901234",
"IPAddress": "192.168.1.7",
"TunerCount": 3,
"IsLegacy": false,
"FriendlyName": "HDHomeRun PRIME",
"FirmwareName": "hdhomerun3_cablecard",
"FirmwareVersion": "20230713",
"ModelNumber": "HDHR3-CC",
"Lineup": "", <--------------------- HDHR Tuner not assigned a Guide Provider
"Channels": […]
}
]
1 Like
Sure. That will be in the next version too. 
1 Like
I'm having problems getting the channels lineup script to run in olivetin. Any ideas of what to look for?
It looks like either a bug in my code or a specific corner case that I'm not handling properly.
Can you please provide the settings for all your sources?
@cyoungers Not sure if this is the issue, but you have a default value of "another-server" in with your environment variables, and I see that in the stderr output, which is never a good sign. Any env vars that don't apply to you need to have null values, or be deleted altogether, though I prefer to see you leave them (empty) in case of future need.
Also, are you using the latest docker-compose and env vars, as shown in the first post of the OliveTin thread?