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?
How to save power (money and the planet) by offloading recordings to 'wake on demand' storage?
Moderator: Forum Moderators
-
- Newcomer
- Posts: 4
- Joined: Sat Mar 04, 2023 11:15 am
Re: How to save power (money and the planet) by offloading recordings to 'wake on demand' storage?
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.
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.
Re: How to save power (money and the planet) by offloading recordings to 'wake on demand' storage?
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.
-
- Newcomer
- Posts: 4
- Joined: Sat Mar 04, 2023 11:15 am
Re: How to save power (money and the planet) by offloading recordings to 'wake on demand' storage?
@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).
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).
-
- Newcomer
- Posts: 4
- Joined: Sat Mar 04, 2023 11:15 am
Re: How to save power (money and the planet) by offloading recordings to 'wake on demand' storage?
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
- 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