s.Oliver

@pwm you're certainly right here, but the poster used @Warrentheo tip to completely erase/wipe the drive and re-do his tests. same outcome.

it doesn't seem to be network speed related. @hammondses states, that he achieves full 10gbe speed, when using a ram-disk on unRAIDs side as destination for the writes. drops to lower speed occur, when the destination is a cache only share. this would indicate, that somewhere in between the receiving I/O buffers (unRAID) and the actual writes to the share, data can't be moved fast enough, so it drops down in speed. interesting would be, if we have others here with this combination of hardware to test: fast NVMe drive (as cache) and 10gbe network speed between all parties who transfer data (client machine to unRAID server). i've got a NVMe drive (but actually because of system freezes not as cache active) but no 10gbe network infrastructure. so i can't test, sorry. but while the NVMe was active as cache, i've seen some read/write operation at maximum speed from/to it (but that was inside the unRAID box so i would guess only between ram <> NVMe disk).

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.

my suggestion for pre v6.4 unRAIDs would be, to go first to 6.4 or 6.4.1. after having verified all is running like expected, do the jump to 6.5.1

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).

too early to say (just up for a few hours). i had initially the same errors as we talked before (back on 6.5.0RCx); and still while have these recordings running, i changed 2 parameters for the tuners (energy save to yes, and discard bytes at the beginning to 0 [before 1024]) and after they were finished and the next recordings started i haven't seen these (same) errors again. anyway, now i see these from time to time: linuxdvb: Unable to provide BER value. linuxdvb: Unhandled ERROR_BLOCK_COUNT scale: 0 linuxdvb: Unable to provide UNC value. i need to observe for a longer time period and will report back to your thread. thx.

updated from 6.4.1 -> 6.5.1. system booted up, recognized all parity/data/cache slots correctly, started the array (without [forced]parity check like a few reported here). Network with 2x 1 GBit bonded ethernet links works as expected (no modifications necessary) Dockers (even with some of them manually configured IPs) work as expected VMs (even with hardware passthrough of GFx) work as expected – and no more call traces in the log congratulation to the new release (and so far without problems here*). and a big thanks goes out to all who help constantly to make it better. * this note is only for those of you with tv-cards from digital devices: the included driver version 1.2.2 in the LibreELEC build (thankfully provided by @CHBMB) does show some quirks here and forces me probably back to an v6.4.1 [again a special build and effort of @CHBMB] with older drivers, but no such problems).

are you happy with it's stability? do you have VMs running on it; and maybe with passthrough active (liek GPUs)? thx.

thx. for your help here, will try it out, as soon as i got a few hours time to do so.

hey there. seems, that you all got CrushFTP as a docker running. am i right, that there's no unRAID template available and you installed it via search from DockerHub? and if so, which author you chose and what environment/path variables are necessary for successful setup? thx. for help.

@CHBMB – here my update on LibreELEC build & Digital Devices TV-Card it seems that with every beginning of a reording i see a mixture out of these errors in the TVH docker: 2018-03-14 20:11:30.052 [WARNING] linuxdvb: Unable to provide BER value. 2018-03-14 20:11:30.260 [WARNING] TS: DVB-C Network/130MHz/Channel Name Transport error indicator (total 1) 2018-03-14 20:12:00.051 [WARNING] linuxdvb: Unable to provide BER value. 2018-03-14 20:12:00.051 [WARNING] linuxdvb: Unhandled ERROR_BLOCK_COUNT scale: 0 2018-03-14 20:12:00.051 [WARNING] linuxdvb: Unable to provide UNC value. 2018-03-14 20:12:00.053 [WARNING] linuxdvb: Unable to provide BER value. 2018-03-14 20:12:00.054 [WARNING] linuxdvb: Unhandled ERROR_BLOCK_COUNT scale: 0 2018-03-14 20:12:00.054 [WARNING] linuxdvb: Unable to provide UNC value. 2018-03-14 20:12:00.143 [WARNING] TS: DVB-C Network/530MHz/Channel Name Transport error indicator (total 1) 2018-03-14 20:12:00.161 [WARNING] TS: DVB-C Network/522MHz/Channel Name Transport error indicator (total 1) 2018-03-14 20:12:00.224 [WARNING] tbl-pass: pass-eit: -: invalid checksum (len 109, errors 1) 2018-03-14 20:12:00.262 [WARNING] tbl-pass: pass-eit: -: invalid checksum (len 3638, errors 1) can't check the files (they just started recording) but i guess these errors at the beginning aren't (actually) serious, but because of TVH listing them in the list of running recordings (and so later in finished recordings) i can't tell a day or two later, if these errors were serious or not (because it can be, that additional errors occur while they get recorded). so in comparison to the github version it's a definite drawback for me. i've lots of recordings running, so it arises as a nightmare when i'm about to decide which to keep and which are worth of being treated any further (removing ads, etc.) and put them into the plex library. if i might ask for one more 6.5.x Github build? please. i'm willing to do testing with LibreELEC from time to time, but now, it's not the standard i was enjoying.

see here:

definitely related to usb/serial devices, so something for @saarg in future releases of kernels, to watch out for.

i've spotted this line in the unRAID log: Mar 14 14:53:57 unRAID kernel: ftdi_sio ttyUSB0: use of SPD flags is deprecated think it's new since v6.5 (probably cause of newer kernel drivers and their requirements?).

yeah, i do see occasional use for OSCam on unRAID without DVB-Build.

before as: crw-rw---- 1 root dialout 188, 0 Mar 14 12:26 ttyUSB0 i can confirm now, that chmod'ding to 777 was enough, to get it going. i left the user:group at the display values (root:dialout). THANKS! @CHBMB couldn't you extract from an installed oscam docker it's used --extra parameters and use these settings to do the necessary correction on the permissions? or let's have a configureable option in the DVB-Plugin to specify it manually. no?

Command: root@localhost:# /usr/local/emhttp/plugins/dynamix.docker.manager/scripts/docker run -d --name='oscam' --net='host' -e TZ="Europe/Berlin" -e HOST_OS="unRAID" -e 'PGID'='100' -e 'PUID'='99' -e 'TCP_PORT_8888'='8888' -e 'TCP_PORT_10000'='10000' -e 'TCP_PORT_10001'='10001' -e 'TCP_PORT_10002'='10002' -v '/mnt/user/appdata/oscam':'/config':'rw' --device=/dev/ttyUSB0 'linuxserver/oscam:66'

hey CHBMB, thx. for looking into it. output of lsusb: root@unRAID:/dev# ls -la /dev/bus/usb/ drwxr-xr-x 6 root root 120 Mar 14 12:26 ./ drwxr-xr-x 3 root root 60 Mar 14 12:26 ../ drwxr-xr-x 2 root root 80 Mar 14 12:26 001/ drwxr-xr-x 2 root root 80 Mar 14 12:26 002/ drwxr-xr-x 2 root root 140 Mar 14 12:26 003/ drwxr-xr-x 2 root root 80 Mar 14 12:26 004/ hmm… how to lookup the complete docker run command from an installed docker?

have an Digital Device Card running with the LibreELEC build. do you use a docker which access an USB device like a card reader?

didn't need to do this. so it seems different for diff. users (you were maybe on RC before?).

Updated from 6.4.1 and it seems to good at first sight – besides: Docker seems to have seen a change in how access to USB devices is granted. got a docker running which accesses a usb-card reader and after the update to v6.5 it spits out access denied errors like "ERROR: Opening device /dev/bus/usb/003/003 (errno=13 Permission denied)". tried already to give "Privileged" rights to the docker = no change. tried to change from "/dev/ttyUSB0" to "/dev/bus/usb/003/003" but same access denied errors. need help here. please. thx.

hey @CHBMB just installed 6.5 LibreELEC and ran immediately into a problem: OSCam docker doesn't see usb-reader. worked always flawlessly, this time errors with "Opening device /dev/bus/usb/003/003 (errno=13 Permission denied)" or ".../dev/ttyUSB0..." (same access denied). i compared the permissions for the device, they seems same as before. i tried to set docker as "Privilleged" no joy also. need help, please.

@CHBMB sorry, been overly busy with day-to-day workload; couldn't respond earlier. i'll test the final v6.5 LibreELEC build with my new Digital Devices Tuner card and report back. last test i did showed lots of errors like these: [WARNING] linuxdvb: Unable to provide BER value. [WARNING] linuxdvb: Unhandled ERROR_BLOCK_COUNT scale: 0 [WARNING] linuxdvb: Unable to provide UNC value. [WARNING] tbl-pass: pass-eit: -: invalid checksum (len 785, errors 1) [WARNING] tbl-pass: pass-sdt: -: invalid checksum (len 388, errors 1) [WARNING] tbl-pass: pass-eit: -: invalid checksum (len 18, errors 1) although shown as warning in the TVH log, they were shown as errors to the responding (running at that time) recordings. i hadn't got the time back then, to investigate, if these errors would've been discoverable in the recorded shows, but because of the massive amount (like 15-30 errors per recording) i switched back immediately to the github build – and had no errors at all. and i need to add, that this github build (6.4.1) with that new DD card outperforms the previous TBS card (which showed a few errors from time to time compared to no errors with the DD card). hopefully the v6.5 LibreELEC build (and the associated drivers) will work like the ones right now.