How to save power (money and the planet) by offloading recordings to 'wake on demand' storage?

[CoolDreamZ]

My goal is to save power by moving the mythtv backend/tuners (along with other some other services) to a smaller more power efficient machine which will then be used for new recordings and will run 24/7 (initially). To achieve this I plan to serve the old 'archived' recordings from the original backend machine 'on-demand' whenever they need to be played/deleted. That machine then shuts down when not in use.

This is what I have done so far.... (server = old backend machine, client = new backend machine)

I have set up an NFS server and using systemd.automount on the client machine the filesystem is mounted 'on demand' and unmounted when 'idle' (timeout set to 15 seconds for testing). I plan to have the server poll periodically and shut down when no clients are connected. I also plan to hook a wakeonlan script into the automount service on the client to wake up the server when required.

This generally works as the NFS filesystem is mounted on-demand at the client and the mountpoint is unmounted when the filesystem is 'idle'. I can also see when there are no connected clients on the server (/proc/fs/nfsd/clients is empty). I have not been able to determine exactly what 'idle' means.

However, when I use subdirectories under the mountpoint in mythtv storage groups the fielsystem on the client is never 'idle' and so the server would never shut down. I have attempted to determine the cause of this and note the following:

1. lsof /mountpoint on the client shows no open files
2. I can manually unmount the NFS filesystem on the client while mythtv is running and therefore conclude that no files/directories are being held open by mythtv
3. The next time mythtv runs 'autoexpire' the NFS filesystem is remounted but subsequently does not become 'idle' (and no files/directories appear to be open)

Q1: Is there some way to either disable 'autoexpire' (ideally except for livetv) or decrease the autoexpire frequency (currently runs every 15 minutes) to continue testing?

Q2: Is there a bug in autoexpire which means the filesystem does not become 'idle' after it has run?

Q3: Is it possible to prevent autoexpire from running on a particular storage group?

[bill6502]

Obviously you're free to explore other options (above), but the designed method is here:
https://www.mythtv.org/wiki/ACPI_Wakeup . I use that. The Wiki is pretty good. Also
old. You can use mythshutdown --lock (and --unlock) to keep the backend up if you're
working on it between recordings and/or if no client is connected to it etc.

I use that and also, https://www.mythtv.org/wiki/Power_savin ... _Spin_Down to
save power when drives aren't doing anything. But, I'll note that my drives are on my backend,
which doesn't match your NFS solution.

I did spend 15 minutes looking for AutoExpire options and didn't find anything that would do
what you want.

[paulh]

One thought I had was using the low power machine as a master backend and the other one as a slave backend that could be woken as needed. I know we have support for waking slave backends but I've never used them that way so not sure how good a fit for your use case it would be though.

[CoolDreamZ]

@bill6502 @paulh thanks for your quick responses and advice.

I will definitely be using either acpi and/or wake-on-lan for my new smaller backend. For the 'archive' backend I need a solution which allows it to be powered off most of the time, possibly for days or even weeks at a time, and then started 'on demand'. I can't find any way to set things up which would allow a master backend to wake a slave 'on demand' solely to play a recording.

When I have time I will try and dig into the code for autoexpire to see if I can patch it to disable autoexpire for testing purposes. I will also explore migrating the 'archive' to a different media manager (e.g. Jellyfin) if I can either get it to work with systemd.automount or wake-on-lan from a client (I use Kodi as a frontend for mythtv).

[CoolDreamZ]

I have examined the source code for autoexpire and, as expected, the calculations for disk space trigger the automounting of the nfs share. I am not 100% sure why the filesystem then never unmounts however I have discovered the following:

• disk space checking code https://code.mythtv.org/doxygen/mainser ... tml#l05169
• statfs causes problems with automounted filesystems and a new automount option strictexpire has been implemented to work around this: https://gist.github.com/Robertof/abfc79 ... abd445e397
• systemd v250 or newer is needed (e.g Ubuntu 22.10)
• mythtv does not calculate free space for directories in the Videos storage group

I have upgraded my backend system to Ubuntu server 22.10, added the strictexpire option to the nfs automount and moved the shared directories to the Videos storage group. Results so far are good:

• The automount is not triggered by autoexpire and the nfs share remains unmounted
• The automount is triggered when playing a recording (via the kodi PVR plugin) and unmounts (after the expiry timeout) when no longer playing

I need to do more testing and it is unclear whether or not recordings should be placed in the Videos storage group. The find_orphans python script reports them as missing (it specifically ignores the Videos storage group among others) and so I have some residual concerns.