s.Oliver

need to correct my last post: PLEX docker (media scan background task) did crash now once. so possible that this isn't related to the kernel, or whatever.

maybe you don't have to, if limetech can identify the problem and fix it.

funny thing, now another problem has disappeared (after going back to 6.6.7), which brought some serious brain smashing: PLEX (docker) has some background tasks running (usually in the night), one is the media scanning job. this one regularly crashed and alot of people had this problem too and tried to find a solution. now after some days of up time with 6.6.7 i haven't seen one crash – YEAH! in the nights i've some big backup jobs running, which are writing into the array. so i would guess, that PLEX has timed out on accessing data in the array (albeit, i just reads files).

well, couldn't stand it anymore – so back to 6.6.7 and all is back to normal, expected behavior. though, missing stuff from 6.7, so i'll hope they can identify/fix the problem really soon.

i can add to this and it's a major drop-down for unRAID going from 6.7 onward. before i was reluctant to post about it, cause of too less tests done to be 100% sure of not having some settings somewhere changed… but now, i'm sure. today i upgraded one more unRAID server from 6.6x to 6.7.2 and do see the exact same behavior! so i do have 2 machines here, which haven't had a single change, except they were uograded to 6.7.x (meanwhile all on 6.7.2). in my book, it doesn't matter how you access the data: coming from network or locally on the server, using different machines to connect to the server… when one write into the array is ongoing, then any reads (even from cache SSDs/NVMe') – even the ones coming from data or cache devices which aren't written to – are super slow. also whenever now a rebuild is happening, you better not want to read any file... also RAM amount doesn't change anything, nor the used controllers nor the cpu (with/without mitigation enabled/disabled). and while i can't back it by data, it seems that rebuilds are slower too. this can have severe scenarios, where some services are writing continuously data into the array (like video surveillance for example). hopefully we can find a fast fix for this, because going back to 6.6.x isn't a good option anymore. @limetech what can we do to help debugging this?

alright man thx. i'll try this once i'm ready for my new PROXMOX installation.

hmm… maybe i read the screenshots wrong... but i guess, because of no other specified bootable device (boot device 1 = cd-rom with empty 'tray', device 2 & 3 are set to nothing, or have non-bootable devices) PROXMOX is looking at it's usb devices (for this VM) and boots from it, if bootable?

you're using it this way? (no special prepared bootable image, pure unRAID usb-stick and it boots directly from that?)

well, i answered all of your questions actually when you do passthrough your hardware to unRAID (HBA, or SATA controllers, or whatever) then unRAID has full control of it's features – and yes, it spins down all HDDs, which are connected to these passthrough'ed hardware. and this includes things like hot-swap (if supported by your hardware) or other things. if done in the right way, your 2nd question could be answered with yes! unRAID see's the drives as they would be on bare metal booted hardware (because you passthrough the hardware, which your drives are connected to then). your 3rd question references to my hint using plopkexec to boot natively into your unRAID installation on a USB stick (this is needed, because the hypervisor can't boot any VM from a usb stick; so plopkexec is a super small VM on ISO and it's then boots unRAID from the USB stick in stage 2). this method allows for native unRAID setup (with your USB key), without any changes/modifications, whatsoever. and the bonus is, that you never need to think about it in the future. all changes which need to be written to the usb stick (where unRAID is installed on) are written to the stick (and not to the ISO in the other guys setup). so no worries in the future – and you could boot unRAID on bare metal (without modifications). probably soon i'll tweak my setup again to go this virtualization route – because now i need the features of Proxmox, but i can't loose my unRAID-server – so i'll redo all this on my newer rig. hope this helps for your decision making.

thx. alot for integrating my wish. now gimme some time to test/play with it will report back.

hi alturismo, haven't tested your xteve docker yet, but i guess i would need a kindly different solution anyway. so my setup uses tvheadend for aquirering tv-signal and creating the epg data (from it's own grabbers directly from the channel stream). so here i would have a need to use (the already generated) TVH EPG data for PLEX and then use xteve's magic to tune from PLEX into a TVH channel. do you see any way of achieving this?

well, i helped a friend to setup dual drive ripping... end of story was, to use this docker two times (with different names) und passthrough one drive to each. so they work as they should, both with proper speeds.

i would've joined the tester group, but haven't got an nvidia card in the server right now. 😞

not sure if this it it, but somewhen in the RC cycle there was a change so that displays got black after awhile of uptime – it was intentional as protection against burn-in (i guess, or...). catched me once, but a keypress wakes the screen.

running this time the Digital Devices Build (6.7.0-rc8) and it looks good! thanks alot @CHBMB for doing the magic! 🙂