Dave Jones
It's become plain from various experiments that a method of avoiding (or at least significantly reducing the chance of) single frame skip in synchronized captures, is to initialize the camera...
Instead of specifying a recording length in advance we really need a recording start and recording stop message. Might be worth thinking about SD card storage for this stuff, but...
The string protocol is nice and easy to debug, but there's enough variability in parsing time to make it a problem, at least when dealing with an array of Pi...
Broadcast isn't supported under IPv6, and multicast is considerably easier for users to setup (no need to know the correct netmask of the network - just use "find" and you're...
This'll be a pain in the ass given the dreadful state of Python distros on Windows but it's probably worth doing. Need to add PySide compat. into the GUI portion...
As mentioned in #5 we need tests for the UI components (command line and GUI); this is less important than ensuring the server and client logic remains fully tested but...
The current video support produces the wrong filename extension when downloading MJPEG recordings (because the server only knows that the file is a video file, not what sort of video...
There's too many options in config which should be specified (or potentially specified) directly in commands (capture count, delay, recording format, etc). Additionally, the tab-completion leaves something to be desired,...
The protocol could be expanded to include specific sub-lists of servers targetted by a broadcast which would improve synchronization when a subset of servers are specified. The major problem becomes...
The GUI needs documenting in a similar manner to the command line docs (section per function, screenshots, blah blah blah)