Hmmm. Watching different Pluto channels for about 20.minutes now, not one glitch. (Using the old version I mentioned previously)
I'll look into it this evening. I can't reproduce the same issues you guys are describing. What channels are you noticing this on the worst?
Every channel for me. I mainly watch the Star Trek channels, or Stargate, X-Files, Ghost Hunters, Top Gear....
I notice this in the CDVR Logs when the issues happen.
2026/03/01 12:34:32.006089 [HLS] Probed live stream in 1.171875s: h264 1280x720 progressive 2430298bps
2026/03/01 12:34:39.067038 [HLS] ffmpeg: ch2078-dANY-ip192.168.0.15-remux: [hls @ 00000204d7954e40] Non-monotonic DTS in output stream 0:1; previous: 1802880, current: 1800630; changing to 1802881. This may result in incorrect timestamps in the output file.
2026/03/01 12:34:39.067038 [HLS] ffmpeg: ch2078-dANY-ip192.168.0.15-remux: [hls @ 00000204d7954e40] Non-monotonic DTS in output stream 0:1; previous: 1802881, current: 1802550; changing to 1802882. This may result in incorrect timestamps in the output file.
2026/03/01 12:35:09.910317 [HLS] ffmpeg: ch2078-dANY-ip192.168.0.15-remux: [hls @ 00000204d7954e40] Non-monotonic DTS in output stream 0:1; previous: 4503990, current: 4503630; changing to 4503991. This may result in incorrect timestamps in the output file.
2026/03/01 12:35:25.082616 [HLS] ffmpeg: ch2078-dANY-ip192.168.0.15-remux: [aist#0:2/aac @ 00000204da058440] timestamp discontinuity (stream id=257): -250667, new offset= 250667
2026/03/01 12:35:46.326339 [HLS] Stopping transcoder session ch2078-dANY-ip192.168.0.15 (out=1m25.432333s finished=false first_seq=1 last_seq=24)```
2026/03/01 12:36:02.031442 [TNR] Opened connection to M3U-Pluto for ch2074 Star Trek
2026/03/01 12:36:02.031442 [HLS] Starting live stream for channel 2074 from 192.168.0.15 (bitrate=3321kbps)
2026/03/01 12:36:02.903041 [HLS] Session ch2074-dANY-ip192.168.0.15 started in 871.5992ms
2026/03/01 12:36:03.157174 [HLS] Probed live stream in 1.124499s: h264 1216x684 progressive 2772318bps
2026/03/01 12:38:49.968053 [HLS] ffmpeg: ch2074-dANY-ip192.168.0.15-remux: [hls @ 000001585d45b5c0] Non-monotonic DTS in output stream 0:2; previous: 16161720, current: 16159800; changing to 16161721. This may result in incorrect timestamps in the output file.
2026/03/01 12:38:49.980077 [HLS] ffmpeg: ch2074-dANY-ip192.168.0.15-remux: [in#0/mpegts @ 000001585b0db0c0] New data stream with index 3 at pos:63233612 and DTS:179.825s
2026/03/01 12:39:16.871980 [HLS] Stopping transcoder session ch2074-dANY-ip192.168.0.15 (out=3m24.619667s finished=false first_seq=1 last_seq=77)
2026/03/01 12:39:16.876001 [TNR] Closed connection to M3U-Pluto for ch2074 Star Trek
I hate to ask you to be a guinea pig, but would you switch from HLS to MPEG-TS and see if that will smooth it out?
That did something....now I am not seeing adds during the ad break, but the Pluto logo screen thingy with that annoying music. Not had any issues, yet.
I think Channels will use its internal FFmpeg to repackage the stream in MPEG-TS. I could be wrong, but I think it does. If it does, that should help a lot with the issue you are having.
Indeed, though, I have to wonder, if that was the "fix" for the past issues, I just had forgotten about it. 
Might me, cause, yea,. no adds, just the Pluto screen, and it gets ahead cause it skips some adds or something, Show finishes like 5 min sooner, and if you close out, and re-open, it is playing like 10 min back or something. There also was the weird thing of some channels that would just skip back like 5 min randomly.
Pluto does a horrible job with its timestamps on its stream.
So, am seeing ads along with the Pluto logo screen thing, on the Top Gear UK channel, Apple TV handles them fine, so far. Web interface streaming in FF, it seems to not like it, plays a couple of them, just stops and has the play icon and won't restart...(only using the web interface for playback testing.)
At this point, Pluto is behaving just as before the big change.
Hopefully I am good for now. 
Thank You for all your effort and dedication to this project.
I hope so. I would advise anyone have freezing issues to make sure to use the MPEG format when setting up the Custom Channel in Channels DVR. Thanks again.
If you can, try the latest version and set it as MPEG when you create the Channels Custom Channel. Let me know if it works.. Thanks.
Just a general thought from a guy who couldn't code his way out of a paper bag. Been tinkering with Docker Desktop lately, and I'm still lost most of the time. I've kept it on my server box for a few years in case I ever wanted to learn, or if something like this Pluto mess ever happened, and a container was the best solution.
But this is something I've observed after the last several days running your Windows solution and the Maddox and KineticMan containers. I see the same issues in Maddox's container and your app. KineticMan's container works perfectly, just recorded 4 shows at once, and it was all perfect. None of the commercial issues like this has. It even seems to tune faster and just feels snappier when changing channels. FWIW, my server box is almost 15 yrs old and likely very underpowered.
If you can figure out where his code is, perhaps there's a clue? He also mentions how he created it to work around the login thing.
Hope this is a clue. I think my ancient server is better off with your app instead of what feels like a resource-heavy Docker Desktop. Thanks for your efforts.
His is a fork of my Pluto docker which is a fork of jgomaz docker which is what this app of built off of. They handle things the same basic way except this app is written in C# and our Docker is using Python. I am not experiencing any issues with either one, but I am using a newer PC. Like I said, this app simply sends a Pluto link to channels, it does not control the stream quality or how the Commercials are injected by Pluto.
I installed v1.1.2 yesterday, and did the SAVE logins. It saved those, plus the port 7777. I verified that by looking in the config file.
This morning, I woke up to no Pluto channels, so checked the port on the v1.1.2 screen, and it had changed to 7778. Not sure why. It's running on the same Beelink mini pc as my Channels server, and that didn't reboot last night, so not sure what happened.
That is odd. I will look into it. You should be able to change it back to 7777 in the settings and restart the server which should set the port again. I will look into making the IP port be more resilient. I am also looking into adding some additional logic to improve the stream resilience too.
Yeah, it makes no sense. I'll watch it, and if it happens again, see if I can figure out a pattern. When I installed this version, I did forget to kill the old instances FIRST, so it did pick a higher port then. I noticed, then killed all the instances with Task Manager, modified the port back to 7777 in the config file. Then I re-ran the v1.1.2 to start it back up. Maybe something happened because of that sequence of events. Maybe I forgot to click Save Logins again, and it ignored my manually setting the port to 7777 in the config file. Though when it started up, it did show on port 7777 then. Who knows.
You don't need to save logins on restart. Once you save them, they are set. You would only need to save if you make a change.
I went back through the logic being used by @KineticMan Docker version. The only difference I can find is that his is using the client id round robin that I had originally. I will revert back to that and see if it helps. It is hard for me to find the issue since mine works just fine, even on multiple channels being used.
@jkr4m3r I think I will put a test version up instead of another latest. I will see if I can isolate what may be causing the problem by adding some event logging in the test version that might help me better understand what is different about your setup and mine. Right now, I am blindly trying to find a needle in a haystack and I'm not even sure I am looking in the right haystack.
Is it possible to change the port? I saw nothing in settings.json