After upgrading to pre-release v2022.08.26.2245
, something I've never experienced before is happening: recording is failing silently, recordings shown in the Schedule are not starting, and nothing I'm seeing in the DVR Server logs directly indicates why.
I also checked against the guide data on zap2it, and these airings are all still as originally scheduled, yet somehow the recordings never started. No errors, just a gap. Namely, "How Do They Do It?," which is using a pass that has been working fine until today displays as "Queued", yet nothing was recorded. The pass' only condition is SeriesID == 404110
.
Screenshot taken at 10:45 PM EST:
Log snippet:
2022/08/26 19:25:20.135150 [SYS] Starting Channels DVR v2022.08.26.2245 (linux-x86_64 pid:12453) in /var/packages/ChannelsDVR/target/channels-dvr/data
2022/08/26 19:25:20.297400 [SYS] Started HTTP Server
2022/08/26 19:25:20.752507 [HDR] Found 1 devices
2022/08/26 19:25:21.134026 [TVE] action=cbs_station err=unavailable in location
2022/08/26 19:25:21.450761 [M3U] Refreshed lineup for Stirr with 107 channels
2022/08/26 19:25:21.509575 [M3U] Refreshed lineup for Pluto with 338 channels
2022/08/26 19:25:22.525493 [DVR] Recording engine started in /volume1/DVR
2022/08/26 19:25:22.526837 [DVR] Waiting 1h34m27.473168475s until next job 1661561990-159 How Do They Do It?
2022/08/26 19:25:22.528124 [SYS] Removing old update 2022.08.19.0326
2022/08/26 19:25:26.960225 [SYS] Created database snapshot: backup-20220826.192526
2022/08/26 19:25:26.960472 [SYS] Removing old backup backup-20220809.182328
2022/08/26 19:25:32.748521 [IDX] Pruned 44 expired airings from XMLTV-Pluto in 213.463462ms.
2022/08/26 19:25:32.803555 [IDX] Pruned 20 expired airings from XMLTV-Stirr in 54.977869ms.
2022/08/26 19:25:32.803688 [IDX] Pruned 0 expired airings from X-M3U in 100.703µs.
2022/08/26 19:25:32.803925 [IDX] Pruned 0 expired airings from X-VIRTUAL in 219.79µs.
2022/08/26 19:25:33.063773 [IDX] Pruned 78 expired airings from X-TVE in 259.82131ms.
2022/08/26 19:25:33.193153 [IDX] Pruned 4 expired airings from USA-OTA***** in 129.335919ms.
2022/08/26 19:36:51.252734 [M3U] Refreshed lineup for Pluto with 338 channels
2022/08/26 19:36:52.807924 [M3U] Refreshed lineup for Stirr with 107 channels
2022/08/26 20:59:50.005630 [DVR] Starting job 1661561990-159 How Do They Do It? on ch=[6110]
2022/08/26 20:59:50.005734 [DVR] Waiting 29m59.994270119s until next job 1661563790-159 How Do They Do It?
2022/08/26 22:25:33.201900 [DVR] Fetched guide data for XMLTV-Pluto in 0s
2022/08/26 22:25:36.172534 [DVR] Indexed 1129 airings into XMLTV-Pluto (72 channels over 28h15m0s) + 74 skipped [2s index]
2022/08/26 22:25:36.476133 [DVR] pruned 238 replaced airings in 0s.
2022/08/26 22:25:36.708900 [DVR] Fetched guide data for XMLTV-Stirr in 0s
2022/08/26 22:25:37.996841 [DVR] Indexed 606 airings into XMLTV-Stirr (22 channels over 26h36m0s) + 17 skipped [1s index]
2022/08/26 22:25:38.229503 [DVR] pruned 41 replaced airings in 0s.
Note the lack of the expected [DVR] Recording for job xxx [...]
line at 20:59:50 (the pass was padded by 10 seconds).
Next, I tried to manually record something from the Web UI, but it just showed as "Scheduled" (not "Recording" like it should), nothing was added to the log at all, and the recording did not start. Finally, I stopped and started the Channels DVR Synology package and recording started working again... something is rather amiss here!
This screenshot was taken after restarting the Channels DVR Synology package:
I would very much like to help get to the bottom of this! I submitted diagnostics:
- Sent when I first noticed the issue:
2107d267-ede1-4868-bc03-9d8d32ff5d47 - Sent after delete & recreate guide database (issue persisted):
d9043aaf-b995-4919-95ca-b0be306932c1 - Sent after restarting the Channels DVR Synology package:
5fbead7f-a272-4d42-a1ee-d9371741211f