Search the Community

I am trying to get HW transcoding working on my Xpenology NAS. I am running TCRP with DSM 7.1 (7.1-42661 Update 4). I am using a real serial/mac address (things like ddns are working fine). I followed this guide when I was trying to make HW Transcoding work: https://drfrankenstein.co.uk/2021/12/06/plex-in-docker-on-a-synology-nas-hardware-transcoding/ Everything seemed to work, the folder /dev/dri/ is present: root@NAS:~$ sudo docker exec -it Plex sh # ls /dev/dri card0 renderD128 But whenever I transcode a movie, it isn't using HW transcoding (see attached file). This is the hardware that I'm using: - Processor: Intel Pentium G4560 Boxed - MoBo: ASRock B250M Pro4 - Power supply: Mini-box picoPSU PicoPSU-160-XT - RAM (8GB): Crucial CT8G4DFD8213 I am hoping that anyone here knows a solution to this problem.

"The device management of the company acquired by Intel is really a mess." Very much so, yes! Thanks for your attention to detail and application of scripts as it relates to this part/driver. Good to know that the SA6400 already has OEM support for the E3100G. I'll definitely try a SA6400 build, and testing the HW transcoding as well.

It seems that sudo is being used redundantly when the user is already a root account. It looks like you have a plex pass since you can select the hw transcoding device. Processing using i915.enable_guc to enable hw transcoding device acceleration has not yet had successful feedback for generations 5 through 10. The situation seems to be the same for the 8th generation. @MoetaYuko , the i915 developer for sa6400, couldn't tell me any more about how to enable it.

Thank you so much for sharing Peter Suh, this is awesome I think I might be doing something wrong, I cant seem to change the /sys/module/i915/parameters/enable_guc with vi or by echoing an update? Is there another way to correctly update it with a new value? using vi to update: "/sys/module/i915/parameters/enable_guc" "/sys/module/i915/parameters/enable_guc" E514: Write error (file system full?) WARNING: Original file may be lost or damaged don't quit the editor until the file is successfully written! trying to update with echo: root@slave:/# sudo echo 2 > /sys/module/i915/parameters/enable_guc -name: /sys/module/i915/parameters/enable_guc: Permission denied I can see the device in transcoder: As well as DRI in the system folders: Just everything is software transcoding:

I recently applied S.M.A.R.T activation of HBA (mpt3sas) on DS918+. It looks like there are still some problems left. I don't know if you can use a translator to translate this post from the Korean server forum where I work. https://svrforum.com/nas/1068754 We conducted transcoding tests on Kernel 5 SA6400 for all generations from Intel's 1st generation. This content also includes feedback from users. I thought there was already feedback on the 8th generation, but I was mistaken. No users have given any feedback yet. And if transcoding acceleration doesn't work, the only thing you can adjust is /sys/module/i915/parameters/enable_guc. I use a setting of 2 or 3, but I'm not sure what each number means. -> I found a setup guide for i915.enable_guc . https://wiki.archlinux.org/title/intel_graphics#Enable_GuC_/_HuC_firmware_loading

Thanks Peter Suh, it is great that these do support transcoding. They still are having issues reading information from the disks. This means I can't see disk temperatures or smart information at all using this version. Mpt3sas does work correctly with ds3617xs (without these below errors), so is likely a driver issue with DS918+, DS1019+ etc? These messages are flooded in the /var/log/messages file. Do you know if support for 8th Gen or others is still being worked on for Kernel 5? Would be great to be able to move to the latest versions 2023-12-15T13:00:25+11:00 Beast synostgd-disk[2611]: disk/disk_is_mv1475_driver.c:66 Can't get sata chip name from pattern /sys/block/sda/device/../../scsi_host/host*/proc_name 2023-12-15T13:00:25+11:00 Beast synostgd-disk[2611]: disk/disk_is_mv_soc_driver.c:71 Can't get sata chip name from pattern /sys/block/sda/device/../../scsi_host/host*/proc_name 2023-12-15T13:00:25+11:00 Beast synostgd-disk[2614]: disk/disk_is_mv1475_driver.c:66 Can't get sata chip name from pattern /sys/block/sdb/device/../../scsi_host/host*/proc_name 2023-12-15T13:00:25+11:00 Beast synostgd-disk[2614]: disk/disk_is_mv_soc_driver.c:71 Can't get sata chip name from pattern /sys/block/sdb/device/../../scsi_host/host*/proc_name 2023-12-15T13:00:25+11:00 Beast synostgd-disk[2617]: disk/disk_is_mv1475_driver.c:66 Can't get sata chip name from pattern /sys/block/sdc/device/../../scsi_host/host*/proc_name 2023-12-15T13:00:25+11:00 Beast synostgd-disk[2617]: disk/disk_is_mv_soc_driver.c:71 Can't get sata chip name from pattern /sys/block/sdc/device/../../scsi_host/host*/proc_name 2023-12-15T13:00:25+11:00 Beast synostgd-disk[2620]: disk/disk_is_mv1475_driver.c:66 Can't get sata chip name from pattern /sys/block/sdd/device/../../scsi_host/host*/proc_name 2023-12-15T13:00:25+11:00 Beast synostgd-disk[2620]: disk/disk_is_mv_soc_driver.c:71 Can't get sata chip name from pattern /sys/block/sdd/device/../../scsi_host/host*/proc_name 2023-12-15T13:00:25+11:00 Beast synostgd-disk[2623]: disk/disk_is_mv1475_driver.c:66 Can't get sata chip name from pattern /sys/block/sde/device/../../scsi_host/host*/proc_name 2023-12-15T13:00:25+11:00 Beast synostgd-disk[2623]: disk/disk_is_mv_soc_driver.c:71 Can't get sata chip name from pattern /sys/block/sde/device/../../scsi_host/host*/proc_name 2023-12-15T13:00:25+11:00 Beast synostgd-disk[2626]: disk/disk_is_mv1475_driver.c:66 Can't get sata chip name from pattern /sys/block/sdf/device/../../scsi_host/host*/proc_name 2023-12-15T13:00:25+11:00 Beast synostgd-disk[2626]: disk/disk_is_mv_soc_driver.c:71 Can't get sata chip name from pattern /sys/block/sdf/device/../../scsi_host/host*/proc_name 2023-12-15T13:00:25+11:00 Beast synostgd-disk[2629]: disk/disk_is_mv1475_driver.c:66 Can't get sata chip name from pattern /sys/block/sdg/device/../../scsi_host/host*/proc_name 2023-12-15T13:00:25+11:00 Beast synostgd-disk[2629]: disk/disk_is_mv_soc_driver.c:71 Can't get sata chip name from pattern /sys/block/sdg/device/../../scsi_host/host*/proc_name 2023-12-15T13:00:25+11:00 Beast synostgd-disk[2632]: disk/disk_is_mv1475_driver.c:66 Can't get sata chip name from pattern /sys/block/sdh/device/../../scsi_host/host*/proc_name 2023-12-15T13:00:25+11:00 Beast synostgd-disk[2632]: disk/disk_is_mv_soc_driver.c:71 Can't get sata chip name from pattern /sys/block/sdh/device/../../scsi_host/host*/proc_name 2023-12-15T13:00:25+11:00 Beast synostgd-disk[2629]: disk/disk_is_mv_soc_driver.c:71 Can't get sata chip name from pattern /sys/block/sdg/device/../../scsi_host/host*/proc_name 2023-12-15T13:00:25+11:00 Beast synostgd-disk[2629]: disk/disk_is_mv1475_driver.c:66 Can't get sata chip name from pattern /sys/block/sdg/device/../../scsi_host/host*/proc_name 2023-12-15T13:00:25+11:00 Beast synostgd-disk[2620]: disk/disk_is_mv_soc_driver.c:71 Can't get sata chip name from pattern /sys/block/sdd/device/../../scsi_host/host*/proc_name 2023-12-15T13:00:25+11:00 Beast synostgd-disk[2620]: disk/disk_is_mv1475_driver.c:66 Can't get sata chip name from pattern /sys/block/sdd/device/../../scsi_host/host*/proc_name 2023-12-15T13:00:25+11:00 Beast synostgd-disk[2611]: disk/disk_is_mv_soc_driver.c:71 Can't get sata chip name from pattern /sys/block/sda/device/../../scsi_host/host*/proc_name 2023-12-15T13:00:25+11:00 Beast synostgd-disk[2611]: disk/disk_is_mv1475_driver.c:66 Can't get sata chip name from pattern /sys/block/sda/device/../../scsi_host/host*/proc_name 2023-12-15T13:00:25+11:00 Beast synostgd-disk[2623]: disk/disk_is_mv_soc_driver.c:71 Can't get sata chip name from pattern /sys/block/sde/device/../../scsi_host/host*/proc_name 2023-12-15T13:00:25+11:00 Beast synostgd-disk[2623]: disk/disk_is_mv1475_driver.c:66 Can't get sata chip name from pattern /sys/block/sde/device/../../scsi_host/host*/proc_name 2023-12-15T13:00:25+11:00 Beast synostgd-disk[2617]: disk/disk_is_mv_soc_driver.c:71 Can't get sata chip name from pattern /sys/block/sdc/device/../../scsi_host/host*/proc_name 2023-12-15T13:00:25+11:00 Beast synostgd-disk[2617]: disk/disk_is_mv1475_driver.c:66 Can't get sata chip name from pattern /sys/block/sdc/device/../../scsi_host/host*/proc_name 2023-12-15T13:00:25+11:00 Beast synostgd-disk[2626]: disk/disk_is_mv_soc_driver.c:71 Can't get sata chip name from pattern /sys/block/sdf/device/../../scsi_host/host*/proc_name 2023-12-15T13:00:25+11:00 Beast synostgd-disk[2626]: disk/disk_is_mv1475_driver.c:66 Can't get sata chip name from pattern /sys/block/sdf/device/../../scsi_host/host*/proc_name 2023-12-15T13:00:25+11:00 Beast synostgd-disk[2632]: disk/disk_is_mv_soc_driver.c:71 Can't get sata chip name from pattern /sys/block/sdh/device/../../scsi_host/host*/proc_name 2023-12-15T13:00:25+11:00 Beast synostgd-disk[2632]: disk/disk_is_mv1475_driver.c:66 Can't get sata chip name from pattern /sys/block/sdh/device/../../scsi_host/host*/proc_name 2023-12-15T13:00:25+11:00 Beast synostgd-disk[2614]: disk/disk_is_mv_soc_driver.c:71 Can't get sata chip name from pattern /sys/block/sdb/device/../../scsi_host/host*/proc_name 2023-12-15T13:00:25+11:00 Beast synostgd-disk[2614]: disk/disk_is_mv1475_driver.c:66 Can't get sata chip name from pattern /sys/block/sdb/device/../../scsi_host/host*/proc_name

Activation has been verified only for Intel 4th generation, 11th to 13th generation IGPU, which is the transcoding of SA6400. I think the 8th generation will be difficult. There is a DS918+ (Apollo Lake) that supports both transcoding and mpt3sas. All Apollo Lake supported models support the above in the same way. DS1019+, DS620slim etc...

Hi Peter Suh, I'm running a 3617xs with mpt3sas drivers to support my raid card. Underneath its an 8700k CPU with 64GB RAM. Would the SA6400 be an appropriate upgrade pathway? Is there anything special required to enable fast transcoding for the CPU? I'm keen to upgrade as I'm still on an older version of your loader "0.9.5.0".

Grazie delle risposte. Io prima avevo un NAS "originale" Synology DS213J con 1 GB di ram e sta ora iniziando a perdere un pò i colpi con DSM7, pensavo con 4 GB di avere un miglioramento, visto che solitamente i NAS non hanno grosse ram installate. Il Terramaster F4-423 ha queste caratteristiche: Processore Intel® Celeron® N5105/5095 Architettura X.86 64-bit Frequenza Quad Core 2.0 GHz (Max burst up to 2.9) Hardware Transcoding Engine H.264, H.265, MPEG-4, VC-1; Massima risoluzione: 4K (4096 x 2160); FPS: 60 Memoria preinstallata 4GB (1 x 4GB) Disponibili 2 slot DDR2 SODIMM con massima memoria 32GB (16GB+16GB) Slot 4 dischi Allora Arc è una loader custom Redpill per DSM 7.x da quel che ho capito, non so se sia la soluzione migliore o meno, ma vedo che è in continuo aggiornamento già dalla versione scritta sono passate 2 minor release, ora siamo alla arc-23.12.11 (non so se questo sia un bene o un male). In teoria io utilizzo il NAS come contenitore foto e video, server multimediale e volevo provare ad utilizzare docker, che non era supportato dal mio vecchio NAS.

you're right. Synology's original specifications for SA6400 are based on AMD Epyc CPU. iGPU transcoding is only available on Intel CPUs. You can see it as hacked to enable the use of Intel CPU in SA6400 and then transcode to Intel iGPU. SA6400, the only model in XPE that supports kernel 5, is considered advantageous and suitable for new hardware of the 11th generation or higher. There are continued reports of cases where 12th and 13th generation MOBOs, which did not work on XPE kernel 4 models, work on SA6400.

Well it's definitely been mentioned here by several people, that the DSM Kernel is hardcoded for the numbers of supported cores/threads, based on model. Of course, maybe that is just. visual thing, in the Info Center, maybe in reality, it uses all there is available, this, I can't remember for sure. I'm on a 920+ which is also build on a 6 Cores / 12 Threads CPU. The 920+ officially is stated to support 4 Cores / 4 Threads, per the link. So if I am remembering the hardcoded support issue right, then we'd like both benefit to the SA6400. Interestingly, my Info Center is showing 6 Cores / 8 Threads. 🤔 I too also already have perfectly running HW Transcoding. Assuming there are no draw-backs from this model. 🤠

I don't think the model limits you to the actual number of cpus that be used by the system. Sure dsm might display all the CPU/cores but does that mean the rest are not being used? My 918 is built on a 6core, 12 core CPU. TOP only shows me number of cpus to be 8. I already have HW transcoding. So wondering if the move to SA6400 would be beneficial

I think I can see, aside from the great news @Peter Suh regarding the "Fast Transcoding" which at the moment, I assume to be HW, even though the system is built with an AMD by default, is that it's kernel should support 12 Cores and 24 Threads. So depending on your chosen hardware platform to build your NAS, your 918+ might support less than what processor is actually capable of. 🤞🏼 It also supports up to 32GB of ECC (don't know if required) RAM. https://kb.synology.com/en-nz/DSM/tutorial/What_kind_of_CPU_does_my_NAS_have

Hi all, I used Dell Precision 3620 (E3-1225v5, 8GB ECC) to build a TCRP-based (DS918+ DSM 7.1.1-42962) Plex Media Server (V 1.30.0.6486). My problem is excessive buffering when trying to stream Plex live TV from HDHomerun Duo. -Not a network issue as everything is hardwired and I can stream smoothly using the HDHomerun TV app instead of Plex -CPU use goes up from 2-3% to 30% (Due to Plex Transcoder; HW transcoding enabled in Plex, transcode off in Live TV/DVR settings), buffering every couple of seconds, regardless of video output quality -No issues streaming locally-stored video files (even transcoding with CPU use bump doesn't cause buffering) -No issues streaming live TV from another PMS running in Ubuntu with GPU passthrough in ESXI 6.7 I appreciate any pointers on what the issue might be and how to resolve it.

Sorry i was incorrect maybe. Is it possible to start P400 for transcoding in Emby/Plex? AI in SS is not inteded (it requires 4-9 gen Intel CPU). Thanks.

Do you use a translator? I have a hard time understanding your German-English translation. I don't even know the meaning of the German in the capture. The recently added SA6400 has many better features than DS3622xs+. It supports fast transcoding in the 12th generation, is device-tree based with the advantage of easy device mapping, and even supports HBA. The only issue is that I226 is not yet stable.

Please try my mshell. We recommend the new model SA6400, which uses kernel 5. Fast transcoding is also possible in Haswell. https://github.com/PeterSuh-Q3/tinycore-redpill/releases/tag/v1.0.0.0

Yes, that's right. Upgrading from kernel 4 to kernel 5 affects performance. It is also related to improving transcoding performance. -------- Oui c'est vrai. La mise à niveau du noyau 4 vers le noyau 5 affecte les performances. Cela est également lié à l’amélioration des performances de transcodage.

Great, at least now you can use hardware transcoding for Plex / Emby / Jellyfin If you are going to use h/w transcoding, I'd advise using the patch for nVidia drivers which allows more than 3 simultaneous NVENC video encoding sessions , which is a driver limitation imposed by nVidia on their consumer GPUs. https://github.com/keylase/nvidia-patch Clone the repo, run the patch, then restart the custom nVidia driver and you're good to go.

So you did not understand my point. No matter what driver will actually work. He could make latest 4090 RTX works on NAS system. As long as you/he/anyoned do not rebuild Surveillance Station SPK to accept these cards, you will only use these drivers to have HW transcoding capabilities for software like plex etc... but never for Surveillance Station AI features. No matter if nvidia-smi detect your card. if it is the same as DVA1622, Surveillance Station will generate some dump/core crash files on the filesystem in loop. If you are lucky, DVA3221 Surveillance Station SPK is not hardcoded like DVA1622 is... and then my point is irrelevant.

Please tell us your CPU model. Your question doesn't say the CPU model anywhere. There are only so many CPUs with 12 cores. The i7-8700 you mentioned below has 6 cores and 12 threads. https://xpenology.com/forum/topic/13030-dsm-5x6x7x-cpu-name-cores-infomation-change-tool/?do=findComment&comment=451802 The standard for determining the Intel CPU generation related to transcoding is the presence of the movbe command. https://github.com/PeterSuh-Q3/tinycore-redpill/blob/38def125c2e7072515951845d1f58f46e92f83a3/menu_m.sh#L582 If you want to forcefully select DS918+ from the model selection list in mshell, Just select Remove Restrictions at the bottom again. You must provide accurate information so that I can give you an accurate answer.

@Peter Suh Just took the plunge of switching from regular tcrp to your tcrp with M-shell. Burnt the v.1.0.0.0 img to usb and now im at the loader menu only to see that it doesnt list 918+ as a model to build for???? How come? is there an override to set that model? ive been on a 918+ build for a long time and wnt to stay on that for hardware video transcoding etc... Is your tcrp somehow detecting i have a 12 core cpu and only listing models that support that # of cpus?

MoetaYuko Thank you again. SA6400, which stabilized transcoding, was officially released to TCRP-mshell a while ago. I have completed verification on the 4th, 11th, and 13th generations of Intel, and will conduct additional verification on other generation CPUs. Is this possible for Ryzen GPU as well? I wonder.

[NOTICE] TCRP-MSHELL SA6400 i915 transcoding stabilization notice A few days ago, when updating SA6400-7.2.1 U3, there was a fatal error when automatically patching the RAM disk, so I fixed it. There was one more error left. When automatic updates occur, not only ramdisk patches but also kernel patches occur. The kernel patch script for kernel 5 was in the friend tools folder developed by @pocopico. This script was not complete. So there was a problem that resulted in a kernel panic. Stabilize the same by referring to ARPL's patch script. Today I upgraded the FRIEND kernel to version 0.0.9i. Currently, this version is verified by @MoetaYuko for Intel 4th, 11th, and 13th generations (a stable version that replaced the existing @jimmmmm version) It has been replaced with the i915.ko file. You can apply it by rebuilding the TCRP-mshell loader. It seems that all processors from the 4th generation of Intel that were previously capable of transcoding will be capable of transcoding. I think users should verify it one by one and give feedback. Status of automatic update up to SA6400-7.2.1 U3 and presence of /dev/dri folder This confirms the stable loading status of the i915 module. I haven't been able to check the HW transcoding message because I don't have a plex pass yet, but if you have a pass, (HW) will likely appear. I confirmed that even with SW transcoding, it played well while maintaining a CPU load of 7%. No additional activation processing for transcoding, such as installing AME, etc. was done. The serial number is also a virtual serial number randomly generated by TCRP.

Hi everyone, I'm new to Xpenlogy and I'm looking to set up a small NAS and the two options I'm considering are Asrock J5040 ITX or Asrock N100M Micro ATX, with the J5040 I see that there is no problem and everything works fine, with the N100 I see that it works, but being so new there are some problems with codecs and transcoding in plex. The N100 attracts me more because it is more powerful, it supports M.2, but of course, I mainly want to use the NAS for a video and music server with Plex, add an Azuracast (radio server) through docker and the usual NAS services, backup copies of photos, documents, print server, torrent, etc... The N100 on the other hand, only has 2 SATA ports and 1 M.2, the J5040 has 4 SATA ports, although I guess this, with a PCI card I can add more sata ports to the N100 or more M.2, I guess come on. What do you recommend today, the J5040 or the N100? Thank you.