Recordings not occurring - event download failed in logs

[wtg]

On May 31st I started having problems with my recordings not occurring. Tuning and watching real-time is fine. Looking at the logs I see "event download failed" errors but I'm not sure why this has started happening. DVR service runs on a Linux Mint-based home server and it's been working fine here for a couple years. It's possible it's related to a system update but what's strange is it seems to resolve for a little while when I reboot the server but then it starts again and the problems are related to the discovery process.

What I've noticed is when things are working, I see this in the logs:

Code: Select all

20260531-06:12:27 Recording: sending discover using local ip 192.168.1.4 (ifindex 2)
20260531-06:12:27 Recording: sending discover using local ip 192.168.1.4 (ifindex 2)
20260531-06:12:27 Recording: discover response from 530785FB-18EB-4821-9F39-8D9E063641D8 http://[::1]:65001
20260531-06:12:27 Recording: discover response from 530785FB-18EB-4821-9F39-8D9E063641D8 http://127.0.0.1:65001
20260531-06:12:27 Recording: discover response from 530785FB-18EB-4821-9F39-8D9E063641D8 http://192.168.1.4:65001
20260531-06:12:27 Recording: discover response from 10A1B12F http://192.168.1.11:80
20260531-06:12:27 Recorded: recorded sync to record-api.hdhomerun.com
20260531-06:12:27 Recording: event download from record-api.hdhomerun.com
20260531-06:12:27 Recording: 10A1B12F lineup request success (found 130 channels)
20260531-06:12:27 System: server time = Sun May 31 06:12:27 2026 (correction of 0s)
20260531-06:12:27 Recorded: recorded sync success
20260531-06:12:27 System: server time = Sun May 31 06:12:27 2026 (correction of 0s)
20260531-06:12:27 Recording: record WAVE News at 11PM Saturday 20210828 [20260531-0730] on 3.1 (13 15)
20260531-06:12:27 Recording: event download success
20260531-06:12:27 Recording: disk space available = 84GB
20260531-06:12:27 Recording: current time = Sun May 31 06:12:27 2026 (correction of 0s)
20260531-06:12:27 Recording: event WAVE News at 11PM Saturday 20210828 [20260531-0730] in future
20260531-06:12:27 Recording: next timer event in 1h17m03s

When things fail, I see the discovery process doesn't find the tuner:

Code: Select all

20260531-08:13:38 Recording: sending discover using local ip 192.168.1.4 (ifindex 2)
20260531-08:13:38 Recording: sending discover using local ip 192.168.1.4 (ifindex 2)
20260531-08:13:38 Recording: discover response from 530785FB-18EB-4821-9F39-8D9E063641D8 http://[::1]:65001
20260531-08:13:38 Recording: discover response from 530785FB-18EB-4821-9F39-8D9E063641D8 http://127.0.0.1:65001
20260531-08:13:38 Recording: event download failed
20260531-08:13:38 Recording: disk space available = 82GB
20260531-08:13:38 Recording: current time = Sun May 31 08:13:38 2026 (correction of -1s)
20260531-08:13:38 Recording: no timer events planned

I restarted the tuner also but that doesn't seem to have any effect. Any ideas?

[wtg]

I discovered the cause of the issue but not sure why it's a problem.

I added a script to my startup that disables wifi on the box when the ethernet connection is active. I'm running pihole on the box too and assign a static ip. I want the IP to be the same whether it's connected via ethernet or wifi so use this script to disable one or the other. For some reason the discovery isn't working when the wifi is disabled but I don't understand why. Any ideas? The script I'm using is below, executed by systemd from a .service file.

Code: Select all

#!/bin/bash 

# Configure the variables
ETHIF="enp1s0"
WLANIF="wlp2s0"
# check ETHIF link every 5 seconds
NEXTCHECK=5

while : 
do
   ETHIP=$(ip -f inet -4 a show dev $ETHIF|grep inet|awk -F ' ' '{print $2}'|awk -F '/' '{print $1}')
   ETHISUP=$(ip -f link a show $ETHIF | grep -o "state UP")
   ETHHAVEROUTE=$(ip r show dev $ETHIF)

   WLANIP=$(ip -f inet -4 a show dev $WLANIF|grep inet|awk -F ' ' '{print $2}'|awk -F '/' '{print $1}')
   WLANISUP=$(ip -f link a show $WLANIF | grep -o "state UP")
   WLANHAVEROUTE=$(ip r show dev $WLANIF)

   # 1 If Ethernet has (or obtains) link
   if [ ! -z "${ETHIP}" ]&&[ ! -z "${ETHHAVEROUTE}" ];then

      # 1-a Bring wlan down, and disable it.
      if [ ! -z "$WLANISUP" ];then
         ip link set $WLANIF down
      fi;

      # 1-c Bring eth up.
      # If you have a route and an IP address on the interface ,the ETHIF is already UP          
      if [ -z "$ETHISUP" ];then
         ip link set $ETHIF up
      fi;
   # 2 If Ethernet does not have (or loses) link
   else
      # 2-a Enable wlan and bring it up.
      if [ -z "$WLANISUP" ];then
         ip link set $WLANIF up
      fi;
   fi;

   sleep $NEXTCHECK
done

[jasonl]

I don't have any way to test this since I don't have any Linux devices on wifi, but my guess is that IP is still bound to the wifi interface even though it's in the down state and that is confusing things when it tries to send the broadcast. Some Linux-based NASes have a similar problem if you assign a static IP on the same subnet to an interface that isn't physically connected to anything, and you have to go in and switch those unused interfaces back to DHCP to make things work correctly.

[wtg]

Thank you for the reply. Strangely I've discovered a simple solution to having a backup network connection with the same IP and the dvr service doesn't mind: both the eth and wifi have the same static IP with both active. I thought it was impossible but would probably produce all kinds of errors but instead it just works. I didn't know Linux would let you do that, and I didn't know the network wouldn't care either. Everything just works