Well, then I'm out of ideas. You're only providing partial logs and minimal details, so I'm out of relevant WAGs.
@racameron, thanks. I don't want to share what my family watches, so not sure all that verbose details on that is relevant. As for Minimal details, open to ideas. Don't feel I've been limited there.
I've seen where a TVE Recording started a few seconds late; but the DVR Log showed authentication issues and retried. The log here just shows it started late with no errors. These were OTA recordings too. I could see that the HDHR Tuner could take a few seconds to start, but the log I shared showed the DVR not trying to start until 41seconds after it should have. So the log should show it started recording, then requesting tuner access.
So the log below shows the DVR Job started late and .4 seconds later requesting connection to HDHR:
2021/09/27 19:00:41.533974 [DVR] Starting job 1632787200-46
2021/09/27 19:00:41.934595 [TNR] Opened connection to 1xxxx
So regardless if my HDHR was available or not, the DVR Job started late. If my time was off, the job would have logged it started on time?
I checked the forum and only found a post about this a while ago affecting Apple; so did not respond to that thread since I was on a Pi.
Thanks
Late wake up is indeed unexpected and generally means the OS/kernel did not wake the process in time. I've seen it happen on Windows but even there 41s is quite extreme.
I know the Pi does not have an RTC so perhaps that is related?
I have not heard of this with our official Pi image which uses a 64bit kernel.
Thanks @tmm1. The Raspbian OS Lite is 32bit. Their 64bit is still in beta. I went from the Official DVR Pi Image to Raspbian so I could load Fan scripts and enable SSD Trim to maximize the flash cell life of the SSD. If this continues to be an issue, I'll just pad extra time in the beginning of recordings and wait until the 64bit Raspbian OS is released(unless you guys are planning to update the DVR Image with Trim and fan scripts) 
Other reason I moved is the HDD was spinning 24/7, so I assume spindown/sleeping of HDD was not available with the official image.
MakerFire does make a RTC GPIO Module using a CR1220 battery. If this is a bigger issue, I'll see about testing one of those with the 32bit OS. Thanks.
While not supported, it is possible to run additional scripts/applications on the RPi image. Just beware that applications will probably need to be statically linked as library versions may differ or not be present; also, you'll probably have to re-install them when the OS image is updated.
@racameron, I thought about doing that, but since I was replacing the HDD drive with a M.2, I was going to do a full rebuild anyway and it would be easier for me to use 'apt' to load the extras I wanted. Either way, I would be forking from the Official Image. I'm pretty sure this is not the last time I'll be reloading the Pi.
I always pad my recordings so this never happens. Sometimes the tuners are not available immediately or there's a network connection issue. The broadcast signal from the station could be delayed for some reason and not start exactly on time. Padding your recordings is always a good idea because there are too many variables involved that could cause problems like this. Expecting a recording to start or end exactly on time is more wishful thinking than a reality.
Can you share what you're doing for TRIM and HDD sleep? And which fan scripts are you using specifically?
Our RPI image does have a periodic fstrim already built-in. You can verify with systemctl list-timers.
1 Like
@tmm1, took a break from the Internet and come back and see all this activity! 
Sorry for the late reply, looks like you added TRIM to the Official RPi Image already. I was just following this guide Enabling TRIM on an external SSD on a Raspberry Pi | Jeff Geerling
The main point from that blog is making sure the SDD and the SATA controller both support TRIM. There were different cases I would have wanted to purchase(aka cheaper) but unknown if the SATA controller supported TRIM. I saw a post that the Argon M.2 case now come factory with firmware supporting TRIM. I bought my case last month on Amazon and it did have firmware supporting TRIM. If not, there is a hack to load TRIM enabled firmware for older cases.
As for fan script, I'm using Agron's script: curl https://download.argon40.com/argon1.sh | bash
With the Argon M.2 case, I'm trying their default fan settings. The fan stays off most of the time as the CPU temps seems to stay below 55c for me. Checking with: vcgencmd measure_temp I'm right now hovering 44c with just one recording playing. Ambient temp where the Pi is located is now 78f(~25.5c). Without the fan script, the fan will stay at 30% speed. It's quiet, but a tad too noticeable when the room is quiet. With the fan script the default is to turn on at 55c at 10% speeds.
For HDD Sleep, I've moved to a M.2 SATA so did not look into that further. I do use HDDs with Open Media Vault. OMV already has SMART support enabled and the HDDs do spin down. Just a note, I was testing with some older USB HDDs that were USB2 and those did not spin down or were passing SMART metrics. All the USB3 HDDs I had did work with OMV for SMART and HDD Spindown.
I have not had anymore late recording starts; but plan to flip back to the Official RPi image. Thanks.
Thanks. I will be working on support for the various Argon40 fans/cases.
2 Likes
Our latest image will detect if the device supports TRIM and enable it automatically.
1 Like
Thanks @tmm1 for the update. I'm going to swap some Pi's around so I can use my newest Pi(C0 stepping) and reload with the Official Image. Thanks.
Was there any progress made for adding support for the Argon M.2 case fans? Just recently switched over to one and unable to install their script. Thanks!
1 Like
@Craig_V , I'm still running Raspbian OS Lite and used the Linux Channels DVR Linux install guide. The Argon40 case has been great. Fan rarely turns on compared to my other Pi's in normal plastic cases. Would like to get back on the Official image as I like the reboot button in the UI.
As I sit here listening to the fan going full blast, I'll probably switch over to to that method of installing things. Was hoping there was an update, or word if the fan scripts would be added anytime soon.
No update yet. It's on my todo list.
1 Like
Regarding SSD trim support on the Channels Raspberry Pi image. I can see that it's running, but is it working?
systemctl status fstrim.timer
● fstrim.timer - Discard unused blocks
Loaded: loaded (/usr/lib/systemd/system/fstrim.timer; enabled; preset: enabled)
Active: active (waiting) since Thu 2023-05-11 06:13:35 PDT; 3 days ago
Until: Thu 2023-05-11 06:13:35 PDT; 3 days ago
Trigger: Mon 2023-05-15 02:00:00 PDT; 12h left
Triggers: ● fstrim.service
Docs: man:fstrim
fstrim -v /
fstrim: /: the discard operation is not supported
fstrim -v /media/DVR
Thanks for the reply. I see that it's working when using the correct parameters to point to the correct mountpoint! The output I get from that command is:
/media/DVR: 794.7 GiB (853327740928 bytes) trimmed