Re: [SlimDevices: Plugins] Announce: New versions of erlands plugins
I tried to streamline my LMS set up by disabling Custom Scan startup rescan refresh and the automatic rescan (one issue was that new data supposed to be scanned by Custom Scan such as album rating for newly added albums did not show up, maybe Custom Scan which is really slow never had a chance to finish between my nightly scans). But after a PC reboot LMS web UI (but not the Custom Scan settings page) still reports a Custom Scan running. Is that just some kind of display issue? I seem to remember installing a beta version of Custom Scan, I have v.3.0pre3832, that might be doing scans differently. How can I get the latest stable version back? I could not see any other version in the plugins page. I have also downgraded to 7.7.2 release LMS version. I still get long startup times although I have disabled TrackStat startup rescan refresh. The TrackStat version is 3.1.3829. vagskal's Profile: http://forums.slimdevices.com/member.php?userid=20778 View this thread: http://forums.slimdevices.com/showthread.php?t=49483 ___ plugins mailing list plugins@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/plugins
Re: [SlimDevices: Plugins] iPeng support thread
pippin wrote: Did you try the non-native menu? That should behave exactly the same as the controller. What does the Controller do, btw, when you do the ClearRescan? Does it back out to the main menu? I haven't had time to try non native. Also it's been a while since I used the Controller so I don't recall exactly what it does, but it was better than what iPeng is doing. Owen Smith's Profile: http://forums.slimdevices.com/member.php?userid=42371 View this thread: http://forums.slimdevices.com/showthread.php?t=51929 ___ plugins mailing list plugins@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/plugins
Re: [SlimDevices: Plugins] Announce: Beta version of SvrPowerControl
SrvrPowerCtrl - will my Netgear ReadyNas Duo support this plugin? Would love to be able to turn off Nas remotely. 05mattjax's Profile: http://forums.slimdevices.com/member.php?userid=39786 View this thread: http://forums.slimdevices.com/showthread.php?t=48521 ___ plugins mailing list plugins@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/plugins
Re: [SlimDevices: Plugins] OSX Mountain Lion sleep issues
gharris999 wrote: Truthfully, I never did take ReallyPreventStandby's code to a finished state. The toggle feature was supposed to be a execute:first == inhibit sleep, execute:again == uninhibit. But I don't recall if I really fleshed that feature out or not. I'd have to review the code and, frankly, I don't even have a copy of ReallyPreventStandby currently installed on any of my LMS boxes. I have now had time to look at your ReallyPreventStandby plugin again Gordon. I am running it with caffeinate -i as the prevent idle command and pkill caffeinate as the allow caffeinate command with these set as toggles. Contrary to what you remembered, the toggle setting means that the commands only need to be called once which is what we need in this case. It is when the toggle setting is not made that we end up with multiple invocations of caffeinate. I have only tested so far the case of preventing standby when any player is powered on - as set in the settings for the plugin. (As an aside, I am using caffeinate as the current official command, not because I think the problems we have had are due to your own sleep inhibit command which also uses power assertions. If I was to get to production use with this I would copy the binary and invoke it under a different name.) Debugging the plugin and analyzing the code convinced me that in this case at least, the call of _killInhibitCmd() in the plugin's _hasResumed() is inappropriate, at least with these settings. It was having the effect of killing the caffeinate that had been started on resume - by a Touch sending its WOL to the server. I have now deleted that call and have found the operation to be much improved. However, occasionally the Mac Mini still goes back to sleep before the plugin has had a chance to make that call of caffeinate. If a Mountain Lion system is woken by an interactive user, say at the keyboard, it will stay awake until the idle timer expires - in my case 10 minutes. If it is woken by WOL it ignores the idle timer and goes back to sleep more or less straight away - unless the appropriate power management assertion is made in time. ReallyPreventStandby depends on polling the state of the system at 60 second intervals. If it has resumed, if players are busy, or if the server is scanning for import it calls the prevent standby command - in the case of my settings this is caffeinate -i. It seems that ML will sometimes be sent back to sleep before that call of caffeinate, in a separate process, has had time to set the assertion. The following comments are copied from my latest post at http://bugs.slimdevices.com/show_bug.cgi?id=8141 as I still believe that this as an issue for the LMS developers to consider. If you agree, please vote for the bug. My firm view is that the source of caffeinate I found, and other examples since, should only be used as an example of the code that needs to be used withing LMS itself. iTunes does this, as can be seen by running pmset -g when it is playing and not playing. Ideally we should avoid the need for polling and take the appropriate action whenever sleep needs to be prevented or can be allowed again. (There might need to be a grace period though before allowing it again as offered now by ReallyPreventStandby - especially if the Mac is allowed to sleep while players are left on.) If hooks could be provided for this within LMS, platform-specific code could then be called. (It might be that some third-party plugins or Apps may themselves need to invoke these - I am thinking of Triode's Spotify and BBC Player for example but again, if sleep was prevented as long as any SB was on this should not be necessary.) I am hoping that the code called via the hooks could be implemented in OSX via the PerlObjectiveC bridge. I will carry on looking at ReallyPreventStandby but I am now more or less convinced that in the case of Mountain Lion we will have to set the assertions and release them within LMS itself and not by invoking new processes to run other commands. nonnoroger's Profile: http://forums.slimdevices.com/member.php?userid=35581 View this thread: http://forums.slimdevices.com/showthread.php?t=95980 ___ plugins mailing list plugins@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/plugins
Re: [SlimDevices: Plugins] OSX Mountain Lion sleep issues
nonnoroger wrote: Debugging the plugin and analyzing the code convinced me that in this case at least, the call of _killInhibitCmd() in the plugin's _hasResumed() is inappropriate, at least with these settings. It was having the effect of killing the caffeinate that had been started on resume - by a Touch sending its WOL to the server. I have now deleted that call and have found the operation to be much improved. However, occasionally the Mac Mini still goes back to sleep before the plugin has had a chance to make that call of caffeinate. ReallyPreventStandby but I am now more or less convinced that in the case of Mountain Lion we will have to set the assertions and release them within LMS itself and not by invoking new processes to run other commands. After the fix to ReallyPreventStandby I have let my system sleep after the grace period set in the plugin settings (I have it at three minutes), woken it again from a Touch and started playing a total of 10 times now. Out of 10 I found it did not honour the grace period once (going back to sleep as soon as I turned off the touch). So far it has not gone back to sleep while playing - although it did this once before my last post. So my fix to ReallyPreventStandby has very much improved things. Is anyone else prepared to try the fix and give us your experience? nonnoroger's Profile: http://forums.slimdevices.com/member.php?userid=35581 View this thread: http://forums.slimdevices.com/showthread.php?t=95980 ___ plugins mailing list plugins@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/plugins
Re: [SlimDevices: Plugins] Announce: Spotify Premium Plugin (Beta)
Thanks again for the help. I managed to figure out what it was with your guidance, and posting it here if anyone runs into the same kind of problem. A couple of days ago I installed a ftp-server called CrushFTP. The server automatically runs on port 8080 and 9090. The error messages have been solely due to this conflict between CLI (Command line interface) and the FTP-server. Once I killed the FTP, everything is back to normal again and works as a charm. A bit irritating though that the error messages displayed are so inconsistent in the squeezebox UI. Makes it hard to target the error. Anyway: Thanks for a great plugin. I don't think I have listened to a local mp3-file in almost two years due to this! danny041's Profile: http://forums.slimdevices.com/member.php?userid=20107 View this thread: http://forums.slimdevices.com/showthread.php?t=79706 ___ plugins mailing list plugins@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/plugins
Re: [SlimDevices: Plugins] Announce: New versions of erlands plugins
vagskal wrote: I tried to streamline my LMS set up by disabling Custom Scan startup rescan refresh and the automatic rescan (one issue was that new data supposed to be scanned by Custom Scan such as album rating for newly added albums did not show up, maybe Custom Scan which is really slow never had a chance to finish between my nightly scans). But after a PC reboot LMS web UI (but not the Custom Scan settings page) still reports a Custom Scan running. Is that just some kind of display issue? Feels a bit strange, do you have automatic scanning for new/changed files enabled in LMS ? If that's the case, it could be that LMS finds a new/updated track at restart and triggers a Custom Scan, I've seen this occurred when their are playlist files in music folder: http://bugs.slimdevices.com/show_bug.cgi?id=17274 I'm not sure when the scanning status is cleared, it could be that it isn't cleared automatically if a scanning has been aborted in a bad way. Another user had similar issues with SMD plugin and then the solution was to install Database Query plugin and create a Free form query with the following SQL: Code: delete from progress And execute this query and then restart LMS. vagskal wrote: I seem to remember installing a beta version of Custom Scan, I have v.3.0pre3832, that might be doing scans differently. How can I get the latest stable version back? I could not see any other version in the plugins page. 1. Make sure the alpha repository is NOT in the repository list in LMS Settings/Plugins: http://erlandplugins.googlecode.com/svn/repository/trunk/alpha.xml 2. Uninstall Custom Scan and reboot the server 3. Reinstall Custom Scan (this should now install the stable version) vagskal wrote: I still get long startup times although I have disabled TrackStat startup rescan refresh. The TrackStat version is 3.1.3829. Can you enable debug level logging of plugin.customscan and plugin.trackstat and post the server.log after the server is accessible after a restart, this should show if the refresh operations are executed and also how long time each part of it takes. Theoretically it could also be Custom Browse that's causing the delays but the intention is that this should only happen after a new version of Custom Browse is installed as it then have to re-parse all configuration files. erland's Profile: http://forums.slimdevices.com/member.php?userid=3124 View this thread: http://forums.slimdevices.com/showthread.php?t=49483 ___ plugins mailing list plugins@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/plugins
Re: [SlimDevices: Plugins] OSX Mountain Lion sleep issues
So, is this a simple change that we can make for ourselves, or does it require a modified plugin? If the latter, can you post your modification. I would be prepared to try it, though my own solution seems to be working for me at the moment. I have had no problems with WOL. Maybe my answer is not subject to the problem you report. But more likely that issue depends on the model of Mac that one has. I am using a 2007 iMac. I do agree that the best solution is for LMS to deal with the issue in its own code, but I don't see that we will have to set the assertions within LMS itself, when ReallyPreventStandby works, rather that it would be *much* neater. The one advantage of my approach is that it does provide a double-clickable way of preventing sleep, whatever else is going on. That is something I find useful. For instance, at the moment I m expecting an instant message from a friend so like to have my Mac awake with display awake, so as to make it easy to check if there is a message. Power assertions would not be the way to go with Messages/iChat, since most of the time one does not need to keep the machine awake, it is just a personal preference. Another case where power assertions wouldn't work is VisualHub, which still works fine but is not being developed further, so we are stuck with it as it is. danco's Profile: http://forums.slimdevices.com/member.php?userid=210 View this thread: http://forums.slimdevices.com/showthread.php?t=95980 ___ plugins mailing list plugins@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/plugins
Re: [SlimDevices: Plugins] Need help to test Custom Scan with support for new/changed scanning
PasTim wrote: Hi Erland - is there likely to be any progress with version 3? It'd be really nice to have fast scans for minor changes/additions if possible. I still hope to get some time to finish it, especially as I want it myself, it's just that I've had some trouble to find time for it during last months due to some other music related development activities which I at the moment have to give higher priority, due to this I don't expect much progress during next 2-3 months. However, if you still haven't seen any progress in a few months please feel free to push/remind me about it again. erland's Profile: http://forums.slimdevices.com/member.php?userid=3124 View this thread: http://forums.slimdevices.com/showthread.php?t=89768 ___ plugins mailing list plugins@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/plugins
Re: [SlimDevices: Plugins] Why is BBC iPlayer plugin not on Squeezebox Plugins page?
Triode wrote: Please add it to the wiki - I am afraid I am considering 7.3 and later and so only really thinking of Extension Downloader. Hi Triode Your app is wonderful. However I have a support issue but don't know where to post it. I doubt this thread is the right place, but could you give me a link to somewhere I can post my query? Dave DaveRado's Profile: http://forums.slimdevices.com/member.php?userid=56933 View this thread: http://forums.slimdevices.com/showthread.php?t=58791 ___ plugins mailing list plugins@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/plugins
Re: [SlimDevices: Plugins] Announce: New versions of erlands plugins
Out of curiosity I tried to download Squeeze Display from Google Play Store to my Android phone (running 2.3). However, try as I might it doesn't appear in the store when searching on my phone. Is there some regional or technical limitation (e.g. for larger screen tablets only)? I'm sure I can download it to my PC and install to my phone from there, but I've not had to do that before with any other applications. PasTim's Profile: http://forums.slimdevices.com/member.php?userid=41642 View this thread: http://forums.slimdevices.com/showthread.php?t=49483 ___ plugins mailing list plugins@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/plugins
Re: [SlimDevices: Plugins] Announce: BBCiPlayer Plugin (UK only)
New version of BBCiPlayer which removes livetext from live streams (as it has been withdrawn by the BBC) and experimental support of the new RadioVis based text and slideshow replacement. Note this only works for Radio 1 and 1Xtra at present as this is all that is supported on the BBC server. Please post feedback here.. Triode's Profile: http://forums.slimdevices.com/member.php?userid=17 View this thread: http://forums.slimdevices.com/showthread.php?t=53229 ___ plugins mailing list plugins@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/plugins
Re: [SlimDevices: Plugins] OSX Mountain Lion sleep issues
danco wrote: So, is this a simple change that we can make for ourselves, or does it require a modified plugin? If the latter, can you post your modification. It is a simple change to the plugin that you can make for yourself once it is installed. See next post for the modification. But let me clarify once again. ReallyPreventStandby still relies on polling every 60 seconds. There is an almost inevitable race condition that depends on the precise timing of asynchronous events that leads in my testing to the Mac occasionally going back to sleep after WOL before caffeinate has set the power assertion. For similar reasons, it sometimes goes back to sleep too early - ignoring the set grace period in the settings of Really PreventStandby. I asked if others wanted to try it nevertheless so we could get an idea of just how often this happens in practice. danco wrote: I have had no problems with WOL. Maybe my answer is not subject to the problem you report. But more likely that issue depends on the model of Mac that one has. I am using a 2007 iMac. Those of us who have more than one Mac (maybe even iPad/iPhone) could try WOL independent of Squeezeboxes. Sorry but again I seem to have failed to help you understand my point. It is not an issue with WOL in general but with WOL from a Squeezebox when ReallyPreventStandby is polling every 60 seconds. Hopefully, other applications that use WOL will do what is necessary themselves. The nature of the race condition will no doubt change depending on how many cores the processor has. I run LMS on a late 2009 Mac Mini. danco wrote: I do agree that the best solution is for LMS to deal with the issue in its own code, but I don't see that we will have to set the assertions within LMS itself, when ReallyPreventStandby works, rather that it would be *much* neater. It is not just a question of neatness. It is only with LMS creating and releasing its own power assertions that we will be able to reliably avoid the race conditions explained above. danco wrote: The one advantage of my approach is that it does provide a double-clickable way of preventing sleep, whatever else is going on. That is something I find useful. For instance, at the moment I m expecting an instant message from a friend so like to have my Mac awake with display awake, so as to make it easy to check if there is a message. Power assertions would not be the way to go with Messages/iChat, since most of the time one does not need to keep the machine awake, it is just a personal preference. Another case where power assertions wouldn't work is VisualHub, which still works fine but is not being developed further, so we are stuck with it as it is. Of course, I too would like Caffeine or something like it to work reliably again (I have had no response from the developers). But that is a different solution to a different problem nonnoroger's Profile: http://forums.slimdevices.com/member.php?userid=35581 View this thread: http://forums.slimdevices.com/showthread.php?t=95980 ___ plugins mailing list plugins@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/plugins
Re: [SlimDevices: Plugins] OSX Mountain Lion sleep issues
If you would like to try this out please follow these steps (first three probably already done): 1. In the settings web page go to the Plugins tab. (I usually start the web page with the Advanced Settings button in the LMS system preferences pane) 2. Under additional repositories at the bottom add http://srvrpowerctrl.googlecode.com/svn/beta.xml This is the link to Gordon's plugins. I am sure he would want me to remind you that this is still Beta code. 3. Apply the changes and then select ReallyPreventStandby from the list of Gordon's plugins. Apply again. 4. In the Plugins tab again, go to the Settings for ReallyPreventStandby. To reproduce my configuration choose: Allow standby after how many idle minutes? 3 Prohibit standby if players are on? Checked Inhibit standby command: caffeinate -i Re-enable standby command: pkill caffeinate Inhibit is a toggle command: Checked Then Apply the changes 5. Stop the LMS server from the preferences pane. 6. Go to /Users/USER/Library/Caches/Squeezebox/InstalledPlugins/Plugins where USER is replaced with your login name. To do this in the Finder you will need to hold down Alt while selecting the Go menu. 7. Edit Plugin.pm - TextEdit should do. Note Gordon's Copyright Notice. Find the definition of the subroutine _hasResumed. Comment out the entire line _killInhibitCmd(); by putting a # in front (alt 3 on my keyboard). I suggest you also add a comment line explaining why. 8. Exit TextEdit, saving explicitly first if you want to. Under Mountain Lion, TextEdit will already have saved the version at Open so you can restore that. 9. Make sure all your SBs are off (not with power disconnected but with the off button pressed, Radio, or selected Touch, which are the only models I have (Four Touches). Restart LMS from the preferences pane. 10. Optional, but I suggest you do this during testing: Under the Advanced Tab in the LMS Settings Web page, select the Advanced tab, Logging, and set ReallyPreventStandby to Debug. Apply. 11. Let your Mac go to sleep by reaching its configured idle period (Mine is set to 10 minutes). Hands off keyboard and mouse. We want to see what happens when you turn on an SB. 12. Start some music playing on your SB from My Music. 13. See if the Mac stays out of standby - for at least a couple of minutes or more. It should stay out of standby as long as at least one SB is on. 14. Pause or stop playing and turn off all SBs as before. See if the Mac stays active for the grace period (3 minutes in the settings above). 15. Once the Mac has gone back to sleep, go back and repeat fro step 12 a few times. We want to know how reliable you find ReallyPreventStandby with these settings and my change. Keep Hands off keyboard and mouse. 16. After several cycles, go back to your mac screen/keyboard and take a look at the LMS Server log in Console - if you set debugging above. Please let us know how you get on Many thanks NonnoRoger nonnoroger's Profile: http://forums.slimdevices.com/member.php?userid=35581 View this thread: http://forums.slimdevices.com/showthread.php?t=95980 ___ plugins mailing list plugins@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/plugins
Re: [SlimDevices: Plugins] OSX Mountain Lion sleep issues
nonnoroger wrote: It is a simple change to the plugin that you can make for yourself once it is installed. See next post for the modification. But let me clarify once again. ReallyPreventStandby still relies on polling every 60 seconds. There is an almost inevitable race condition that depends on the precise timing of asynchronous events that leads in my testing to the Mac occasionally going back to sleep after WOL before caffeinate has set the power assertion. For similar reasons, it sometimes goes back to sleep too early - ignoring the set grace period in the settings of Really PreventStandby. I asked if others wanted to try it nevertheless so we could get an idea of just how often this happens in practice. Sorry but again I seem to have failed to help you understand my point. It is not an issue with WOL in general but with WOL from a Squeezebox when ReallyPreventStandby is polling every 60 seconds. Hopefully, other applications that use WOL will do what is necessary themselves. The nature of the race condition will no doubt change depending on how many cores the processor has. I run LMS on a late 2009 Mac Mini. It is not just a question of neatness. It is only with LMS creating and releasing its own power assertions that we will be able to reliably avoid the race conditions explained above. Of course, I too would like Caffeine or something like it to work reliably again (I have had no response from the developers). But that is a different solution to a different problem I felt some of your earlier posts implied that you did not like the idea of Caffeine. It seems I was wrong. I have also written to the developer with no reply as yet. I understand about the possibility of a race. What I do not understand is why, after WOL has woken up a Mac, it would ever go to sleep before the idle period as set in Energy Saver. If it stayed awake that long, RPS would always win the race. That's why I was suggesting trying what happens with WOL in other situations. I note that a Google search does reveal some issues with WOL, for instance https://discussions.apple.com/thread/3735289?start=0tstart=0. When I have a bit of time, I'll follow your instructions on reworking RPS, much neater than mine. danco's Profile: http://forums.slimdevices.com/member.php?userid=210 View this thread: http://forums.slimdevices.com/showthread.php?t=95980 ___ plugins mailing list plugins@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/plugins
Re: [SlimDevices: Plugins] OSX Mountain Lion sleep issues
danco wrote: ... What I do not understand is why, after WOL has woken up a Mac, it would ever go to sleep before the idle period as set in Energy Saver. But that is not what happens with Mountain Lion. As I have explained in several posts. The idle period is only applied after interactive use. Once that has expired a WOL does not keep ML awake foranother idle period. This is why we are trying to find a solution. As I have also said before I think Apple have it right with ML. It is now up to developers to use the tools properly, (And I do know about legacy programs which will not be fixed but caffeinate and a corresponding GUI will provide a solution for that.) Caffeinate is fine for interactive use when the Mac is already awake, directly, or indirectly from scripts, but to call after WOL will give us race conditions in my view. nonnoroger's Profile: http://forums.slimdevices.com/member.php?userid=35581 View this thread: http://forums.slimdevices.com/showthread.php?t=95980 ___ plugins mailing list plugins@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/plugins
Re: [SlimDevices: Plugins] OSX Mountain Lion sleep issues
Couple of thoughts on your solution. The -i switch should not be necessary, as the default is to prevent idle sleep. For debugging purposes, caffeinate -di might be good. That prevents both display sleep and idle sleep, which makes checking easier in step 14. I've made your changes, but currently do not have time to check the result. danco's Profile: http://forums.slimdevices.com/member.php?userid=210 View this thread: http://forums.slimdevices.com/showthread.php?t=95980 ___ plugins mailing list plugins@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/plugins
Re: [SlimDevices: Plugins] Announce: New versions of erlands plugins
Erland, in your wiki under Trackstat / Music IP Integration, there is Export of ratings, play counts and played time for all tracks in SqueezeCenter. and The import/export functionality is found under the Custom Scan menu inside SqueezeCenter Settings in the web interface. Is there any documentation available without installing the Custom Scan plugin ? I cannot find any mention of Music IP Integration in the entry in your wiki for Custom Scan. Wirrunna's Profile: http://forums.slimdevices.com/member.php?userid=3225 View this thread: http://forums.slimdevices.com/showthread.php?t=49483 ___ plugins mailing list plugins@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/plugins
Re: [SlimDevices: Plugins] Announce: Beta version of SvrPowerControl
05mattjax wrote: SrvrPowerCtrl - will my Netgear ReadyNas Duo support this plugin? Would love to be able to turn off Nas remotely.Maybe. I gave my ReadyNAS 600 to my nephew a few years ago so I can't walk you through the steps. But at the very least, I think you'll need to get root ssh access to your ReadyNAS and then experiment to figure out what system commands will successfully suspend/hibernate the system. You should be able to get some advice from folks over on the ReadyNAS forum: http://www.readynas.com/forum/. If you'll be ssh-ing into your NAS from a windows client, then PuTTY is the ssh client terminal app of choice. WinSCP will be a useful tool too. Anyway, once you've figured that much out, you'll need to identify which user account the squeezeboxserver process runs under: # ps aux | grep 'squeeze' ..and having identified the account, you need to modify the /etc/sudoers file to grant that account passwordless permissions to run those suspend/hibernate commands. That's it, in a nutshell. If you've never had any experience bashing away at a debian system (which I think is the underlying OS of the ReadyNAS) from a command line, you'll be in for a very 'reto' experience. Good luck, and please post your recipe, if you cobble together one that works. gharris999's Profile: http://forums.slimdevices.com/member.php?userid=115 View this thread: http://forums.slimdevices.com/showthread.php?t=48521 ___ plugins mailing list plugins@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/plugins
Re: [SlimDevices: Plugins] OSX Mountain Lion sleep issues
I am not at all a computer person so I doubt if this will help. I did happen to notice this on a different forum and wondered if it might be useful. It is a caffeinate command that targets the specific program SABnzbd specifically. Could not we do the same thing with LMS? caffeinate -i /Applications/SABnzbd.app/Contents/MacOS/SABnzbd jdwek's Profile: http://forums.slimdevices.com/member.php?userid=56876 View this thread: http://forums.slimdevices.com/showthread.php?t=95980 ___ plugins mailing list plugins@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/plugins
