IG-88

if the intel qsv is working you should be able to use the example from there can you try what happens when you eplicitly convert a file using intel qsv ffmpeg -i INPUT -c:v h264_qsv -preset:v faster out.qsv.mp4

i've tryed to build the module for 3617xs, dsm 6.1 as comiled there was only a mvsas.ko, but from the makefile it looks like it should contain the code for 94xx in my 3617xs vm the image booted and the mvsas driver was loaded, it's as good as i can do it atm, try it with your 3617xs installation and let us know what the result is 1.02a2 with mvsas http://s000.tinyupload.com/?file_id=047 ... 8171187484

ich vermute mal windows pc auf dem vmplayer benutzt wird? dann bliebe noch der steinige weg mit dem kostenlosen virtualbox und der "normalen" installtion von dsm 6.0.2/6.1 viewtopic.php?f=2&t=29582&hilit=Tutorial%3A+Install+6.x+on+Oracle+Virtualbox

looks like you would need a extra kernel module mv_94xx.ko (your card has Marvell 9480) not provided by synology or jun's loader only way will be to build it yourself, i wrote a how to so you might try it? viewtopic.php?f=2&t=32744 as i already have enviroment for 3615xs dsm 6.1 i could provide the module or even bootimage for that version as you are using 1.0.2a2 you will have used 3617xs 6.1 you would have to change to 1.02a and 3615xs to use the bootimage i can provide atm (or someone else might provide the module/bootimage for 3617xs?)

afair on my 6.1 test install i also tested mtu 9000 with my second nic (10Gbit) to see if performance was at least the same as with 5.0 (it seemed to be better)

this should be USED

i have a 5.0 and as i knew there where sata porblems with newer 5.x version i wanted to know if the hardware works fully disconncted alls disks, removed usb boot stick with 5.0 loader took empty disk and usb stick with newer dsm 6 jun loader and tryed to install a clean dsm and checked if all hardware is detected and working you might do the same, that way you would know if it comes from your old 5.x config or it is a general problem (unlikely) btw. in my 5.0 i found the actual mtu info not in /etc.defaults/synoinfo.cof (there all were 1500), the actual used value i found in /etc/synoinfo.conf, that matched what is configured in the web gui i'd expect your problems (you discovered so far ...) will be gone if you set the network config with 5.x running to defaults, no bonds, default mtu (for all nic's), it will be no problem to redo the settings if upgrade was successfull

viewtopic.php?p=99744#p99744 das sieht aus als wäre es für vmware workstation, wird dann vermutlich auch mit vmplayer laufen aber ohne etwas über die quelle zu wissen ist das natürlich auch ein gewisses risiko ... die Surveillance Station kannst du dir dann aus dem packet-zentrum nachinstallieren

don't try to install 6.1.1 if the updater suggests it, 6.1.1 uses a new kernel 15101 instead of 15047 from 6.1 so jun 1.0.2a/a2 will not work edit: looks like the problem was in the test vm as other people dont have problems with it so it should have been more a warning that it did not work for me

mmmhhh, after following my own link, yes it does, i had a few tabs to ark.intel.com open as i wrote this, must have looked on a wrong/different tab as i compared it with the N3710 that 's what i took from the serviio syno package and posted here, ffmpeg is no option for hardware trancoding (atm), ffmpeg will use the normal cpu features and that means you need lots of cpu power if you want full hd transcoding (and thats usualy "only" h.264) to lower resolution if you want hardware transcoding with dsm you will have to try the 916+ image (jun 1.02a2) or patch a synology kernel with ffmepg und complettly build (not just a kennel module) and implement it in dsm, don't know if anyone ever suceeded or even tryed that the 916+ image might be working shortly, jun brougt it up so i expect he will make it work if it does'nt work with 1.0.2a2

try to put in all 3 real mac addresses in grub.cfg set mac1= set mac2= set mac3= set netif_num=3 both normal, ssh has to be activated in webgui after install, default is off there are guides for downgades her in the forum too (never done one myself) edit: you might also try to disable the onboard nic an try set mac1= set mac2= set netif_num=2 with just the 2 port intel nic

what ever it is it shoud be found in /var/log/messages, dsm has to start a driver and recognise ports for storage

found some interrsting detailed inforamtion about the hardware transcoding on intel based synology boxes "... DS214play and DS415play with Intel Evansport SoC are the only models supported. Serviio uses the multimedia tool FFmpeg for manipulating media files, and I am only able to build a hardware-assisted FFmpeg for DS214play and DS215play. Subsequent to those products, Synology has marketed a number of other systems with hardware transcoding features but these are not supported by Serviio. The DS216play with STiH412 Monaco SoC uses a specialised build of Gstreamer for the Synology transcoding solution, so its hardware features cannot be used by FFmpeg. It seems likely that Synology is also using Gstreamer for the Intel Braswell or newer generation CPUs with QuikSync, since DSM ships with an older FFmpeg (2.7.1) than the version which introduced QuikSync support (2.8.0). To implement FFmpeg QuikSync hardware transcoding support requires Linux kernel patches for libmfx support which is not currently included in DSM 6.x, so Serviio support for Intel QuikSync on Synology is unlikely unless Synology in future switches to using FFmpeg for its own hardware transcoding solution. ..." https://pcloadletter.co.uk/2012/01/25/serviio-syno-package/ if someone plans to use ffmpeg in cooperation with Quick Sync Video, DSM 6 is no good, but the synology inegated hardware trancoding might work if the processor supports Quick Sync Video (up to now no reports about a running dsm 6.1 916+ image on non synology hardware)

sysnology liefert treiber eigentlich nur mit für was sie selbst verbauen oder unterstützen, das sind usb basiert dvb adapter, die fertig compilierten treiber für pci/pcie karten sind zwar im source vorhanden werden aber nicht mitgeliefert, die müsste man sich selber bauen, genauso wie es z.b. jun mit den treibern für diverse storage und netzwerk controller macht und in seinem bootloader mitliefert habe grade im englischen bereich ein how to geschrieben der dies dokumentiert so das man sich seinen treiber selber bauen kann - einige linuxkenntnisse vorausgesetzt für dsm 6.1 auf 3615xs habe ich alles vorrätig, da ließe sich das relativ schnell bauen und in ein bootimage integrieren für 6.0.2 mit jun 1.01 loader geht meine anleitung theoretisch auch aber da habe ich keine testumgebung, kann also nicht mal eben was zusammenwerfen wenn man bereits eine dsm am laufen hat muss man das nicht in den bootloader (usb) integrieren, dann reicht es die kernel module (*.ko) zu bauen und man kopiert sie sich nach /lib/modules/ (und passt die /etc/rc.modules an), die "integration" ist also easy zwei lösungen, zum einen gibt es in winscp eine option so das nach der anmeldung automatisch sudo benutzt wird oder du meldest dich als admin über ssh an, machst ein "sudo -i" und setzt das passwort für den user root beide lösungen werden hier im forum erklärt (englisch), die forum suche hilft bei bedarf

thats also a solution (an a waste of 6 good ports) the bootloader has kernel modules (drivers) as long as it has the same kernel version it will work as 6.1 use a new kernel version you can only have 6.0.2 Update xx (11 at the moment) with you loader (1.01) dsm shows what inside a real 3615/3617, just a fake "picture", has nothing to to with the hardware linux in the background is using, when you check the logs you will see that processor and ram are recognised and used

kernel modules/drivers are specifically compiled for a kernel (-versions) and even distributions it's not like windows where you can download a driver somewhere and just put it in so don't take any *.ko file, stick it in and expect it to work if you haven't build the *.ko yourself or don't know exactly where it came from, expect it to fail I'm no expert but as there is no how-to here in the forum - lets start one hopefully other will correct and help refine or take over and rewrite it some steps are made in windows (osfmount) but will also possible in the chroot environment on linux basic knowledge about using a linux console and command-line tools (or midnight commander) is needed, if you never used this you should not start with this how-to, choose something easier or invite someone who is able to help (do a workshop) doing all this from scratch will take at least 1-2 hours, in most cases (re-read, google, try, google, try again, ...) much longer, maybe plan a weekend of text-adventure fun edit: i think it also will do for 6.0.2 and loader 1.01 (not tested), kernel sources are available: https://sourceforge.net/projects/dsgpl/files/Synology%20NAS%20GPL%20Source/8451branch/bromolow-source/linux-3.10.x.txz/download, extra.lzma is a little differently placed (boot.img\image\DS3615xs\) but the steps will be the same 1. building the kernel module (driver) 1.1 what driver/module i need you will have to find out (google) what the name of the driver/module is that your hardware needs or you will have to know where to find the rigt option in the menu-system of the kernel when configuring it example: nForce 630 chipset with RTL8211E, you might expect it to be a realtek driver like rtl*.ko but it's not its "forcedeth.ko" because the RTL8211 is not a fully working PCIe Network Chip in some cases you might be forced to find out by booting a linux distribution and look in /var/log/, use lspci or other tools it also helps if the hardware provider has already compiled packages for specific distributions like redhat, you can look inside these packages for *.ko files you also can look in the .config file of the kernel (more below) with a text editor to find a section where the module is mentioned, this will also give you a hint where to find it in the menu-system when configuring the kernel 1.2 you need the kernel source in the case of synology that seemed sometimes difficult but at the moment there is kernel source for dsm 6.1 https://sourceforge.net/projects/dsgpl/files/Synology%20NAS%20GPL%20Source/ 15047 is the synology build version and tells you about what dsm version it is (15057 = dsm 6.1) and what kernel was used to build the modules, it !!!might!!! change in a later version so always check for what version your bootloader from usb stick is made for (jun 1.02 is for 15047) edit: dsm 6.1.1 has a new build number 15101 but seems to use the same kernel 3.10.102 as 6.1 so it should work with 6.1.1 too as i write this for ds3615xs it's bromolow as a platform, for ds3617xs it's broadwell and ds916+ is braswell (you usually see that name on the update files for a synology system like "synology_broadwell_3617xs.pat") so for ds3615xs we use this: https://sourceforge.net/projects/dsgpl/files/Synology%20NAS%20GPL%20Source/15047branch/bromolow-source/linux-3.10.x.txz/download edit: it looks like as for building the modules there is no difference for kernels modules build for 3615 and 3617 even if https://sourceforge.net/projects/dsgpl/files/Synology%20NAS%20GPL%20Source/15047branch/ has extra kernel sources for bromolow and broadwell, there are all intel x86_64, same might go for the 916+ (not testet yet), at least a evdev.ko build from 3615 kernel source did load without problems in a vm with the 3617 image 1.3 setting up a DSM 6.1 ds3615xs test environment with virtualbox (its free) or whatever works with juns loader look in the forum to find something that works, basics for virtualbox are - mac of the nic (intel pro 1000 desktop) in vm and grub.conf need to be the same - boot controller for jun's image (vmdk with reference to img file) is ide, controller for dsm disks is scsi lsi (!!!) - choose esx server option in grub menu 1.4 installing chroot put in http://packages.synocommunity.com for custom packages and change the setting that beside synology packages trusted ones are also to install install debian-chroot plugin (https://synocommunity.com/package/debian-chroot) from community section (some info's about it: https://github.com/SynoCommunity/spksrc/wiki/Debian-Chroot#configure-services) you might also install midnight commander if you are on it, makes things easier if you're not a command-line junky and more used to a graphical environment that give you clues activate ssh in dsm connect with ssh/putty to you dsm, login with user admin (and if you want to be root use "sudo -i") start the chroot with: /var/packages/debian-chroot/scripts/start-stop-status chroot after that you are inside the chroot, check with ls and you won't see "/volume1" or other sysnology specific directory's from the dsm environment, you can leave the chroot environment with "exit" later if you want now we have to update and install tools: apt-get update apt-get upgrade apt-get install locales dpkg-reconfigure locales dpkg-reconfigure tzdata apt-get install mc make gcc build-essential kernel-wedge libncurses5 libncurses5-dev libelf-dev binutils-dev kexec-tools makedumpfile fakeroot linux-kernel-devel lzma bc after that we create a directory (lets say "test") 1.5 copying kernel files and create kernel modules copy the downloaded kernel (linux-3.10.x.txz) to a share on the dsm, open a 2nd putty and copy the linux-3.10.x.txz (/volume1/...) to /volume1/@appstore/debian-chroot/var/chroottarget/test/ (that's where the "test" directory of the chroot environment is located in your real system) change back to your first putty where you are in chroot (the same way can be used to get the created files back to your shared folder on your volume1 which can be accessed from windows) change into "test", extract the linux-3.10.x.txz to a directory named "linux-3.10.x" and change into it the following copy's the kernel config file from synology to the right place for use/build cp synoconfigs/bromolow .config we make a fallback copy make ARCH="x86_64" oldconfig we start the ascii art menu and search for the missing driver to activate cursor/return are your friend in navigating, space selects, we activate the driver to an "M" so its build as module (*.ko file we need) there will be tons of descriptions how to do it, just google if needed make ARCH="x86_64" menuconfig on exit we save the configuration and with the following we make/create the modules (will take a while) make ARCH="x86_64" modules now you have to find your *.ko file (use some nice ls options, to be expanded later) usually you will have to look in /test/linux-3.10.x/drivers/scsi or block copy that file to /test for easy access when we put it in the boot image 2. modify the "synoboot.img" use osfmount (windows) to extract the "extra.lzma" (see dsm 5.2 to 6.0 guide, used there to edit grub.cfg in synoboot.img) in "extra.lzma" are the additional *.ko files and a config file where the files to be loaded on boot are named -> see forum thread "dsm 5.2 to 6.0" with howto to modify jun's loader for usb vid/pid and mac, its basically the same you just open the other partition (30MB) and extract the "extra.lzma" copy the "extra.lzma" to the share of the dsm so we have local access in a putty session on dsm in putty session #2 ("normal" session without chroot) we copy the "extra.lzma" to the "test" directory in the chroot environment go to putty session#1 (in chroot) decompress "extra.lzma" to "extra" ("extra.lzma" is a compressed cpio file) with: lzma -d extra.lzma with ls we can check that "extra.lzma" is now just ""extra" (a cpio file without the extension cpio) create a new directory, copy the "extra" there, change into it and extract it with: cpio -idv < extra delete the remaining file "extra" inside this directory we copy the *.ko file into usr/lib/modules/ and in /etc we edit the file rc.modules (easy with midnight commander, go to file, press F4, internal editor) network drivers seems to be added under EXTRA_MODULES, storage drivers under DISK_MODULES, just go to the end of the line and fill in the name of the *.ko file without the ".ko", what you add is basically a blank and the name rc.modules looks like this: EXTRA_MODULES="mii mdio libphy atl1 atl1e atl1c alx uio ipg jme skge sky2 ptp_pch pch_gbe qla3xxx qlcnic qlge netxen_nic sfc e1000 pcnet32 vmxnet3 bnx2 libcrc32c bnx2x cnic e1000e igb ixgbe r8101 r8168 r8169 tg3 usbnet ax88179_178a button evdev ohci-hcd" DISK_MODULES="BusLogic vmw_pvscsi megaraid_mm megaraid_mbox megaraid scsi_transport_spi mptbase mptscsih mptspi mptsas mptctl ata_piix megaraid_sas mpt2sas mpt3sas" EXTRA_FIRMWARES="bnx2/bnx2-rv2p-09ax-6.0.17.fw bnx2/bnx2-rv2p-09-6.0.17.fw bnx2/bnx2-rv2p-06-6.0.15.fw tigon/tg3_tso5.bin tigon/tg3_tso.bin tigon/tg3.bin" if your controller or nic needs a firmware, you add the file under usr/lib/modules/firmware/ and add the appropriate line in EXTRA_FIRMWARES, if a extra directory inside "firmware" is used it has to be added to the name, see the bnx2 firmware files after everything is in place we recreate the cpio file, re-compress it as lzma and write it in the directory above as "extra.lzma" the command is used inside the directory where we extracted the file "extra" (command line taken from https://github.com/kref/scripts, its what jun uses to create it): (find . -name modprobe && find . \! -name modprobe) | cpio --owner root:root -oH newc | lzma -8 > ../extra.lzma in putty session #2 (without the chroot) we copy "extra.lzma" from the chroot position in filesystem to the location where we can access it from windows if you still have osfmount open to the "synoboot.img" replace the "extra.lzma" with the new one, dismount and close osfmount - our new "synoboot.img" is ready to test it ps: i was asked to make a video - thats much harder to change and i'm to old for this

i dont know if anything overrides the other, to play safe they should correspond so if you define 20 internal ports the max number should be 20 (at least its what i would try) beside i would try to take all "visible" sata ports into account, so if the 6 onboard ports are active (not disabled in bios) i would count them, so its 6 + 8 + 8 = 22 usbportcfg 0011 0000 0000 0000 0000 0000 0000 0000 esataportcfg 0000 1111 1100 0000 0000 0000 0000 0000 internalportcfg 0000 0000 0011 1111 1111 1111 1111 1111 maxdisks=22 usbportcfg=‭30000000‬ esataportcfg=FC00000 internalportcfg=3FFFFF you also might define sataportmap in grub.cfg, from 1 to 688 after checking the manual of the board, there are 2 more sata ports as eSATA (Marvell 88SE621), disable them

whats the naxdisks entry? you might have to set it to 28 to match the numer of internal ports you defined so from hardware side you have 2+4+8 sata ports (or 2+8+4) i have no idea how the multiplexer is taken into account when making it "internal" synologys own solution is to only count internal (fixed number) sata ports rhey use esata with multiplexer for there own extension boxes but as i never read about someone using esata and a "normal" multiplexer i expect there is a special detection for there own brand and on all other occasins the esata port only shown one disk (that was i've seen with my esata tower befor i reconfigured it to jbod and used it as backup media) to limit the problems i would suggest you try to put the pcie cards in a way that you get 2 + 8 + 4 sata ports so the system finds them as 1st onboard, 2nd lsi, 3rd syba and on the syba you make shure you connect the intenal disk to the first two ports and the esata to the 3rd port so there in no "gap" (unused port) or "oddity" (1 port with 5 disks) in the chain of disks and the multiplexer disks are at the end of the "chain" the other way is to exactly write down the serial numbers of the disk and how they are connectet by hardware (port of every controller) plus write down on what "portnumber" the syno diskmanager in the gui sees what serial number and we start to guess whats happening and why btw. you might write a usb drive with open media vault, boot it and look what a "normal" linux/nas shows you (I'd expect there will be all disks found)

looks like there is not much that can be done, the teardown shows there is no sata port or m2 slot no good choice for nas

try https://download.xpenology.xyz

5-20? might be 4 x onboard sata? in grub.cfg you might try to change sataportmap from 1 to 88 (onboard sata disabled) if there are only 8 + 8 sata ports or 488 if there are 4 onboard ports and maxdisks=20? usbportcfg, esataportcfg, internalportcfg looks ok for 20 ports you already asked a few days ago but gave no information about your systemboard how many addition satat you have and how it is configured?

diese treiber sind dabei r8169.ko rt2800lib.ko rt2800usb.ko rt2x00lib.ko rt2x00usb.ko rtl8187.ko rtl8192c-common.ko rtl8192cu.ko rtl_usb.ko r8169.ko von jun, der rest von synology wobei man bei dem chip immer mal ließt das die leuten die r8169.ko disablen und r8168.ko statt dessen benutzen, aber der sit nicht dabei, musst also testen, theoretisch ja, praktisch, man weis es nciht https://unixblogger.com/2016/08/11/how- ... ted-guide/ das spräche dagegen das es ootb mit der 6.0.2 läuft, in jun's loader 1.01 sind r8168.ko und r8169.ko drin aber es lief in diesem fall scheinbar nicht: viewtopic.php?f=2&t=1361&p=97660&hilit=RTL8111H#p97660 aber bei dem kommentar könnte man annehmen das es geht aber nur nicht mit jumbo frames viewtopic.php?f=2&t=20216&p=82217&hilit=RTL8111H#p82217 aber zur installtion kann man ja eine andere karte reinstecken und wenn das system erst mal installiert ist wird es wesentlich einfacher einen treiber nachzuschieben (man muss ih nicht in irgendwelche boot images integrieren, sondern kann einfach den treiber nach /lib/modules kopieren und in die /etc/rc.modules schreiben und probieren bis es geht oder man keine lust mehr hat also vorausgesetzt man braucht die r8168.ko (die bei jun 10.2a/a2 aka dsm 6.1 fehlt) würde ich mal vermuten das man es mit der 6.0.2 hinkriegen könnte (betonung auf könnte) ich bastle grade an einem guide um sich die kernel treiber selber zu compilieren (und in das boot image einzubauen) so das man in kürze auch eine r8168.ko für 6.1 haben könnte

du solltest das mit den 4 sata pors evtl. jetzt beim testen berücksichtigen und sehen das es jetzt richtig läuft, wenn du später mal was nachrüsten willst stehst du wieder vor dem gleichen problem nur ist dann evtl. der druck größer und das risiko das bei fehlversuchen platten aus dem raid fallen erscheint zu groß evtl. hilft ja ein sataportmap=48 in der grub.conf?

also ich würde mal vermuten das der HA Cluster nur zwischen zwei 3615/17xs laufen wird, eine 3615/17xs mit einer 1815 wird synolgy nicht zulassen (wollen) dafür ist die 1815 zu "klein"

bei amd scheint es (auch aktuell mit der 6.1) probleme zu geben, wenn man es easy going will dann besser was von intel, ansonsten ist es eher unkritisch, es gibt aktuell zusätzlich tests mit einen ds916+ image das intel hardware transcodierung unterstützen soll, da bräuchte der prozessor wohl diese speziellen merkmale aber das ist noch nicht so ganz lauffähig und ich habe noch nichts gelesen das jemand es geschafft hätte die hardware transcodierung zu nutzen, vermutungen darüber was diese merkmale sein könnten habe ich hier mal abgegeben viewtopic.php?f=2&t=32651 aber das ist reine spekulation tage, wochen monate, hängt von einigen dingen ab, welchen schutz baut synology ein um zu verhindern das man es auf einer "fremden" hardware nutzt (und findet sich jemand der das umgeht), findet sich jemand der das boot image pflegt und extra treiber zur verfügung stellt damit auch andere hardware als die von synology verbeute geht, gibts kernel sourcen von synology, ... also eher keine vorhersagen zu dingen die es noch nicht gibt meine persönliche strategie um das auszugleichen ist ein exit plan, das kann sein das man alle daten ohnhin im backup hat und bei bedarf mit was anderem neu aufsetzt oder aktuell bei mir, ich habe das raid auf der sysnology als raid5/6 angelgt (kein shr mit asymetrischen platten) so das lvm und mdadm als standard tools reichen um das raid auf einen "normalen" linux zu mounten. getestet habe ich Open Media Vailt, das kann ich einfach als usb stick in meine kiste stecken, hochfahren und habe zugriff auf die raid5/6 datenpartitionen (instant, kein backup/restore oder irgendwas grroß installieren) wenn die updates die gleiche "nummer" haben die wiedergibt welche kernel version verwendet wird in der regel ja - es sein denn synology schiebt mal sowas wie einen zusätzlichen schutz nach der verhindern soll das fremde systeme funktionieren (man weis das ja nicht genau wie sich das in zukunft entwickelt) bei dsm 6.1 ist das im moment 15047, sollte sich diese nummer verändern dann heißt das neuer kernel und damit auch neuer bootloader notwendig (btw. 6.0 ist 8451, wer das also weis wird nicht in die falle tappen und ein update durchführen wenn er keinen neuen funktionierenden bootloader hat) sourcen mit den nummern kann man sich hier ansehen: https://sourceforge.net/projects/dsgpl/ ... %20Source/ na da passe ich mal, da sollte man bei der plex community nachsehen was die sagen und ob sich der plex dabei auf hardware transcodierung stützt (Intel Quick Sync Video), im zweifelsfall solltest du ohne diese spezialfunktion kalkulieren wenn es dafür einen extra treiber braucht dann fehlt der vermutlich im 3615/3617 image in ist evtl. nur im 916+ image dabei (aber das ist alles noch offen), man sollte sich nur auf das verlassen was es jetzt gibt, was mal kommt kann mit unter eine halbe ewigkeit dauern, manchmal fängt einer an was zu basteln und hat nach einer weile keine zeit mehr dafür oder einfach den kanal voll weil er angeflaumt wird oder alle immer nur haben wollen aber keiner was gibt (nicht geld sondern zeit, arbeit, support investieren) unter dem gesichtspunkt ist eine andere distribution die "offener" ist vieleleicht eine überlegung wert (OMV?)