Thanks! If it helps at all, Blue Stream Fiber actually kicked out Comcast from the neighborhood. 
Thanks for the info on logs & Portainer passwords. I've saved both for future reference as needed.
For the Portainer problem I didn't rely entirely on AI (typically use it as a last resort), and remember looking through docs and they were so daunting that I was afraid to to mess with setting up yet another docker to fix a docker that's causing trouble (swallowing the spider to catch the fly).
For example, resetting a Portainer password is not difficult. From the Portainer docs:
Looking at it now I still wouldn't really know what to do. I see a line that says "you'll need to mount the Portainer data volume." Ok, what is the data container volume and how do you mount it? It also mentions something about a "bind mount," which is also Greek to me! I think one of the frustrating things about Docker-related stuff is that so often the instructions say to do a thing but not how to do it - or even provide links to how to do it if they don't want to break the flow of the main instructions. A glossary would certainly be a handy thing. Yes, maybe with enough effort I could have painstakingly looked up each of those mysteries, but it didn't seem worth the additional frustration to use a thing advertised as making things easier, when I could much more easily paste in whatever "docker run" command was provided.
I had also looked via Google (which was a major rabbit-hole source), and the Reddit Portainer sub, which was aimed at people who'd been using it forever and had no help for beginners. I didn't get a reply to my post there looking for help.
So I'm still not convinced to give Portainer a try, but will definitely use the command to get full logs next time I need them.
Also this is an option for those who have TV Providers who lack an app with deeplinks
@KineticMan and @bnhf,
Are there any tweaks we can make to the player quality-wise? I find that when I use the ah4c method, I get instances of pixelation (sometimes a quarter of the screen) while watching. I suspect the player, and not the capture card, because when I use the Windows Android Bridge project, I don't get anything like that.
I'd like to stay with the FastChannels project because of the faster tune times and that the WAB project has a tendency to run into the "heavily congested network" message from Directv too often.
During the US Open I was using the FastChannels bridge for sometimes 10 or 12 hours continuously, and never saw any pixelation.
Can you give us any other clues? Also, I wonder if the network congested messages in WAB could be a different manifestations of the same issue?
The WAB issue is when the channel is initialing tuning. If it comes up, I just have to tune another channel, then go back and tune the 1st channel again and it works.
Looking at the Activity page for ah4c, it shows a consistent 9-10Mbps in and 8-9Mbps out. The pixelation does not have any specific timing, it happens in tv shows, movies, and sports. What should I look for?
Hi @KineticMan
Ive noticed that some of the authorization for COX TVE is barfing suddenly. I guess Spectrum bought out COX. Any advice on re authorization with COX/Spectrum within fast channels/
I guess we are officially in the Whac-A-Mole territory. Appreciate all you do!!
Figured we were on borrowed time with Cox. Bummer.
Let me try to get Spectrum up and going.
2 Likes
FYI,
FDL, ESPN4CC, and the other FastChannels feeds are on the same PC, but none of them have the same issue.
What about peacock, abc, directvstreamfree/paid, hbomax fast channels,? Not sure if Paramount has any?
I'm not really sure, since I'm not seeing this issue.
How is the transcoding being done on your "virtual encoder", hardware or software? Maybe try switching from one to the other temporarily to see if that makes a difference. Any ffmpeg errors in your CDVR log for that transcoding?
The FC Player is pretty simple, so that seems unlikely to be the problem.
agreed- it's just a pass through. no caching or proxying (outside the license server info). hard to imagine anything FC does would affect stream quality.
I just changed the transcoding from hardware to software, not much difference. Here are the logs entries from CDVR. All of the stream sources in my custom channels are set to mpeg-ts, so I don't know what the "HLS" in the entries mean.
2026/09/17 08:39:53.133364 [TNR] Opened connection to M3U-FastChannelsAH4CDirectvAndroidBridgeah4c for ch702 AMC HD
2026/09/17 08:39:53.133911 [HLS] Starting live stream for channel 702 from 192.168.88.245
2026/09/17 08:39:54.155884 [HLS] ffmpeg: ch702-dANY-ip192.168.88.245-remux: [mpegts @ 0000029749a66400] DTS 95647 < 168000 out of order
2026/09/17 08:39:54.159085 [HLS] ffmpeg: ch702-dANY-ip192.168.88.245-remux: [vist#0:0/h264 @ 000002974b74ee40] timestamp discontinuity (stream id=256): -837256, new offset= 837256
2026/09/17 08:39:54.773045 [HLS] Probed live stream in 1.6385847s: h264 1920x1080 progressive 9836769bps
2026/09/17 08:39:55.222955 [HLS] Session ch702-dANY-ip192.168.88.245 started in 2.0890367s
2026/09/17 08:39:55.230382 [ENC] Starting encoder for ch702 in D:\My Videos\Streaming\sessions\ch702-dANY-ip192.168.88.245-3502646565\encoder-1-952394570 at 1 (0.355100) (encoder=h264_amf, codec=h264, acodec=copy, resolution=1080, deinterlacer=linear, bitrate=5867, segment_size=0.01)
2026/09/17 08:39:55.279350 [HLS] ffmpeg: ch702-dANY-ip192.168.88.245-1-h264-copy---5867-0-1080-0-0--linear-false-false-0.01-0: [vost#0:0/h264_amf @ 000001c5a27fc600] -enc_time_base -1 is deprecated, use -enc_timebase demux
2026/09/17 08:40:19.269976 [HLS] ffmpeg: ch702-dANY-ip192.168.88.245-1-h264-copy---5867-0-1080-0-0--linear-false-false-0.01-0: [vist#0:0/h264 @ 000001c59f5bbe40] corrupt decoded frame
2026/09/17 08:41:00.677603 [HLS] ffmpeg: ch702-dANY-ip192.168.88.245-remux: [hls @ 000002974b13c580] Timestamps are unset in a packet for stream 0. This is deprecated and will stop working in the future. Fix your code to set the timestamps properly
2026/09/17 08:41:03.635356 [HLS] ffmpeg: ch702-dANY-ip192.168.88.245-1-h264-copy---5867-0-1080-0-0--linear-false-false-0.01-0: Last message repeated 1 times
2026/09/17 08:41:03.635898 [HLS] ffmpeg: ch702-dANY-ip192.168.88.245-1-h264-copy---5867-0-1080-0-0--linear-false-false-0.01-0: [h264 @ 000001c5a1d738c0] Invalid NAL unit 0, skipping.
2026/09/17 08:41:03.642509 [HLS] ffmpeg: ch702-dANY-ip192.168.88.245-1-h264-copy---5867-0-1080-0-0--linear-false-false-0.01-0: [h264 @ 000001c5a1d738c0] error while decoding MB 34 50, bytestream -11
2026/09/17 08:41:03.840896 [HLS] ffmpeg: ch702-dANY-ip192.168.88.245-1-h264-copy---5867-0-1080-0-0--linear-false-false-0.01-0: [vist#0:0/h264 @ 000001c59f5bbe40] corrupt decoded frame
2026/09/17 08:41:08.698009 [HLS] ffmpeg: ch702-dANY-ip192.168.88.245-1-h264-copy---5867-0-1080-0-0--linear-false-false-0.01-0: [h264 @ 000001c5a2489f00] Invalid NAL unit 0, skipping.
2026/09/17 08:41:08.941608 [HLS] ffmpeg: ch702-dANY-ip192.168.88.245-1-h264-copy---5867-0-1080-0-0--linear-false-false-0.01-0: [vist#0:0/h264 @ 000001c59f5bbe40] corrupt decoded frame
2026/09/17 08:41:13.016629 [HLS] ffmpeg: ch702-dANY-ip192.168.88.245-1-h264-copy---5867-0-1080-0-0--linear-false-false-0.01-0: [h264 @ 000001c5a248b980] left block unavailable for requested intra mode
2026/09/17 08:41:13.016629 [HLS] ffmpeg: ch702-dANY-ip192.168.88.245-1-h264-copy---5867-0-1080-0-0--linear-false-false-0.01-0: [h264 @ 000001c5a248b980] error while decoding MB 0 10, bytestream 31199
2026/09/17 08:41:13.223590 [HLS] ffmpeg: ch702-dANY-ip192.168.88.245-1-h264-copy---5867-0-1080-0-0--linear-false-false-0.01-0: [vist#0:0/h264 @ 000001c59f5bbe40] corrupt decoded frame
2026/09/17 08:42:08.642502 [HLS] ffmpeg: ch702-dANY-ip192.168.88.245-1-h264-copy---5867-0-1080-0-0--linear-false-false-0.01-0: Last message repeated 11 times
2026/09/17 08:42:08.644584 [HLS] ffmpeg: ch702-dANY-ip192.168.88.245-1-h264-copy---5867-0-1080-0-0--linear-false-false-0.01-0: [h264 @ 000001c5a248aac0] left block unavailable for requested intra4x4 mode -1
2026/09/17 08:42:08.644584 [HLS] ffmpeg: ch702-dANY-ip192.168.88.245-1-h264-copy---5867-0-1080-0-0--linear-false-false-0.01-0: [h264 @ 000001c5a248aac0] error while decoding MB 0 23, bytestream 122366
2026/09/17 08:42:08.853166 [HLS] ffmpeg: ch702-dANY-ip192.168.88.245-1-h264-copy---5867-0-1080-0-0--linear-false-false-0.01-0: [vist#0:0/h264 @ 000001c59f5bbe40] corrupt decoded frame
2026/09/17 08:42:14.976861 [HLS] Stopping transcoder session ch702-dANY-ip192.168.88.245 (out=2m21.526956s finished=false first_seq=1 last_seq=139)
2026/09/17 08:42:14.977366 [TNR] Closed connection to M3U-FastChannelsAH4CDirectvAndroidBridgeah4c for ch702 AMC HD
2026/09/17 08:42:15.047194 [ENC] Stopped encoder for ch702 in D:\My Videos\Streaming\sessions\ch702-dANY-ip192.168.88.245-3502646565\encoder-1-952394570 after encoding 1 to 131
2026/09/17 08:42:15.047194 [SNR] Buffer statistics for ch702 AMC HD: buf=0% drop=0%
2026/09/17 08:42:15.318034 [TNR] Sharing existing connection to M3U-USBHDMI for ch10000 USB HDMI Capture (clients=2, len=0)
2026/09/17 08:42:15.612541 [SNR] Buffer statistics for 192.168.88.30 (192.168.88.30) for ch10000 USB HDMI Capture: buf=0% drop=0%
2026/09/17 08:42:16.798077 [TNR] Opened connection to M3U-FastChannelsAH4CDirectvAndroidBridgeah4c for ch702 AMC HD
2026/09/17 08:42:16.798077 [HLS] Starting live stream for channel 702 from 192.168.88.245
2026/09/17 08:42:17.146911 [HLS] ffmpeg: ch702-dANY-ip192.168.88.245-remux: [mpegts @ 000002751e135c00] DTS discontinuity in stream 0: packet 14 with DTS 168000, packet 15 with DTS 12963543
2026/09/17 08:42:17.264538 [HLS] Probed live stream in 465.9084ms: h264 1920x1080 progressive 25400bps
2026/09/17 08:42:18.170741 [HLS] Session ch702-dANY-ip192.168.88.245 started in 1.3726602s
2026/09/17 08:42:49.863506 [HLS] Stopping inactive session ch702-dANY-ip192.168.88.245
2026/09/17 08:42:49.863506 [HLS] Stopping transcoder session ch702-dANY-ip192.168.88.245 (out=32.997822s finished=false first_seq=1 last_seq=1)
2026/09/17 08:42:49.863506 [TNR] Closed connection to M3U-FastChannelsAH4CDirectvAndroidBridgeah4c for ch702 AMC HD
2026/09/17 08:42:49.870633 [SNR] Buffer statistics for ch702 AMC HD: buf=0% drop=0%
2026/09/17 08:42:50.607175 [SNR] Buffer statistics for 192.168.88.30 (192.168.88.30) for ch10000 USB HDMI Capture: buf=0% drop=0%
Leave it at hardware then.
Were you seeing this same issue when you were using the single encoder "Fixed capture stream" approach via FastChannels (i.e. no ah4c involved)? If you're not sure, can you restore that setup to test?
Will do.
Ok, using the single encoder was rock solid. No pixelation and the picture quality actually looked richer. Below are the CDVR log entries.
2026/09/17 10:38:14.762427 [TNR] Opened connection to M3U-USBHDMI for ch10000 USB HDMI Capture
2026/09/17 10:38:14.762427 [TNR] Opened connection to M3U-FastChannelsFCDirectvAndroidBridge for ch7002 AMC HD
2026/09/17 10:38:14.762427 [HLS] Starting live stream for channel 7002 from 192.168.88.245
2026/09/17 10:38:15.023272 [HLS] ffmpeg: capture-usb-hdmi: [aist#0:1/pcm_s16le @ 0000016f3148d500] Guessed Channel Layout: stereo
2026/09/17 10:38:15.023272 [HLS] ffmpeg: capture-usb-hdmi: [vost#0:0/h264_amf @ 0000016f321d6f80] -enc_time_base -1 is deprecated, use -enc_timebase demux
2026/09/17 10:38:15.023782 [HLS] ffmpeg: capture-usb-hdmi: [aost#0:1/aac @ 0000016f321dafc0] -enc_time_base -1 is deprecated, use -enc_timebase demux
2026/09/17 10:38:15.642340 [HLS] Probed live stream in 879.377ms: h264 1920x1080 progressive 277294bps
2026/09/17 10:38:16.534171 [HLS] Session ch7002-dANY-ip192.168.88.245 started in 1.7712053s
2026/09/17 10:38:49.885076 [HLS] Stopping inactive session ch7002-dANY-ip192.168.88.245
2026/09/17 10:38:49.885076 [HLS] Stopping transcoder session ch7002-dANY-ip192.168.88.245 (out=34.344433s finished=false first_seq=1 last_seq=1)
2026/09/17 10:38:49.885076 [TNR] Closed connection to M3U-FastChannelsFCDirectvAndroidBridge for ch7002 AMC HD
2026/09/17 10:38:49.889053 [SNR] Buffer statistics for ch7002 AMC HD: buf=0% drop=0%
2026/09/17 10:38:50.013568 [SNR] Buffer statistics for 192.168.88.30 (192.168.88.30) for ch10000 USB HDMI Capture: buf=0% drop=0%
The mystery deepens, as ah4c is generally just a proxy (no decode, no re-encode, no color touch at all), although there are settings now that can change that. Can you confirm this is still the exact set of env vars you were using:
EDIT: With the addition of a FASTCHANNELS_URL value of course.
EDIT2: And also, if you could confirm you haven't enabled anything through in-app settings, like closed captions.
They look the same to me and nothing else enabled. I noticed that in the single encoder Stream Encoder URL it does not have the added "format=ts&codec=copy" that is in the ah4c variable. Should that make any difference?
TAG=latest
CONTAINER_NAME=ah4c
HOSTNAME=ah4c
DOMAIN=local
DOCKER_RUNTIME=runc
GPU_DEVICE=/dev/null
HOST_PORT=7654
IPADDRESS=192.168.88.30:7654
NUMBER_TUNERS=1
TUNER1_IP=192.168.88.113:5555
ENCODER1_URL=http://192.168.88.30:8089/devices/M3U-USBHDMI/channels/10000/stream.mpg?format=ts&codec=copy
STREAMER_APP=scripts/firetv/fastchannels
PYATV=false
CHANNELSIP=192.168.88.30
FASTCHANNELS_URL=http://192.168.88.30:5523
ALERT_WEBHOOK_URL=
LIVETV_ATTEMPTS=5
CREATE_M3US=false
UPDATE_SCRIPTS=true
UPDATE_M3US=true
TZ=America/Los_Angeles
SPEED_MODE=false
KEEP_WATCHING=4h
AUTOCROP_CHANNELS=
LINKPI_HOSTNAME=
LINKPI_USERNAME=
LINKPI_PASSWORD=
USER_SCRIPT=
NULL_FRAME_INSERTION=false
PLAYBACK_DETECTION=false
PLAYBACK_STATIC_TIMEOUT=
PLAYBACK_DELAY=2
PREROLL_FILE=
ENCODER_CODEC=h264
HEARTBEAT_INTERVAL=0
NVIDIA_VISIBLE_DEVICES=
NVIDIA_DRIVER_CAPABILITIES=
HOST_DIR=/data
CDVR_STARTING_CHANNEL=8000
CDVR_M3U_NAME=directv.m3u
1 Like
I wouldn't think so, but it's suspiciously on point. Can you either switch back to ah4c, and try with those modifiers removed -- or at minimum, add them to CAPTURE/ENCODER STREAM URL. Ideally, I'd prefer you try the former, if you're willing.