Spin up a new recording and watch the status from the home screen and see if you have drops and high buffer. I think its a ui bug maybe becuase my recordings are fine after the fact.
Nope.
Activity
Recording ch6034 for Friends until 3:00PM: buf=0% drop=0% timeouts=0 segment_timeouts=0 playlist_timeouts=0
Ahh Try OTA... Below is what happened for me over the course of the last 2 min...
*Recording ch3.1 for BIG3 Basketball until 6:00PM: strength=98% quality=100% symbol=100% rate=9.1Mb/sec buf=29% drop=0%*
*Recording ch3.1 for BIG3 Basketball until 6:00PM: strength=98% quality=100% symbol=100% rate=11.5Mb/sec buf=70% drop=0%*
*Recording ch3.1 for BIG3 Basketball until 6:00PM: strength=98% quality=100% symbol=100% rate=11.8Mb/sec buf=100% drop=17%*
*Recording ch3.1 for BIG3 Basketball until 6:00PM: strength=98% quality=100% symbol=100% rate=10Mb/sec buf=100% drop=38%*
*Recording ch3.1 for BIG3 Basketball until 6:00PM: strength=98% quality=100% symbol=100% rate=10.8Mb/sec buf=100% drop=51%*
Then once the timeouts pass the avg drop stats dwindle down...
2026/06/20 17:41:19.768983 [DVR] Recording for job 1781991679-ch3.1 from 104BD623 ch3.1 into "TV/BIG3 Basketball/BIG3 Basketball Week 1 Los Angeles 2026-06-20-1741.mpg" for 19m10.54190308s
2026/06/20 17:41:19.798422 [DVR] Refreshing metadata for BIG3 Basketball (14259172)
2026/06/20 17:41:39.855876 [WRN] Timeout while getting series info for tms/14259172: retrying
2026/06/20 17:42:00.857435 [WRN] Timeout while getting series info for tms/14259172: retrying
2026/06/20 17:42:21.858882 [WRN] Timeout while getting series info for tms/14259172: retrying
2026/06/20 17:42:42.859952 [WRN] Timeout while getting series info for tms/14259172: retrying
2026/06/20 17:43:03.861536 [ERR] Failed to get series info for tms/14259172: Get "https://contentdb.fancybits.co/api/series/tms/14259172": context deadline exceeded
2026/06/20 17:43:03.918998 [IDX] Generating video index for job 1781991679-ch3.1
Buffer back to 0% and drops will steadily decline...
I don't have an OTA tuner (it's an HDHR Prime)
Here's my TVE recording
2026/06/20 14:30:00.000461 [DVR] Starting job 1781991000-ch6034 Friends on ch=[6034]
2026/06/20 14:30:03.832743 [TVE] stream timestamps: tbsp: start_at=2026-06-20T14:19:52-07:00 end_at=2026-06-20T14:29:50-07:00 live_delay=7.013732431s
2026/06/20 14:30:03.832887 [TNR] Opened connection to TVE-YouTubeTV for ch6034 TBSP
2026/06/20 14:30:03.833320 [DVR] Recording for job 1781991000-ch6034 from TVE-YouTubeTV ch6034 into "TV/Friends/Friends S06E25 2000-05-18 The One With the Proposal 2026-06-20-1430.mpg" for 30m29.979709788s
2026/06/20 14:30:04.357803 [DVR] Refreshing metadata for Friends (183931)
2026/06/20 14:30:25.422234 [WRN] Timeout while getting series info for tms/183931: retrying
2026/06/20 14:30:46.423612 [WRN] Timeout while getting series info for tms/183931: retrying
2026/06/20 14:31:07.424524 [WRN] Timeout while getting series info for tms/183931: retrying
2026/06/20 14:31:28.425531 [WRN] Timeout while getting series info for tms/183931: retrying
2026/06/20 14:31:49.426736 [ERR] Failed to get series info for tms/183931: Get "https://contentdb.fancybits.co/api/series/tms/183931": context deadline exceeded (Client.Timeout exceeded while awaiting headers)
2026/06/20 14:31:51.087084 [IDX] Generating video index for job 1781991000-ch6034
Activity
Recording ch6034 for Friends until 3:00PM: buf=0% drop=0% timeouts=0 segment_timeouts=0 playlist_timeouts=0
yeah all of my m3u sources are perfectly fine. Its just OTA HDHR I think...
I'm not getting buffering when recording from my HDHD Prime.
Maybe they fixed the server problem (I'm not seeing any new errors or warnings).
I am getting something similar for TMDB.
2026/06/20 19:09:28.039257 [ERR] Failed to get movie info for tmdb/8850: Get "https://contentdb.fancybits.co/api/movies/tmdb/8850": net/http: request canceled (Client.Timeout exceeded while awaiting headers)
2026/06/20 19:09:48.040452 [WRN] Timeout while getting movie info for tmdb/11528: retrying
2026/06/20 19:10:09.045149 [WRN] Timeout while getting movie info for tmdb/11528: retrying
2026/06/20 19:10:30.047867 [WRN] Timeout while getting movie info for tmdb/11528: retrying
2026/06/20 19:10:51.052433 [WRN] Timeout while getting movie info for tmdb/11528: retrying
Yep. Mine has been logging the errors and warnings again for the past hour.
context deadline exceeded
database is locked
request canceled (Client.Timeout exceeded while awaiting headers)
Timeout retrying
I updated server to 2026.06.20.0022 earlier today.
I now see on the sever Admin UI constant activity of it trying to refresh info on my local library files but failing.
Tons of this:
Edit: Many those TMDB ids pulls up movies/shows in my local library on TMDB, but, are French pages not the English ones....very odd. Some IDs, are things not in my library. Is this trying to do a Guide
refresh and failng?
Edit2: I been watching M3U channels, and a few recordings. No OTA or TVE today.
What do you mean same result? Did you see drops on that ping?
This sounds like a network issue though it could be somewhere on the Internet. If the issue continues, please open the console for your container and Ping your gateway and also Google if the gateway is good. Then do a traceroute to contentdb.fancybits.co
With what others are posting I did a trace. On on FIOS in NYC.
Tracing route to contentdb.fancybits.co [104.26.2.161]
over a maximum of 30 hops:
1 <1 ms <1 ms <1 ms unifi.localdomain [192.168.2.1]
2 3 ms 2 ms 2 ms lo0-100.nycmny-vfttp-375.verizon-gni.net [96.246.23.1]
3 7 ms 5 ms 3 ms g101-0-0-21.bstnma-lcr-21.verizon-gni.net [100.41.209.154]
4 * * * Request timed out.
5 9 ms * * customer.alter.net [152.193.5.194]
6 6 ms 6 ms 7 ms 162.158.61.109
7 4 ms 6 ms 6 ms 104.26.2.161
It appears there is some congestion between Verizon and Alternet yet some traffic is getting through. Note: I'm not having Channels DVR issues.
Well, from a UK perspective, this stopped after about a couple of hours - not long after my initial append. The suggestion of a hole somewhere in the internet sounds a plausible explanation. Fortunately all recordings (HDR) continued just fine.
Looks to be an issue between Cloudflare and the fancybits server, this from Cloudflare:
What happened?
There is an unknown connection issue between Cloudflare and the origin web server. As a result, the web page can not be displayed.
What can I do?
If you are a visitor of this website:
Please try again in a few minutes.
If you are the owner of this website:
There is an issue between Cloudflare's cache and your origin web server. Cloudflare monitors for these errors and automatically investigates the cause. To help support the investigation, you can pull the corresponding error log from your web server and submit it our support team. Please include the Ray ID (which is at the bottom of this error page).
Chief
Meaning i changed my system dns to google to rule out any localized DNS issues.
Why do you believe this? What evidence lead to this conclusion?
Sorry everyone: contentdb is back now. We're looking into what happened.
2 Likes
@eric should an hdhr recroding fill the buffer and eventually transition to packet loss when the contentdb is unavailable? Im thinking of situations where the end user's internet is down. Or is this just a UI issue as the recordings turned out ok in the end?
I tested through 3 different internet providers in different locations and all said the server was unreachable, and all 3 locations came up to the cloudflare page even though they each had different DNS servers set. Now we know thru Eric that the reason was the server was down, which fits with the results from Cloudflare.
3 different DNS servers will all go back to the authoritative server. That is unless they go back to Cloudflare for "security". As I got through using both Verizon DNS and Opendns, Cloudflare is possibly breaking things again. Possibly they are defending some something. I avoid Cloudflare whenever possible.