Mike Fahl
-
Posts
723 -
Joined
-
Last visited
Posts posted by Mike Fahl
-
-
This error message indicates a corrupt ZIP file. How was it compressed? How large is the file?
I found a similar conversation with another customer a while back, here's a workaround and some comments related to that.
Desite the errors reported by the MacOS X
zipinfo command line program, I was able to unzip it on my Mac. After re-zipping it on my Mac, I was then able to bring it into WATCHNET. Hence, it seems the zip is “wierd” in some way that WATCHNET doesn’t like. Since it seems the zip contains no files that need unicode encoding for their names, you may want to try another method for zipping it, such as the one built into Windows (just right-click and choose “Send to > Compressed (ZIP)”).The BANDIZIP suggestion is a temporary solution anyway, and was nice since it supported unicode filenames and was free. But it seems it doesn’t generate entirely reliable ZIP files for large file collections (although it seems to work OK for smaller file sets).
Hope that helps.
Mike
0 -
If you want truly small form factor, your're not going to get the best performance, as you probably figured. Here's a small "player" style box with four outputs that could perhaps qualify, depending on what you mean by "small-form":
http://www.aopen.com/us/shop/products/digital-engine-de6140
Mike
0 -
Finding the proper URL for a particular camera can be challenging. There are some pointers here for example:
http://www.soleratec.com/support/rtsp/rtsp_listing?camera_company=D-Link
You're looking for the "RTSP URL". This should really be documented by the camera manufacturer. Have you checked the manual?
Mike
0 -
There's no "maximum number" as far as WATCHOUT is concerned (as with most other things in WO). So the answer is the dreaded "it depends". It depends on resolution, framerate, encoding, network bandwidth available, what else the system is doing, desired quality, etc, etc. So I suggest you just give it a try, tweaking the above properties as you go until you figured out whether it works for your use case. I suggest you avoid any wireless network stuff.
Mike
0 -
No. Data is sent right away. You should be able to confirm this by using any app that can receive and act on data arriving on a TCP port.
For instance, you could set up one WATCHOUT prod to talk to another by enabling TCP control on the 2nd), and then send prod PC protocol commands to it. It should respond instantly.
My guess is that your framing is incorrect. What should the command line be terminated with? Perhaps there are more framing characters needed before/after the command string. You mention CR above ($0D). Do you know this for a fact?
If the framing is indeed something else, that would explain why it doesn't work when you just append a CR to the command string. Again, please try sending the command from a TELNET client to the device, to see if that works as desired. If it does, WATCHOUT should work the same way. If it doesn't, contact the manufacturer of the controlled device and ask them why. Using TELNET as a client would make it easy for them to repeat your test, and is totally independent of WATCHOUT.
Mike
0 -
If you have one program that CAN talk to the device successfully, and you don't have accurate docs as to what youre supposed to send, you can always snoop the wire to see what the successful program sends, and then mimic that. But of course having proper docs that shows exactly what data to send is preferable (including "framing" such as a CR at the end of the line, or whatever is expected).
Mike
0 -
That generally means there's no one listening to that TCP port on that IP address. Try connecting to it using TELNET instead to make sure you can connect to it and send commands as expected.
Mike
0 -
It means that the computer you send the load command to loads a show with specified name. It then tries to find "itself" in that show, and the display output(s) to be used. This operation fails. Perhaps since its IP address doesn't match, or perhaps its name doesn't match (if you use named computers instead of IP addresses). For instance, if you load the show form a command file, and have no network attached, the computer may not find itself based on IP address, since it typically has no IP address unless there's a network connection.
Mike
0 -
Make sure you zip the file itself. Not the folder it's in. I.e., the DFC_DATA file must be at the "top level" inside the zip.
Mike
0 -
I wasn't sure how much higher the data rate might need to be for comparable quality in mpeg2.
Depends on the content, how well it compresses, and how picky your client is ;-). So "your mileage may vary", as they say.
Mke
0 -
That would be a particularly crummy implementation of TCP which just throws away data when not "ready". But I wouldn't be surprised if Bill is right (he typically knows what he's talking about ;-). Bill's suggestions of sending two cues, the first with jusy a $OD anf the second with the real command, spaced apart by a second or so, should tell. The first command will open the connection and send a (hopefully) innocent Carriage Return character. The delay will let the projector "wake up" and come to its senses. The second should then execute the desired command.
After opening a TCP connection, WATCHOUT will keep it open for a while (about a minute if memory serves me), in case new commands come along to the same connection. After a timeout with no further data being sent, WATCHOUT will close the connection.
Mike
0 -
You can switch the status displays to match DF or NDF SMPTE, but the timeline readout is always in real time (with mS resolution), so it may differ if you're using certain SMPTE formats. Straight B&W 30fps timecode should always match to the second though (although its resolution is 30fps frame rather than mS, of course).
Mike
0 -
Best way to troubleshoot this is probably to snoop the Ethernet wire data and compare what WATCHOUT sends with what some other controller sends, to see if there's any difference that can explain the discrepancy. I use Wireshark, which is a free utility.
Mike
0 -
Here's another similar example, this one encoding staight from an image sequence (which is often a more practical source format:
ffmpeg -y -threads auto \
-r 25 -i "/Volumes/Backup/InkDrop4kJpeg/InkDrop4kHD[0000-3827]%04d.jpg" \-f vob -vcodec mpeg2video -b:v 60000k -minrate 60000k -maxrate 60000k -g 15 -bf 2 -an -trellis 2 \"/Users/mike/Desktop/inkDrops-60MBit.mpg"Hope this helps.Mike0 -
This is one I used:
ffmpeg -y -threads auto \
-i "/Volumes/rawvideo/R3D_3840x2160_30FPS.mp4" \-f vob -vcodec mpeg2video -b:v 80000k -minrate 80000k -maxrate 80000k -g 15 -bf 2 -an -trellis 2 \"/Users/mike/Desktop/3840x2160-80MBit.mpg"I also made some tests with H264, which also worked fine, although MPEG2 is less taxing on the CPU.We recently ran three 4k outputs from a single chassis, which seemed to work well. This was on a fairly beefy AMD card, with DisplayPort straight to the displays (running 4k at 60Hz).Mike0 -
There's no built-in way to do what you want. It would be rather simple to make an external control app talking to WATCHMAKER through its network port to trigger those. That would then live in its own window, providing only the controls you need (e.g., press spacebar to trigger main timeline, and a few keytboard or on-screen buttons to trigger other timelines).
Mike
0 -
The only way to do pre-split video is using a Video Proxy, so I'm not really sure what you're asking here. To use this, you need to create a separate video file for each display, spaced properly to match the distance between displays you set up in WATCHOUT.
Mike
0 -
Please describe in more detail what kind of system configuration you try to build. Describe it from a usage point of view - not your idea of how to accomplish it. Getting a better understanding for what youre actually trying to do would make it easier to suggest a good solution.
Mike
0 -
You may want to download a complete, working example and start from there:
http://academy.dataton.com/recipe/basic-flash-controller
There's some more elaborate examples included with the Flash-based Systems Manager:
Mike
0 -
I assume you've already seen this:
http://academy.dataton.com/recipe/kinect-input
Uses the original Kinect, and includes all you need to get going with some basic interaction.
Mike
0 -
Something like this
var wo : WATCHMan = new WATCHMan("192.168.1.221");
var auxTL : AuxTimeline = wo.GetAuxTimeline("MyAuxTimelineName");
auxTL.addEventListener(AuxTimeline.KEvt_PlayingChanged, function(evt : Event) {if (auxTL.Playing)gotoAndStop(10);
else
gotoAndStop(1);});
(writing from memory, so take the above with a grain of salt)Mike0 -
Any Mac version?
Mike
0 -
FYI, the location of this log folder is covered in the manual:
http://academy.dataton.com/watchnet/running-server
Mike
0 -
If the image disappears on screen when this happens, it sounds like a playback issue. If the image stays on screen as you get this message, it sounds more like a network problem.
Mike
0
production on win8
in WATCHOUT FORUM
Posted
WATCHOUT 5.5.2 will be released early next week. It improves compatibility with Windows 8.1. Let us know if that solves your problem. If not, please contact support@dataton.com for assistance.
Mike