Transition Members
  • Content Count

  • Joined

  • Last visited

Everything posted by jhoughten

  1. For my Unraid VM, I had to specify USB 2.0 (EHCI) for the Bromolow build. I used the same VID/PID as you are. I did not add any settings for SataPortMap or DiskIdxMap, but I'm using a virtual HD, not passthrough. For the Apollolake build, I could use USB 3.0
  2. So, the Synology Photos package determines which platform it is running on. If it is running on a 3615, it does not use the acceleration method. There is nothing special to be done on that platform. If it is running on a 918, it "knows" that a 918 has the hardware to accelerate the face detection. On the virtual platform, the acceleration fails and the face detection does not fall back to an unaccelerated detection. It simply fails. So we have to pass through hardware to allow that acceleration. And we have to do it in a specific way for the package to use it.
  3. I switched to SATA boot, but I get the same error situation. The pkg-SynologyPhotos-face-extraction service is running. systemctl status pkg-SynologyPhotos-face-extraction gives a little more info. The error there just before the uncaught thread task exception is: "Error: (face plugin) load network failed" So, maybe MAC address is important on the 918, but not the 3615? I'm going to change the MAC to the Synology MAC for that SN.
  4. It's quiet today, so, I'll as this question. Does anyone have a definitive answer or even a pretty good idea as to why the face detection in Synology Photos works on 3615 but not on 918? I have 2 KVM based VMs (on Unraid), identical except for the SNs and MAC addresses. Redpill with JumKey's 7.0.1 develop branch The 3615 VM finds faces with no errors. The 918 VM gives the "synofoto-face-exctraction[] uncaught thread task exception /source/synofoto/src/daemon/plugin/plugin_worker.cpp:90 plugin init failed: /var/packages/SynologyPhotos/target/usr/lib/libsynophoto-plu
  5. However DSM interprets that value is beyond me. With Jun's loader on DSM 6.2.3, maxdisks=6, but the storage manager shows 5 used slots and 5 available slots. It must be some combination of the maxdisks and the internalportcfg settings. These new settings on 7.0 have storage manager showing disks 1, 17 and 18. Disk 17 is the loader USB device, even though I do have synoboot, synoboot1, and synoboot2 in the /dev directory.
  6. Right. It's a little confusing. SataPortMap, DiskIdxMap, etc are in the boot string, so, they really should be in the "extra_cmdline" portion of the user_config.json, no? While the maxdisks, internalportcfg, etc are in the synoinfo.conf, so should be in the "synoinfo" portion of the user_config.json. Using this as the user_conf.json does change the synoinfo.conf to contain the desired values: { "extra_cmdline": { "vid": "<fill me>"; "pid": "<fill me>"; "sn": "<fill me>", "mac1": "<fill me>", "DiskIdxMap": "0
  7. According to the RedPill Loader readme.md, you can change in when you build the loader and it should patch it: "synoinfo is a key=>value structure where you can override any synoinfo options (e.g. "SataPortMap": "...")" I'm testing it now.
  8. Also, it seems like the maxdrives and internalportcfg settings in /etc/synoinfo.conf keep reverting to their original settings. I have made the change in /etc/synoinfo.conf and /etc.defaults/synoinfo.conf. The usbportcfg setting is retained, but the others revert back to maxdrives=16 and internalportcfg=0xffff
  9. My face recognition is also not working. In /dev/dri there is a card0 and renderD128 In /var/log/synofoto.log, I get this error over and over again: 2021-09-09T11:48:15-06:00 DS918 synofoto-face-extraction[19489]: /source/synophoto-plugin-face/src/face_plugin/main.cpp:22 face plugin init 2021-09-09T11:48:15-06:00 DS918 synofoto-face-extraction[19489]: uncaught thread task exception /source/synofoto/src/daemon/plugin/plugin_worker.cpp:90 plugin init failed: /var/packages/SynologyPhotos/target/usr/lib/libsynophoto-plugin-face.so In /var/log/messages, I get this er
  10. The thing about the extra_cmd_line is that it just adds that stuff to the linux /zimage command that starts. You can actually edit this without rebuilding the image. When the GRUB screen comes up, you can hit the e key to edit the command. I added DiskIdxMap=00 SataPortMap=1 SasIdxMap=0 to the end of the command - after syno_port_thaw=1 Then I was able to boot! And I was able to install DSM7.0. The command line changes are not saved when you reboot, so you may want to make them permanent and rebuild the image file once everything is working. The
  11. @snowfox The UEFI version is here: @maxhartung Does your EliteBook 840 G2 work with Jun's loader on 6.2.3?
  12. So, I got the UEFI version to boot. Thanks Jumkey! I'm getting the "We've detected an error on the hard drives (2), and the SATA ports have also been disabled." error. I only have 1 SATA port. Can I fix this with the synoinfo settings?
  13. How are you booting in UEFI? The image file has the MBR structure. I haven't seen anything about what changes need to be made to build a UEFI image.