Leaderboard

you do not write much about the way you migrated, your hardware, number of disks, ... so gazing int my crystal ball i'd say 12 disks is the default when updating with a big dsm update (200-300MB *.pat file) whats the onboard and added controller(s)? even with 12 disks it can happen thats disks are beyond the 12 boundary when the position on the controllers is "wrong" like when having 6 onboard and a 8 port controller its 14 ports and 2 ports will "outside" the default amount, no problem with 12 disks and the disks on the right position either you had set the default count manually higher then 12 or the drives got repositioned for some reason and are not beyond 12 did you change anything in your synoinfo.conf with the "old" version you used? beside dmesg it might be usefull to see the output of "cat /proc/mdstat"

yes, the 12.1 is named "special purpose and test" and thats not what you have in mind usually the one with highest number is the newest, when not doing so you might think about why and have a reason might be depending on you settings and partly it might be the compromise when down or upscaling with hardware, it can't be compared with a good 2pass algorithm, it also might depend on the setting synology uses when transcoding, i never looked what settings are used with video station and if it can be tweaked because i dont use that afaik there is not much you can tweak in the video station gui, its just a binary switch to have hardware transcoding or not there will be no difference with 12.1 and 13.3, its always the i915 driver that comes with DSM and video station if you want to change things look into how video station calls ffmpeg to transcode the video and try to find out how to improve that, its also possible to install a newer version of ffmpeg from external by a 3rd party package

from older posts i can see some clues about you hardware and that you might use a added sata pcie card things like that are important so please add some details about the hardware you use now (added extra/extra2 ?) dmesg will give a good overview about the hardware as it lists all pcie devices and disks also maybe some lines of the log before the errors might be interesting too, its better so see more/all log activity to get a picture depending on your configuration and experience you can try to migrate to 3617 (loader 1.03b), it uses a different kernel (3.10.105) and might behave differently also running memtest from a bootable media can't hurt

might depend on the context, if booting with a empty disk not containing a DSM system its pretty normal that /dev/md0 and /dev/md1 are not present (system and swap) but if can you see that you are loading the 2nd kernel (the original dsm kernel) and booting process is fine when the kernel starts and decompresses there is a special ascii character in the upper left corner, seeing one and then nothing else means you stuck after the 1st reloader kernel (presumably injecting the fake drivers of the original hardware and maybe doing more), it should be a second character and after this there should be the normal output you (on serial consle) you usually see on a normal systems monitor console only seeing the 1st character with loader 1.03b 3615/17 will mean in most cases that the system did not boot in csm/legacy mode, it might be active in bios but only if the csm/legacy boot device is used then its starting in that mode, when using the uefi boot device then its still starting in uefi (csm is just a added option in uefi)

finally got the two 225 rpm fans (Hyperborea) up over 600 rpm by using bios, they exhaust top-back & back but had to put a diode & a splitter to slow up the two front intake fans (Gentle Typhoon), this got them down to about 900 rpms ambient is 21°C & HHD's 25°-27°C idle

https://mega.nz/folder/q80zQATS#1VAWvg4Dr0rfSnRjM5X9pQ