@wahlman: what do you mean by updated existing users?
@wahlman: what do you mean by updated existing users?
https://www.youtube.com/watch?v=Tmlnht6nn_c
So is it safe to say that we should just wait for OpenPlex to come out with an updated version that does all of this for us? I like being lazy
So is it safe to say that we should just wait for OpenPlex to come out with an updated version that does all of this for us? I like being lazy
What to fix iMovie on IOS 8? All you have to do is copy over the plexconnect-patch.rar files and restart plexconnect. If/when its merged into the main code you just need to update iBaa's github or fork that has the iMovie patched files.
I see. Why do people use .rar files? For the Mac user out there, these are a nightmare!
I see. Why do people use .rar files? For the Mac user out there, these are a nightmare!
Not if you have something like The Unarchiver installed!
Oh I know there are options, i just don't understand why things aren't just in .zip format that is supported natively on windows and mac. Not complaining and i appreciate people doing the work. Just wondering if there is a good reason for the rar files. Maybe Linux based?
You da man wahlman
Sure... something like this. I still prefer processes, can't really tell why. :-)
I just would like to understand the difference from Trailers to iMovie - updating my aTV right now... looking into it over the next couple of days.
In the specific case, using a process does not really make much of a difference: if one of the server crashes, the other can't really survive. and given everything is written in an interpreted language, the security of separate processes does not really make much of a difference. still, it's your code, so it's your choice.
I kid you not: With the attached diff, everything works correctly for "iMovie Theater" too. I don't really grok python. but the param and appletv settings turn out empty/None in the XMLConverter inside the SSL server.
diff --git a/WebServer.py b/WebServer.py index fcbfcb8..e91564f 100755 --- a/WebServer.py +++ b/WebServer.py @@ -290,6 +290,11 @@ def Run(cmdPipe, param): def Run_SSL(cmdPipe, param): if not __name__ == '__main__': signal.signal(signal.SIGINT, signal.SIG_IGN) + + setParams(param) + XMLConverter.setParams(param) + cfg = ATVSettings.CATVSettings() + XMLConverter.setATVSettings(cfg)dinit(__name__, param) # init logging, WebServer process </pre>
Ok. That one wouldn't fly - I guess. With two instances of ATVSettings, at shutdown you never know if your fresh changes ones will win. Or get directly overwritten by the second process collapsing.
In the specific case, using a process does not really make much of a difference: if one of the server crashes, the other can't really survive. and given everything is written in an interpreted language, the security of separate processes does not really make much of a difference. still, it's your code, so it's your choice.
Yeah, I understand that processes might not be necessary here, as the amount of work being done on one request is not that huge either, risking to slow down the whole experience.
I guess, it's more a "learning by doing" philosophy, having a great playground here, even numerous testers. :-)
Task today: "use python and let one module/class (CATVSettings) serve two (or more) processes."
After a first look and read it might be nicely achievable using a proxy thing, on top of multiprocessing.managers.BaseManager...
We are all here for the fun if it, aren't we?
:-D
Ok. That one wouldn't fly - I guess. With two instances of ATVSettings, at shutdown you never know if your fresh changes ones will win. Or get directly overwritten by the second process collapsing.
clearly so. the result is indeterminate.
one could design a mechanism for the two instance to communicate and exchange the changes.
i'm not really sure it's worth it.
Yeah, I understand that processes might not be necessary here, as the amount of work being done on one request is not that huge either, risking to slow down the whole experience.
Modern operating systems implement threads and processes in terms of the same syscall. Thread are marginally more efficient, but only by an extremely thin margin. IPC between processes, on the other hand is quite expensive, whereas threads share the same memory.
Threads always run on the same core, processes can be shared between the 2 or 4 or 8...
Threads always run on the same core
I'm sure that's not right, different threads can run on different cores.
Hm. I thought that would be the main difference between a thread and a process?
Threads of the same process can run on different cores. The primary difference between threads and processes is shared vs separate memory spaces.
Having said that we need to be careful when discussing threads vs processes. The performance and implementation differences vary substantially between operating systems. In addition a thread in Python does not necessarily have to be equivalent to an OS level thread. It most likely is on most OSs, but threads can be implemented in both user space and kernel space and so the specific implementation matters.
So... here is another possible solution - if somebody wants to have a read. :-D
Using a python "proxy manager" to share ONE class instance across multiple processes - it's coded to easily fit into PlexConnect's naming scheme.
Main difference to today:
ATVSettings is owned by PlexConnect/Main. Then forwarded via Proxy to WebServer and WebServer_SSL.
I will have to see how this work in the complete project - and how it relates to the threading solution.
