vexingv

Members
  • Content Count

    10
  • Joined

  • Last visited

Community Reputation

0 Neutral

About vexingv

  • Rank
    Newbie
  1. Thanks for pointing that out. i have not tried it, but after looking at that post, it seems that with Jun's loader, 16 drive bays are the default on 918+, thus i guess i should be good to go since i will be using fewer than that.
  2. ^^^ bump I'm curious to find out as well. I just switched from 3617 to 918+ as it seems to include newer features. While I currently only have 4 drives installed, I still have 2 spare SATA ports on my motherboard. I know the 918+ has only 4 drives; if i just plug in two additional drives, will they automatically be recognized? Do I have to edit/modify any files so that it can use/recognize the two additional drives/SATA ports?
  3. I've been running an xpenology server since 2015 with DSM 5.1 until last year when Plex required a transition to DSM 6 with x64 packages. I then upgraded to DSM 6.1 with Jun's 1.02 loader and had been fine with that. Wanting to get more performance, I decided to upgrade my CPU from an i3-4130T to a Xeon E3 1285L V4, the best/latest CPU supported by my ASRock E3C226D2I motherboard, which has Intel Quick Sync support. As this was a significant change, I decided to change to upgrade to DSM 6.2.2 and take advantage of HW transcoding support in Plex too. Installation and migration went fine--I used existing serial/mac from an older Synology 415+. I checked that the Dev/Dri folders existed indicating that HW transcoding was supported. As a Plex Pass user, I enabled hardware transcoding support on the server. I initiated a stream on a device and the Plex dashboard showed that HW transcoding started and minimal spikes in CPU usage. However, the stream never actually played--it was continually buffering and would do so for several minutes and never started. I ultimately disabled HW accelerated transcoding and went back to software/CPU only based transcoding, which starts playing immediately. I understand that quality may differ while using HW transcoding, but in my case, it doesn't seem to work/start. Am I missing something here? Do i need to enable or add any additional drivers? Is this Xeon CPU not supported for HW accelerated transcoding via Intel Quick Sync? TLDR -upgraded CPU to Xeon E3 1285L V4 from I3-4130T -upgraded to DSM 6.2.2 with 1.04b loader for 918+ platform -HW transcoding supported and enabled on Plex server -with HW acceleration enabled on Plex server, stream continually buffers and never actually starts; wind up disabling HW transcoding -what gives? My server hardware: ASRock E3C226D2I Intel Xeon E3 1285L V4 / Noctua NH-D9L HSF Crucial 16GB (2x8GB) DDR3 ECC RAM (unbuffered) 4x3TB WD RED drives XFX XTR 550W PSU Fractal Design Node 304
  4. has this problem been fixed/addressed in DSM 6?
  5. i'm bumping this thread as i now see that many are now using DSM 6. has this issue with ACL/permissions on encrypted shares been fixed in DSM 6? thanks.
  6. Doman, sorry of the very late response. The only solution i found was to downgrade to DSM 5.1. I'm hoping this will be fixed when DSM 6 is released, whenever that may be.
  7. i wound up downgrading to 5.1.5055 to create some shares and change my ACL permissions. then i upgraded to again 5.2.5644. however, even with the ACL permissions corrected, i still had problems writing to the encrypted shared folders (getting errors that i did not have permission) on DSM 5.2. ultimately i had to downgrade to 5.1.5055 again and it looks like i'm sticking with that release until the issue has been corrected. i'm not sure what the new features are between DSM 5.1 and 5.2, but i'm also concerned of any security updates and other bug fixes that may have been corrected since DSM 5.1. honestly for a NAS, this ACL permission bug is a huge issue that should be getting more attention and getting fixed.
  8. That bug is quite annoying as there are some new features in 5.2. I'm surprised it has not been addressed in over 6 months. While less than ideal, have you downgraded to change/edit/create permissions, then subsequently updated to the latest 5.2 version?
  9. i tried on 5.2.5592 and 5.2.5664 and i have this problem as well in that i cannot edit ACL/permissions for existing encrypted folders, nor can I create any new encrypted shared folders either. is this a confirmed bug that is only correctable via downgrade to DSM 5.1? or have there been any solutions/fixes in the interim?
  10. When i first setup my xpenolgoy system earlier in the year (can't remember which version i started with but likely 5.1), i created a couple of encrypted share folders and things worked well. recently, i wanted to create another encrypted folder and wanted to add permissions to an encrypted shared folder for a new user. however, i cannot make changes any changes to the ACL/permissions of the existing encrypted shares nor can i create new encrypted shares. the error message i received reads: since creating those first encrypted shares, i had upgraded to DSM 5.2 (5.2.5565, 5.2.5592 and now 5.2.5664). perusing the boards, is this an issue with xpenology DSM 5.2? xpenology only? or are legit synology DSM users seeing this problem as well? any solutions? obviously, i had been using encrypted shared folders earlier without any issues. and i can still create and edit permissions for unencrypted folders just fine. this 4 hdd volume uses SHR and Ext4. any help/fixes/solutions? thanks. configuration if it helps: core i3 4130T, Asrock e3c226d2i; 8GBx2 ecc ddr3, 3TBx4 WD Red hdd's, fractal node 204