lightyear

Just an update - I noticed if you use a box with Intel UHD 630 iGPU, the local display output sometimes looks bleached out, way too high contrast. There seems to be some bug in the 630 monitor negotiation resulting in a weird profile or gamma. I have found a workaround though which get's the image back to normal - set a more precise refresh rate, so in my example above where I had 60hz (@60), if I use 59.94 instead the profile/gamma returns to normal. Examples would be 1920x1080@59.94 or 3840x2160@59.94. 4K60 looks sweet in SS.

Simple tweak but didn't see it mentioned on the forums. The DVA1622 ships with its local display output set to 1920x1080@60. You can tweak the config file and make it come up to 4K - assuming you are connecting to a 4K monitor. Depending on your monitor and host hardware, you might get 4K@60 working (rather than @30) - its working for me with a DVA1622 based off an HP ProDesk (Intel 630) but of course my monitor supports 4K60. My CPU still only 12% with monitor centre open and an AI task running, quite impressed. Dunno why they don't ship with 4K enabled out of the box - text and high res camera images look much crisper and can't see a reason not to use it if monitor is 4K. Note after you test it and it works there is also a .defaults version of the conf file you should update so this is persistent.

proptest showing the RGB settings are set to auto for the Intel 630 DP: Instead of 0 (auto), can set this to 1 for Full RGB range, and 2 for Limited 16:235 range, overriding the Intel bug when an HDMI adapter used.

I noticed on a bare metal box (DVA1622 + Intel integrated 630 graphics) that if I use a Displayport -> HDMI adapter then the output RGB levels are shifted (picture too bright). Using Displayport output to Displayport monitor is fine. This particular box doesn't have an HDMI output (HP ProDesk) and I wanted to plug it into an HDMI display so tried an adapter (which does work with other GPUs). Seems this is a known issue with the Intel graphics when an HDMI adapter is used. On Windows and Linux there are workarounds to tweak the RGB range (RGB Broadcast setting) between 16-235 and 0-255. Note I don't have adequate RGB range or black level control on the display so really it needs me to adjust what the 630 is doing. Going to see if I can get proptest from libdrm on there. Before I go digging I wondered if anyone looked at tweaking the 630 settings on Synology? https://community.intel.com/t5/Graphics/Full-Quantization-Range-0-255-not-available-with-Displayport-gt/td-p/610081 tia

The 1622 can only do 2 tasks (people/vehicle detection), or only just 1 face detection. If 1 (people/vehicle) task per camera is sufficient, with two cameras, the 1622 image is an option and should have much lower consumption. Another thing I noticed is if you leave the monitor centre open on the external display (I used 5 cameras, some with AI), it will cost CPU. I usually close it and reopen it on the local display when I need it.

My ESXi doesn't have a GPU that will work and I'm using its pcie slot for a raid card. Others have got it working though, although the 1622 image is only expecting an Intel 630 integrated GPU so as long as you have a compatible CPU with that you should be able to pass the iGPU thru. If you are wanting more than a couple of AI tasks you should be looking at the 3221 + Nvidia GTX 1650 route, although that's a big hot beast in comparison. Regarding (2), have a search about syslog-ng filtering. Depending on what you are installing on, different people will get different errors in their syslog logs, depending how close your hw matches a real box, but you need something like my parp2 rule: This is a kernel message so controlled by kernel.conf. I typically edit this in /etc.defaults/syslog-ng/patterndb.d and copy to /etc/syslog-ng/patterndb.d and restart the syslog-ng daemon, although doing it in the default folder and rebooting will also do it. You normally have some complaints in scemd.conf too you have to filter.

Don't make em .sh extension, they need to be same name as the binary (even though they are shell scripts). e.g. Make sure they are executable, e.g. chmod ugo+x <script>

Sure, I really appreciate the hard work here and happy to share... First locate the existing daemons that are crashing. The two I saw crashing and restarting constantly are synodvad and synofaced, since I had no suitable GPU for passthrough. The path will depend on your volume name but in my case the first one is here: /volume1/@appstore/SurveillanceStation/synodva/bin Move the existing synodvad binary out of the way (I just used 'mv' to rename them with a back up suffix). Now put script in its place, make sure you give them execute privs, e.g. chmod ugo+x. You can do this as root but you should do a chown and chgrp to make them appear as 'SurveillanceStation' although it was not necessary. Script for synodvad: #!/bin/sh # fool watchdog with another pid cp /tmp/dvaadapter.pid /tmp/dvad.pid Repeat for faced, found here for me: /volume1/@appstore/SurveillanceStation/synoface/bin/synofaced/bin And a script for faced #!/bin/sh # fool watchdog with another pid cp /tmp/faceadapter.pid /tmp/faced.pid It won't make AI work but this stopped these processes constantly dumping a core and the syno watchdog restarting them constantly.

Confirming Redpill DVA1622 DSM 7.2-64561 image working fine with both bare metal and under ESXi. Used standard tutorials although on ESXi I had no suitable GPU for local display so I did some mods to silence all the error reports in the system logs. Kudos to team. Details: ESXi 7 running on HP Microserver Gen 8 - Xeon E3-1265Lv2, 6GB VM (also worked fine with only 2GB) Didn't have suitable GPU for passthrough so no local display or deep analytics Flies, stays under 2% CPU most of the time Mem usage stays very low 5 cameras HP ProDesk 400 G4, i5-7500, 12GB 100% working, local display (Intel 630 native) and AI CPU sitting at ~7% with one AI task running on a 1080p/20fps feed Also feels responsive Disable secure boot in BIOS to boot redpill USB Edited scemd.conf and kernel.conf to remove usual log noise (complaints about synbios writes, iotcl, invalid parameters) - most of those the usual reasons like lack of LEDs, fans and serial port and easy to quench with filters in /etc.defaults/syslog-ng/patterndb.d. On ESXi due to lack of GPU, I saw deep video analytics (dvad) and face analytics (faced) kept crashing, and restarting every second - these were flooding the logs. Disabling the daemons doesn't really help since the watchdog keeps trying to restart them and will complain if it can't. The watchdog seems hardcoded with the process names to look for (the /tmp/*.pids actually) so there wasn't an obvious config file to tell it to ignore dvad and faced. A trick that worked was (at boot) run a script that fools the watchdog that the daemons were running - my script copies /tmp/dvaadapter.pid to /tmp/dvad.pid and /tmp/faceadapter.pid to /tmp/faced.pid, which is sufficient to make their watchdog think the AI daemons are up and stop complaining. That gets ESXi without Intel GPU happy with no log or crashing churn. The bare metal HP is running sweet. Nothing much to do there except filter out 'get empty ttyS' and some led_brightness messages due to lack of serial port.

I do this already and the Coral is crazy fast, pretty accurate (not perfect) and stopped me chasing the DVA3221 with a big hot gpu. Some use Frigate NVR on its own and its not bad at all. However, you can use both Frigate and DSM SS, which I do. The basic setup is this - have your existing DSM SS doing recording, possibly 24/7 although I do use my cameras' smart motion events for tripwire and zone intrusion. In parallel, I have frigate running on the cameras sub streams with a usb Coral doing object detection. This sends MQTT events on detections. I catch these with Node Red and convert to various DSM Action Rules (web hooks), which add bookmarks/trigger notification. So now my timeline shows not just camera motion events, but frigate AI detections too. I do more than this but that's the basic idea - the AI processing is offloaded to a Coral which takes about 10ms for inferences. Most people probably use Frigate NVR on its own or with Home Assistant, but I was already invested in DSM SS and like the product and they can run in parallel.

I assume you don't have a working local display GPU. Go to Application Center in SS and find and stop the Local Display service: You should also purge those *.pma files over SSH. They should not reappear now.