I don’t use Plex, but I get this error a lot when my NAS has spun down (gone idle) because I was spending too long in the interface looking for something to watch (or verifying the scraped metadata) or left a playing title on pause while I went away to cook dinner or whatever …
Force-killing and restarting the app is the only thing that works to get Infuse to wake up the NAS again.
I don’t know if this is primarily a Firecore issue or a Synology one (or an AppleTV one) …
but wonder if it isn’t possible for Infuse to try to send a ‘wake up!’ command (whatever that might be) when it encounters whatever condition triggers it to spit out that error message?
Just a suggestion, I’ve found that when my Synology gets bored with my actions and goes to sleep, I can navigate to one of the favorites that are located on in and just open it and do a quick browse in that to the file level. That wakes mine back up and I can continue.
Yup, I can confirm that has sometimes also worked. Force killing is generally quicker and more reliable for me, though — I’ve even got a physical button my Harmony dedicated to the task.
Still, it would be nice that if instead of just giving up and sending the error message, Infuse would try doing whatever it successfully does when it’s restarted — so that we don’t need to navigate away from what we were doing, or start from scratch.
… Assuming, of course, this is code Firecore can send or compel my AppleTV to send on its behalf, like it does when the app is first opened.
What I DON’T want it to do is purposefully keep my drives spooled up by sending periodic access calls because I’ve got a real short attention span and its quite possible in that case my drives would never spin down because I’d forget to close the app for days on end.
I’ve just happened to be in the right place a few times where I could see the NAS when I was doing something in Infuse and it actually does start waking on the action but sometimes the time it takes the NAS to spin up is just a bit longer than the error out time in Infuse so you get the error. I’ve been able to also just send scan for changes and by then the Synology is ready to go.
Do you have the actual IP address in the NAS share info with the NAS set to a static IP with your router? That helped my set up.
EDIT TO CORRECT: I meant to say enter the MAC address for the NAS in the share info. Setting the IP also helps too.
^ When Infuse spits this error, it seems as if it doesn’t understand why it can no longer play the title; as if it doesn’t realize the drive has spun down. Might the logic be altered to assume this might have happened, and then check that assumption by sending a fresh access command to wake the (potentially sleeping) server, and attempt to reestablish a (new, if necessary) stream from that specific selected file?
Ah, yes; I suspected this also could be part of the problem. Except that file remains inaccessible once the error is spitted out, even if the NAS is accessible moments later. You still have to either force kill, or navigate somewhere else. There’s no “try again” option once the time-out limit is reached.
Maybe it just needs a better error message — something like “hold on a sec, still waiting for that file …”
(I gather they don’t want to extend the time out before sending the error because users might think the App itself froze.)
I’d recommend that you include the MAC address since Apple played with the allowable wake calls. The MAC address info was added to help with the wake commands. I’m digging through my stack of notes trying to find the reference so give me a bit.
From what I gather and my own experience, WOL only will wake a device if it has been shut down with network access. It will not speed up wake from sleep or hibernation which can take 1-2 min to be fully ready for infuse to start reading. I personally have a special wake command set during my peak usage hours to get around this. Otherwise my device is hibernating. But yes infuse could have a better message and maybe even wait longer.
I’ll try adding the MAC, but the 1-2 minute wake regardless sounds reasonable.
I understand the delay to wake my NAS is not at all Firecore’s fault, but even so, if coding a better error message (that doesn’t simply dead-end when my share is asleep when you try to access it) could be done, that would be awesome.