Support
All support resources for our products. Here you can find answers to frequently asked questions, discuss with other users, recover a lost license code or file a support request.
Forum closed
This forum was closed and turned into an archive effective April 21, 2018. It is no longer possible to create new topics or reply to existing topics.

Thanks everyone for all the great questions and contributions over the years.

Please use the Contact form to get in touch.

Remote Buddy Forum

Overview 

AuthorThread
User

11.04.2011 20:45:45
Re: EyeTV behaviour deactivation is NOT pausing EyeTV - Making my EyeTV / Plex integration FRUSTRATING!

This posting is older than 6 months and can contain outdated information.
I appreciate your response! I've tinkered with a setup just like this and you're absolutely right it does work fine. However it's not the "smooth" and contextual configuration I would prefer.

That's why I am attempting to use the Activate/Deactivate mappings on Remote Buddy behaviours. To me these (if they could be implemented successfully) are much more natural as they should be fired off REGARDLESS of how you "enter" or "exit" an application

EyeTV Deactivation tell application "EyeTV" to close every window 
EyeTV Activation tell application "EyeTV" to play; enter full screen 
Plex Deactivation tell application "System Events" to do shell script "killall Plex &"

If these 3 behaviour events actually worked then it wouldn't matter if you were switching from EyeTV to iTunes or Plex or anything, EyeTV will close all its windows, Plex will stop using resources and if you end up switching back to EyeTV then it will open the live TV window.

This implementation seems much more HTPC friendly to me and are what I was hoping to get from Remote Buddy. I've "sort of" got this working now by sticking each app (EyeTV and Plex) into their own Space, then allowing the OS to switch between the spaces. It _seems_ to be working and the transitions are pretty smooth so that's a nice bonus. EyeTV doesn't seem to be stealing focus with this setup, but in all this is still not quite as smooth as I would like. What would be FAR BETTER than the hacks I'm attempting to create is first class support from RB to implement the workflow. i.e.

************* Add an option to run the "deactivate" event handler for a behaviour BEFORE activating the next behaviour/application. This would enable me to "clean up" EyeTV before switching to another app and would likely solve ALL my issues with EyeTV in one swoop. This would also allow me to integrate something like Backdrop.app into the switching process to make the UI transition smooth, and being able to run a script BEFORE killing plex would allow me to open the EyeTV Live window and get it fullscreen BEFORE killing plex, so that transition would be much smoother as well.

This is why I'm currently experimenting with MythTV. I REALLY like the separation of concerns in Myth- there's a MythBackend daemon which is responsible for all recording and acts as a server for one or more MythFrontend clients. The frontend is FAR more capable than EyeTV- allowing you to manage recordings, schedule recordings, create "true" season passes, etc.. And when you switch to another app you can either kill the MythFrontend process or send it back to "home" where it doesn't seem to use any resources from what I can see (~ 4% of one CPU.) 

Thread-display::