Jump to content

cswartzlander

Member
  • Posts

    10
  • Joined

  • Last visited

About cswartzlander

  • Birthday 08/23/1979

Profile Information

  • Gender
    Male
  • Location
    Atlanta, GA

Recent Profile Visitors

374 profile views

cswartzlander's Achievements

(2/3)

  1. Wang, I have a bit more information for you. I was able to create a Wireshark packet capture of the RTSP negotiation on a Watchout 6.1.5 computer and can send it to you via email. However, I was not able to create a packet capture of the failed RTSP connection. The request is literally never sent from the Watchout 6.4.1 computer to the camera. I have tried it with both TCP and UDP (unicast) which both failed. Since it doesn't make much sense to send you an the empty failed RTSP packet capture, I thought I would provide you with this information prior to asking you to sift through the good connection. As a workaround, we bought the NDI|HX license for this particular camera. This is working correctly with Watchout 6.4.1, so the pain point has been alleviated. However, we do have several other Watchout 6.1.5 systems that use RTSP sources which we will want to update in the future. It would be good to sort through this issue and restore functionality to this feature. If you would like me to send the successful 6.1.5 RTSP packet capture for this camera, I would be glad to provide. Unfortunately, the failed 6.4.1 RTSP packet capture is devoid of any data. Thanks! Clint
  2. Wang, Unfortunately, I cannot easily move it over to a public IP. I could send you a Wireshark capture of a successful connection with the camera to VLC as well a Wireshark capture of the failed negotiation to Watchout. If you have a suggestion of any other tools we can use to analyze the RTSP connection, I would certainly be glad to try them. Also, I tested with another known-good RTSP stream from a totally different manufacturer and experienced the same error message. The problem does not appear to be related to the manufacturer / model of camera. Thanks! Clint
  3. Dataton Support, We have a Watchout system that was updated from version 6.1.5 to version 6.4.1. After performing this update, network video assets using an RTSP streams from our cameras have stopped working. The error received when attempting to play is as follows: error: no video network support We have verified that the RTSP stream is still working within VLC player. That is to say, the URL is correct. We have also deleted / recreated the network video asset in the media bin. Have there been any changes that would affect RTSP support? Did the desired format of the URI change within Watchout? The stream is configured as follows: URI = "rtsp://192.168.100.109:554/MediaInput/h264/stream_1" OR "rtsp://192.168.100.109/MediaInput/h264/stream_1" Stream = UDP Unicast Dimensions = 1280 x 720 The camera is a Panasonic AW-HE130 with the most recent firmware installed. No system changes other than the Watchout update have occurred. We experience the same result when testing with several other Panasonic cameras in the building. Thanks! Clint
  4. Dataton Support, We wiped the production computer clean and installed the following applications: Windows 7 64-bit Service Pack 1 drivers Quicktime Watchout 5.5.1 We installed the following Windows updates (as required by driver installation): KB2565063 KB958488 KB976902 Firewall is disabled. The image still blinks on DIS and does not display on the production computer. To recap, we have now wiped and rebuilt both the DIS and production computers. DIS will work with a different Watchout 5.5 system, but will not work with the 5.5.1 system. Any suggestions or recommendations would be greatly appreciated. Thanks!
  5. Jonas, The original issue posted in this thread is still unresolved. The next step is going to be to rebuild the Production computer. Prior to taking this step, I would appreciate some feedback from Dataton. Can you provide some insight into this problem? Thanks! Clint
  6. Clarification - The WYSIWYG editor made some changes to my previous post. The smileys were supposed to be System B, but the combination of B and ) appears to be an escape sequence for emoticons. I checked the system time on all computers. They are all set fairly close. Also I ran Wireshark again and saw the UDP packets arriving at the Production computer. Any suggestions on what to try next?
  7. Thomas, I reverted to the on-board graphics card in the DIS. The problem persists. We have attempted several additional troubleshooting steps. Here's what's new: The DIS works correctly with a different Watchout 5.5 system (System , but does not work with the Watchout 5.5.1 system (System A) for which it was intended. In order to determine if 5.5.1 has issues with DIS, we updated the 5.5 system (System to 5.5.1. The DIS continues to work correctly with the updated system (System . However, it still does not work with the intended system (System A). Reinstalled Watchout 5.5.1 on the Watchout Production computer (System A). Problem persists. In order to determine if the issue was caused by the cloning process used to deploy the system, we re-built the DIS from scratch. We installed Windows 7-64bit, device drivers, Quicktime, and Watchout 5.5.1. The firewall was disabled. The problem persists. I agree with Mike's conjecture that UDP packets aren't making it into Watchout. I see UDP packets (with Wireshark) that contain the file arriving at the computer (packet header has file name clearly identified), but Watchout does not recognize that the data is being received. Is is possibly a data timestamping issue? I'm going to check BIOS clocks on all of the machines. There has to be a valid reason why Watchout does not see the data. Any other thoughts on what would impede the flow of UDP to the application? Thanks for your input gentlemen!
  8. Mike, I ran WireShark on both the Image Server and the production computer while adding dynamic media. I see UDP packets going both directions between the two computers. Based on this test, UDP is making it through the network. Also, the same Image Server works normally with our other Watchout 5.5 system. JFK, As you recommended, we have changed the display computer reference from IP address to name. The problem persists. To verify that the issue is not related to the cloning process, I have gone through the uninstallation process again. This time, I wiped the registry of any reference to Dataton and Watchout. Any suggestions on how to resolve this issue would be greatly appreciated. Thanks!
  9. Gentlemen, Thank you for the prompt responses. The system is in-use for extended hours due to holiday scheduling, but I will try your suggestions as soon as there is some down-time. I have some additional information which may provide some insight into the problem. First, I attempted to use the Dynamic Image Server with another Watchout system in the building. This worked without issue, and the image displayed correctly. We did not experience any of the blinking issues. This Watchout deployment is on the same network, and it is configured in the same manner (using IP addresses; not names). This system is running Watchout 5.5 (not 5.5.1) on both the Production and Display computers. Second, the Dynamic Image Server system drive was cloned from Production computer of the Watchout system that cannot connect to the DIS. After the image was deployed, the computer name and IP address were changed. I uninstalled / reinstalled Watchout on the DIS, but I did not clear the registry of all entries for Watchout. Is is possible that a pre-existing registry entry would cause the symptoms that we are experiencing? Thanks for your help! Clint
  10. Dataton Support, We are experiencing issues with Dynamic Image Server 5.5 (as packaged with Watchout 5.5.1). When adding a dynamic image to the production computer, the production computer reports the following error: From Dynamic Image "<media name>" of Media List, <timestamp> Error: Server Timeout In addition to receiving this error message, the requested image blinks in the Dynamic Image Server window. The file requested is jpg format. System Specifications: Windows 7 64-Bit Enterprise, Service Pack 1 Intel i5-3570k (Image Server) Intel i7-3770k (Production and Display Computer) Gigabyte Z77X-D3H Motherboard 8GB RAM Nvidia 640GT Display Card (Image Server and Production Computer) AMD 7970 Display Card (Display Computer) Datapath Vision RGB-ES1 Capture Card (Production and Display Computer) Additional Information: Windows firewall disabled All computers have static-assigned IP addresses in the same subnet Production and Display computers function normally otherwise Steps Taken: Verified file path is correct (based on blinking behavior on Image Server, server and file path should be correct) Verified Production computer can load the same image file directly; independent of the Image Server Attempted to use different file and file format Reboot all computers Uninstalled / reinstalled Watchout on Image Server as suggested in other threads reporting similar issue. Please let me know if I can provide any additional information. Thank you for your help! Clint
×
×
  • Create New...