s.Oliver

hmm... just tried safari with the black theme, but it rendered same as firefox. well, well.

ah, i see. i use the black theme (but i tried all others and never saw this "line" effect). hmm...?

what the hell were you doing at that time? pretty big numbers on each core. and how to set the display of the core usage to these small line bars?

what's your use case? why the need for crazy read speeds (which deeply depend on how well in continues blocks they have been written before)? ZFS as the worlds safest file system uses only software and needs to have direct hardware access to the drives (so no RAID controller in between). well, i experienced already problems with RAID controllers (mostly in RAID enclosures), but anyway, whenever possible i don't go for hardware RAID x anymore. and well, in the worst cases of all cases, where more drives die as your RAID config can deal with – in unRAIDs case all other drives have their data intact, because all of them have their regular file system (xfs), which can be read from any linux. unRAID has it's disadvantages too, no doubt. it's not meant to be an ultrafast NAS/RAID in terms of disk throughput. but it can be an ultra cool NAS, with a twist. you can tune on different areas (like using cache drives), you can passthrough independent drives (outside the array) to VMs, etc. alot of stuff which keeps this solution ultra flexible. adding drives of different sizes to the array and more. and it can keep heat and energy usage low, because of it's dont't use, don't spin approach (but you decide, don't want to wait on a drive which needs to spin up to access files, ok, don't let it spin down – it's just a setting, per disk if you want). let's think of an RAID controller failure – now you have a pretty hard time ahead (worst case, you can't get the same card and the new one can't read the RAID signature from your drives, oops). so, think about a minute, what you want to do with your rig. you want to game on it – you can with unRAID (me and friends do it). you want to use it as a daily mainstream workstation, you can. having stuff like a plex-server, tv-recorder or both and more – you can. no need to have that 8 drive hardware based RAID 6 for that. buy one good SSD or NVMe as cache drive and your set. and whenever you need to move to new hardware, it's super easy with unRAID – take your USB stick, plug your disks to your SATA ports, or HBA card and boot from USB. there's no such thing as will it recognize my RAID 6 from the previous controller card, or whatever. i've done it several times, it's too cool how easy that is. and btw. the less drives do spin, the quieter your rig gets. so 8 drives all time vs. 0 drive(s) in best case (example: Windows VM with GPU passthrough in gaming session). what do you want to do with it?

ok, meanwhile i switched to unRAID as native boot OS (so i've all virtualization features available). but, if you don't need them inside unRAID – because you do them on Proxmox – then i probably would go again the route i've taken back then. there are a few things to think about: a) using one of the most cool features of unRAID is, being not a RAID x with all disks spinning all the time – see at the name "un" & "RAID" – which leads to the necessity, that unRAID has the only hand on these disks (and/or the controller where they are connected to) which need to be spun down. passing disks via PVE's into any VM (also unRAID) doesn't let it spin down these disks, because PVE never spins them down on it's own. so i passed through a whole host adapter with all disks connected to it, which should be only available in the unRAID universe. and so all features related to these disks worked as expected. b) plug-ins / dockers they worked inside unRAID as expected (well, at least all stuff which i tested, but back then, i hadn't got any hardware access from dockers like for example a TV card for TVHeadend). but i would expect them to work, because if they are (hardware)-passed through like the HBA then why not. the only additional layer of (maybe) problems could arise because of the bootloader (plopkexec) in front of unRAIDs kernel – well, it worked perfectly with my HBA, YMMV. c) PVE on the PVE side of things you can do whatever you like (because all disks related to unRAID are/and should be passed through via hardware into the VM). so go ahead with ZFS (if you got enough RAM) or any other kind of RAID which is supported. d) bootloader vs. boot image Proxmox doesn't boot a VM from a USB-stick directly (which is unRAIDs way and it needs this USB sticks UUID for verifying your license anyway). the bootloader approach (plopkexec) has the advantage, that the unRAID VM will eventually be booted from the USB stick (PVE boots the bootloader and that in turn loads unRAID from the USB stick). and because of this, unRAID sees no difference in it's boot device and all operations are done like traditionally when unRAID booted natively from this USB stick (all updates, changes, etc. are written directly to the USB stick and are available with the next boot). doing a VM disk image approach works too (i read back then about it), but has the disadvantage that people needed to manually copy changes made to the VM disk image back to the USB stick, before booting again. i would choose Proxmox again, over any other hypervisor. alright, hope this helps in decision making.

not using this docker, but seeing the same behavior with unRAID, whenever (especially) write access into the array is starting AND the destination drives are spun down (so they need to get online/spun up) and this delays other parts on unRAID – especially all tasks, which are time sensitiv (i.e. had time outs in other dockers because of this). i would guess this is related to the virtual file system, which unRAID uses, to manage the whole array (all drives) as one big file system. probably a kind of locking mechanism. often it helps, to manually spin up the destination drive(s) [incl. parity], before any write operations start.

hmm... maybe there's still a problem with wrong authentication method used by unRAID. before i recognized that, my setup looked like: email-server was not using SSL/TLS and allowed a bunch of authentication methods, like CRAM-MD5, LOGIN, Kerberos… after i saw these errors, the setup had changed to this: email-server was setup to accept TLS, but also non-TLS connections, but i disabled the LOGIN authentication. nothing else changed (same account, same passwords). but, because of the now disabled LOGIN authentication method, unRAID server yells "Server didn't like our AUTH LOGIN (504 Authentication method not enabled)" – yeah, right, because i configured you to use CRAM-MD5. so it was using all the time the "LOGIN" authentication method, despite me setting it to use CRAM-MD5. i've used the "Custom" preset, because i run my own email-server (postfix). i run this server for years and it cares about quite alot of domains/users. everthing works for everybody, only unRAID seems to misbehave here – it simply doesn't use the choosen authentication method. the email-server log, when unRAID tries to send email (or me hitting the "Test"-button). Creating SSL connection to host SSL connection using DHE-RSA-AES256-SHA Server didn't like our AUTH LOGIN (504 Authentication method not enabled)

thx. didn't help either. just bought myself the breaking bad box and can't rip season four and five (now tested with 1.12.0 and latest 1.12.2). then tried v1.12.2 on mac (with an ext. slim-drive) and there it worked.

@TheClaus how did you tag the docker to receive the v1.12.0 version?

well, well, solved. the SSD was connected to an LSI controller. changed to int. SATA controller and it's getting it's trim command fine.

@bonienl ideas for improvement 1) option to choose to run the trim command after the mover has finished instead of running it at a static time via the cron schedule, run it automatically after the mover job is finished. in my case the biggest delete operations are almost always occurring when the mover deletes the copied data from the cache SSD/NVMe. or even better: add it as an optional checkbox in the 'Scheduler' preferences, which could read like: "Automatically run after the 'Mover' has finished" so we have best of both worlds – cron style fixed time (can be disabled if then not needed anymore) and automatic style after the mover operation. 2) make it possible to choose, which devices should get trimmed in combination would make a super flexible solution (for example: cache gets trimmed automatically after mover finished, but UD mounted only via cron's call) but i know, that asks for quite some programming work. thx. alot for your solutions.

i know, exactly this i'll do on next possible occasion. probably one of those is connected to an LSI controller.

yes, i do see those others as well getting trimmed. but i've got a assumption... wasn't there talk about awhile ago (or maybe really long ago) which controllers did/didn't support trim commands? these two same SSDs are for sure not connected to the same controller. but i can't physically check right now, which drive is connected to which controller; will do asap. is there any CLI command, which lists devices according to the used controller?

@bonienl Dynamix SSD TRIM Plug-In Problem hi bonienl, temporarily replaced my NVMe cache device (system stability problems) with a regular Samsung SSD 850 EVO and now your Dynamix SSD TRIM doesn't trim it. maybe your plug-in gets confused, because i've the exact same model/type SSD once more installed and used as UD disk, which gets trimmed. i could imagine your plug-in trims the first found disk and then goes on to other devices (with different name), no? my system is up for 3 days, and in the logs i see the trim gets executed, but never for the cache SSD; the UD SSD gets trimmed every time.

additional informations to my post/question from above (5 above this one) : when i wrote about cpu usage, i was reading them from the dashboard view (which i have to add, is pretty damn correct here). but today i had top running in the terminal, while i started another rip and was rubbing my eyes – there i saw only 2 makemkv processes which in summary/averaged consumed 'only' 27% – and that seems pretty reasonable to me. hmm… but as soon as the ripping is finished, the dashboard cpu display plums down to the usual value. head-scratching here. @saarg maybe you can have an eye on top as well when you find time to do a test. thx.

perfect, that gives us maybe a little bit of an insight.

pure rips, no conversion or whatsoever.

hey guys! just updated to unRAID 6.5.1 and did a few rips from newly bought discs. not sure, if this ever has been this way before (on version 6.4.1 and older), but looking at the cpu stats while a rip was running, made me ask myself: was this docker ever using this amount of cpu time? i observed, that it added around 70-80% of load to (only) the first core (#0) of my cpu (it's normaly around 7-10%) – xeon e5-1650 at 3.5 GHz 6-core / 12-threads. probably i would remember seeing such a load increase, but can't help it; not sure anymore. i would have tested it (on 6.4.1), but it's my only unRAID box and is running in production-mode most of the time – so it takes some time to find a free testing time slot. i tried @saarg 's MakeMKV RDP docker as well, same outcome. do you guys see the same? and this is no complaint btw., only an observation. thx, alot for this wonderful docker (i'm on the latest version here).

what about taking the drive out, formatting with another machine and put it back in (so no old structures, partitions, etc. on drive).?

JFYI: just updated to the latest version (as of yet – 2018.01.07a) of UD and now see this error: Warning: Invalid argument supplied for foreach() in /usr/local/emhttp/plugins/unassigned.devices/include/lib.php on line 920 Warning: Invalid argument supplied for foreach() in /usr/local/emhttp/plugins/unassigned.devices/include/lib.php on line 1099 i've no shares, etc. mounted. maybe it is assuming, that there's at least one mounted?

your HD HomeRuns stream directly to TVH, or in other words: TVH tells them to stream a channel (or several at the same time), whenever it records or wants to tune on a channel for Live TV – so no transcoding here. your clients (which receive from TVH) are the ones which define if transcoding comes into play. if you use KODI, there shouldn't be any transcoding necessary.

i see and sorry, have mixed you both guys up. good to see that the hardware transcode with intel quicksync-feature seems to work (and that software projects as plex do pick it up). but as always, it's just on pretty new cpus so not for me

alturismo, i'm using TVH extensively for recording (as docker) and you barely can tell on cpu usage if it's recording or not. all functions except transcoding are extrem low on cpu usage. transcoding uses lots of cpu in any solution (i tested emby, plex and a few other solutions). so you need to avoid it. but: TVH offers quite a few possibilities; for example you can use VLC, or KODI (with TVH Plug-In) or the iOS app to watch live-TV and all without transcoding! it's also pretty cheap to grab a small android box with KODI/TVH plug-in and have a full blown TV appliance. from an DVR solution point i wouldn't go back to any other solution (at least not on unRAID – and i wouldn't exchange unRAID for any other storage solution). you get quite a bunch of possibilities within one package and the community is great.

ya, had these good results as well. well...

i certainly won't make it in time before all the christmas days are over. but then, i'll try a shot at the devs. @saarg: please be prepared and (hopefully) find a little time to help me out, when they get back to me with questions, i can't answer but anyway, i can't imagine, that over at least 1,5 years in time this bug has stopped the full potential of TVH (for all docker installations around the world) and nobody (nor the developers for themselves) got a hold of it. but then, maybe not too much dockers are based on Alpine Linux? i got no idea, what is (if it exists in any way) the commonly used linux distribution for dockers; or let's rephrase that to: which is the most used linux distro for TVH dockers? if this doesn't show the bug, they probably don't care.