Yea try this:
echo -e "\n#includedir /private/etc/sudoers.d" | sudo tee -a /etc/sudoers
Yea try this:
echo -e "\n#includedir /private/etc/sudoers.d" | sudo tee -a /etc/sudoers
ok - i edited it with visudo because i am a chickenā¦ then just for fun i rebooted and the server started up on autologin (i need to try your system service version at some point)ā¦ and now i see 2 wakeorpoweron entries owned by com.getchannels.dvr for tomorrow morning and tomorrow afternoon. iāll set the machine to sleep while idle and see what happens. it happens to be recording right now and i see the assertion:
pid 302(channels-dvr): [0x000000010000015a] 00:21:53 NoIdleSleepAssertion named: āThe recording engine is busy.ā
so it looks like everything is in order. this is awesome.
Excellent. Let me know.
i just logged into the machine to see if had fallen asleepā¦ it had. dunno if it was the sleep/wake cycle, but now the 2nd wakeorpoweron has been duplicated:
[0] wakeorpoweron at 04/24/17 23:27:00 by com.elgato.eyetv
[1] wakeorpoweron at 04/25/17 09:18:00 by com.getchannels.dvr
[2] wakeorpoweron at 04/25/17 13:24:00 by com.getchannels.dvr
[3] wakeorpoweron at 04/25/17 13:24:00 by com.getchannels.dvr
however, a subsquent forced sleep followed by a wake did not result in another wakeorpoweron. i suppose this is harmless but i thought iād report it.
rob
The DVR is not very smart about setting the wakeup events, and will err on the side of making too many. The extra events should be harmlessā¦
Once we confirm this approach works, I can optimize the generated events to minimize wakeups.
ok - (duh - times above) weāll see what happens. i may not be home until after both events are fired, so iāll have to check in the afternoon to see what happened.
rob
BTW, does the DVR machine wake up automatically when you try to use the ATV app? Howās the lag?
i should have tried that last nightā¦ i got preoccupied with trying to understand why when i airplay the DTV now app from my ipad to the appletv that the data is being pulled straight from the internet by the appletv itself.
iāll see what the lag is like later today.
This is part of the AirPlay protocolā¦ it does a hand-off of the video URL and lets the ATV pull it directly from the internet.
i was afraid of that. the issue is that ATT zero rates the cellular data for DTV Now, while iām under a data cap here on comcast. ergo iāve been forcing DTV Now on the ipad to pull data from the cellular network but then airplay to the appleTV (by statically assigning an IP to the wifi interface but omitting the gateway). i guess they got wise because i think this just started happening with the last update to the ios app, and of course they didnāt say anything about it in the release notes. given how the app store works, iām toast; canāt roll back.
initially i had tethered the ipad to my router and forced the traffic out the cellular link, but they seemed to be able to tell that the data was not terminating in an ipad and so the data was not zero rated. i think āhotspotā data looks different to the cellular network, so they can discriminate. oh well. this is only going to get worse with current the situation at the FCC.
rob
anyway, back on the subject at hand, the server machine is currently asleep, so i started the channels app on the ATV andā¦ the server did not wake. i feel like maybe the sleep proxy stuff is not working right; earlier when the server was sleeping, arp -a (on my desktop machine) still showed the server machineās mac address and just now it says āincompleteāā¦ i thought the sleep proxy machine was supposed to do a proxy arp. in this case i have at least 2 sleep proxies - the appleTV and an airport extreme base station.
the ATV channels app came up in a ānon-DVRā state, so at least thereās that - i could still watch live tv. but i guess youād expect it to behave that way if it does not see a backend server.
rob
so there was a wakeup set for 23:27:00 last night; not sure if that was for a recording or maintenance, but no recording took place at that time. the log shows at 23:27:11 the backend tried to check for an update and failed. the machine must have woken up a few more times since there are log entries at 01:01:11, 04:03:26, etcā¦
i donāt know how long it takes for en0 to come up but itās possible that 11 seconds between the wake and the check was not enough time. indeed according to system.log, en0 did not come up until 23:27:22 and there were still kernel AFP remount messages until 23:27:29.
i will put the machine back to sleep and see if it can do the recording thatās scheduled for 13:24
Bummer. Did you double check if āwake for network accessā is enabled in Energy Saver?
it should be - if i connect to it using VNC the machine wakes upā¦ but i will double check. yeah, wake for network access is checked. do you want to see any tcpdump logs or anything?
the good news is that the machine woke up and started recording; i donāt want to mess with it until itās done. a related question: are you preventing sleep until comskip is finished?
question - do you find the server from bonjour announcements? do those get proxied as well? just wondering if the frontend simply never tries to talk to the backend due to a lack of service announcements. or are those proxied too?
Yes.
Hmm ok. Does it also work if you connect using VNC but using the IP address and not the hostname?
According to http://stuartcheshire.org/SleepProxy/index.html:
The Client
Anything. Tiger, Leopard, SnowLeopard, Lion, Windows, Linux, iPhone, iPad, Android, or anything else that has TCP/IP, it doesnāt matter. Connect to your sleeping server from any client device and the server will magically wake to serve you, regardless of whether you connect by IP address, by hostname, or via Bonjour browsing. The server will wake regardless of whether the client is right next to it on the same link, or 30 Internet hops away on the other side of the planet.
Yes, but the app also remembers the last IP address found and tries to connect to it directly.
i will try - the machine is still recording right now, but when itās done iāll put it to sleep.
i usually refer to it by its name, so iāll try the IP address in the VNC client.
referring to the machine by itās IP address seems to work OK for vnc or ssh. it does take so long to wake up that ssh or VNC times out the first time.
iām reading that page you referenced and looking at the mdns traffic from my two airport express boxes using tcpdump (the Apple TV does not seem to be advertising as a sleep proxy), and i see a lot of PTR and SVC related to sshd and eyeTV but i donāt see anything from the channels server. i guess i thought it was supposed to be enough for you to advertise the server as a bonjour service to get sleep proxy action but maybe not??
17:16:25.715050 IP htpc2.mdns > 224.0.0.251.mdns: 0*- [0q] 26/0/9 (Cache flush) TXT "path=/eyetv/",
PTR _http._tcp.local., PTR EyeTV htpc2._http._tcp.local., TXT "----", (Cache flush) TXT "",
PTR _ssh._tcp.local., PTR htpc2._ssh._tcp.local., TXT "model=Macmini6,2" "osxvers=13",
(Cache flush) TXT "", PTR _sftp-ssh._tcp.local., PTR htpc2._sftp-ssh._tcp.local., (Cache flush) TXT "",
PTR _rfb._tcp.local., PTR htpc2._rfb._tcp.local., (Cache flush) SRV htpc2.local.:2170 0 0, (Cache flush)
SRV htpc2.local.:22 0 0, (Cache flush) SRV htpc2.local.:22 0 0, (Cache flush)
SRV htpc2.local.:5900 0 0, (Cache flush) TXT "keyHash=...." "txtvers=1", PTR _eyetvsn._tcp.local.,
PTR htpc2._eyetvsn._tcp.local., (Cache flush) SRV htpc2.local.:49298 0 0, (Cache flush)
PTR htpc2.local., (Cache flush) AAAA fe80::aa20:66ff:fe11:9e93, (Cache flush) PTR htpc2.local.,
(Cache flush) A 172.18.1.15 (941)
Strange, here dns-sd -B _sleep-proxy._udp local
shows my Extreme, Express and two ATV4s.
Weāre using a custom bonjour server implementation, so itās possible weāre not doing something thatās required for the sleep proxies to pick up on our service.