Project

General

Profile

TVH @ RPi to send WOL to NAS

Added by Pila RPi about 8 years ago

Searching how to send WOL to my NAS when TVH wants to record, so my NAS does not need to be always on. Found several scripts but they all seem too complicated and doing more than I need and for other devices.

Is there a simple way to to something on my RPi (LibreElec) to just send WOL to the NAS if it is not available. Or, some "PreCommand" that would send WOL to my NAS before any TVH recording starts?

TVH and Kodi are LibreElec at an RPi and it never gets turned off. NAS I would like to turn off and TVH records to the NAS.


Replies (13)

RE: TVH @ RPi to send WOL to NAS - Added by Robert Cameron about 8 years ago

If your NAS has WakeOnLan enabled, there is a program called wol that will send the magic packet to it. You can use:

$ wol [target_MAC_address]
where [target_MAC_address] is the MAC of your NAS. I am not sure if wol is available on LE, though.

Another tool that does this is ether-wake, and it works the same way: just pass the MAC address of the machine you want to wake.

However, since LE isn't a full Linux distro, your choices are going to be limited. If you do find a tool to run on LE that will send magic packets, then just use that was the PreCommand in your recording profile.

(Of course, if your recording directory is network-mounted, depending upon the protocol it may let the connection sleep when not in use, and re-establish one when necessary, allowing the NAS to sleep on its own—this is what mine does.)

RE: TVH @ RPi to send WOL to NAS - Added by Pila RPi about 8 years ago

(Of course, if your recording directory is network-mounted, depending upon the protocol it may let the connection sleep when not in use, and re-establish one when necessary, allowing the NAS to sleep on its own—this is what mine does.)

Well, that is what I would want ideally.

RPi mounting of the NAS for the TVH is done via autostart.sh (Simplified)

mount -t nfs 192.168.2.5:/volume1/Public/Video/TV /storage/nas -o nolock;

I do not have a problem with regular WOL, all is perfect. Kodi WOL is OK. I just need to make TVH wake my NAS before recording.

RE: TVH @ RPi to send WOL to NAS - Added by Robert Cameron about 8 years ago

Why not use _netdev in /etc/fstab?

192.168.2.5:/volume1/Public/Video/TV /storage/nas nfs nolock,_netdev 0 0

RE: TVH @ RPi to send WOL to NAS - Added by Pila RPi about 8 years ago

Because Raspberry OpenElec documentation said I need what I wrote previously. I tried fstab but it did not work. This worked.

I actually have a bit more complex line as I am waiting for a server to boot up (3 minutes) or RPi (30 sec boot) will not do it right.

RE: TVH @ RPi to send WOL to NAS - Added by Robert Cameron about 8 years ago

You may want to try LibreELEC, as OpenELEC has essentially been left behind. (All of the main developers of OE left to create the fork LE, mostly because OE was developing so slowly and was always out-of-date.)

The problem with OE/LE is that it is not a proper OS. It is essentially a media appliance OS that only does what it was shipped as. Any additional functionality is a pain to tack on after-the-fact. If your goal is to do more than OE/LE does out of the box, you are best using a different OS, such as a proper Linux distro.

RE: TVH @ RPi to send WOL to NAS - Added by Pila RPi about 8 years ago

I am using LE now, just sarted with OE and therefore mentioned OE documentation.

I am quite often aware it is not a proper OS, whenever I want to do someting more complex. But, since I am on RPis, I expect LE to be more efficient. I will have to check other options if unable to wake NAS for TVH recording. But, on RPi, they will likely be limited.

RE: TVH @ RPi to send WOL to NAS - Added by Gert Jansen about 8 years ago

Robert Cameron wrote:

Why not use _netdev in /etc/fstab?

192.168.2.5:/volume1/Public/Video/TV /storage/nas nfs nolock,_netdev 0 0

Out of interest, is the netdev option only interesting when used with WOL?

I use this for my rpi (raspbian, not OE or LE) to make a connection to my NAS

172.17.44.213:/data04/video/TVHeadend /mnt/tvheadend nfs rw,sync,bg,auto,intr,soft,retry=10
172.17.44.253:/data01/raspi /mnt/raspibackup nfs rw,sync,bg,auto,intr,soft,retry=10

My NAS is a VM on my ESXi-server where I also have a few VMs running TVHeadend, so it needs to be up all the time.

--

A friend of mine tried to get LE to wake up his NAS as well, but he couldn't find a way to do it and gave up.
I believe he switched to OSMC and got it working there.

Can ask him if anyone's interested.

RE: TVH @ RPi to send WOL to NAS - Added by Robert Cameron about 8 years ago

The _netdev option is used when mounting devices at boot. It informs the system that it is a network device, and therefore the network interfaces ought to be brought online first before attempting to mount them. (This is also help speed up booting, since the boot process is not hung waiting for a mount that may not happen because of network situations.) It is a general option for all network filesystems, and really has nothing to do with WOL. With some init systems/supervisors (such as systemd), _netdev filesystems are also allowed to be accessed/written to while bringing up the network interfaces (such as when waking from sleep) and the write operations are buffered, only written to the FS once the connection has been re-established.

If LE has perl, you can use wakeonlan [[https://github.com/jpoliv/wakeonlan]]; just make sure to set it executable.

RE: TVH @ RPi to send WOL to NAS - Added by Pila RPi about 8 years ago

Kodi has no problem waking up NAS. Any other PC has no problem waking up NAS. I need a way to tie TVheadend recording with sending WOL prior to recording. Or OS to do it for me, as would be logically for me.

I need a command to use with mount to say: if disk / computer is not available, first try sendng WOL.

_netdev does not seem to fit a bill. I have RPi waiting for a server before it can be mounted a I do not want it to start recording if there is no proper mount. This solved a problem with mounting from a cold start as Rpi boots in 30 seconds and NAS takes 3 minutes.

I can not locate any pre-recording field in the TvHeadend as I would gladly put wol command there.

RE: TVH @ RPi to send WOL to NAS - Added by Pila RPi about 8 years ago

Robert Cameron wrote:

(Of course, if your recording directory is network-mounted, depending upon the protocol it may let the connection sleep when not in use, and re-establish one when necessary, allowing the NAS to sleep on its own—this is what mine does.)

OK, that I want. The command to do so goes....

RE: TVH @ RPi to send WOL to NAS - Added by Pila RPi about 8 years ago

Unless something pops out, seems I will have to make a script to check scheduled recordings on a regular basis and send WOL to the NAS

RE: TVH @ RPi to send WOL to NAS - Added by Pila RPi about 8 years ago

OK, recordings finaally stopped, server went to sleep after 30 minutes, can test the script.

Works, 2 lines of code. Script says: if recording is pending in the next 20 minutes, WOL the server. Plus one cron entry.

Hope I did not miss some side problem or dependancy of the TVheadend on the server :) Hmmm, TV channel icons are likely going to ask for relocation from the server.

RE: TVH @ RPi to send WOL to NAS - Added by Pila RPi about 8 years ago

This is unfortunatelly OS related problem. I can not mount using fstab as it is not being used in RPi LE. I must mount using mount command.

If I try mounting, using e.g.

mount -t nfs 192.168.2.5:/volume1/Public/Video/TV /storage/recordings -o nolock,_netdev

mounting failes. Problem occurs when my mount becomes unavailable due to my server sleeping. RPi and TVH become unresponsive until server is back from sleep.

RPi wakes server well for recording, TVH records everthing.

If I umount this share prior to server going to sleep, all is perfect. AFter I wake my server, I mount it back with usual command, all is perfect.

But, how to make umounts and mounts after wakeup automatic?

edit... Solved everthing, server sleeps, both RPis are happy, RPi wakes it up when needed, mounts solved, recording works in all situation transparently for the user, seems for the last 4 days it works perfectly well.

    (1-13/13)