s.Oliver

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! 🙂

hey @CHBMB, tried the latest LibreELEC build 6.7.0-rc8, but it failed. i'm on a Digital Devices card (TVHeadend recognizes the tuners as: Sony CXD2854ER). might it be, that the DVB drivers are missing and so no tv-card gets recognized? it results in no /dev/dvb directory to be created and so the tvheadend docker won't start. 6.7.0-rc7 worked fine.

it definitely is and i'm already pre-clearing another big drive (with the new version) – looking pretty good here. a big, big thank you!

thx. for being open to ideas 🙂 i would vote for hourly writes. my pre-clears with newer drives take 32-40 hrs. and i don't trace the progress too often – so i wouldn't miss a time span of 30 mins. anyway.

thanks alot gfjardim for clearing things up a bit. respectfully a few notes/ideas below: my observation about the amount/count of writes is different than what you wrote. with every GUI update on the Main tab of unRAID i see a flip between the 256 Bytes and 4,x KBytes shown. the update is around every 5 secs so in average that would be around 5 KBytes written every 10 secs. = roughly 70 MB per 40 hour pre-clear. now, it might be that the GUI doesn't show real values... anyway, my concern isn't the rough amount of data written, but the continuously writing (the stick gets written to for lets say 40 hrs. without break) . from my understanding the USB sticks aren't made for that exact use case (usually you write a bunch of files, then they are maybe read again and stay for some time and after a while you delete a few, write a few and so on). i wouldn't count on that everybody does have absolute good quality sticks. and these sticks can get quite hot while in continuously use – might not help with long lasting usage. unRAID's concept is (and please correct me here) to write only absolutely necessary config changes back to the USB stick. all other stuff is in RAM. now i imagine, that you like to have this resume file for some reason. but, because of these really long pre-clear sessions couldn't it be optimized to be on a lesser often schedule? i imagine, that if for some reason the operation is stopped, it probably wouldn't be too bad to have a resume file state of half (or even a full) hour back then on the stick. so my idea would be: use temp storage (ram) location for these high frequency updates and do only copy/or write (newly) once in awhile to a (power loss safe) location on the USB stick. so it would help to dramatically reduce writes to the stick and still have the resume file safely on stick (albeit maybe – and only in case of bigger problems – not in it's latest up to date state). but would it hurt to loose maybe 30-60 min. of documented pre-clear state? and would this be the high priority case which needs to be covered? my unRAID runs pretty stable for long time periods. i only like to help to make it even better (and more safe). thanks again for your great work on this really appreciated plug-in/tool for unRAID.

nobody has seen this strange issue? i'm running on 6.7RC7 and did another test with the next drive to clear; exactly when i started the pre-clear job, these writes started immediately again. stopped the pre-clear job and so the writes to the flash drive stopped. so right now, i simply can't pre-clear anymore, without risking the health status of my flash drive. any help please?

hey there! started yesterday to preclear a new disk and after awhile i recognized that there are continuously writings to the flash drive. it is flipping between 256,0 B/s and 4,6 KB/s (sometimes up to 4,9 KB/s). toggling the display shows an already impressive number of 416870 writes (and 1269 reads). so i'm pretty confident, that these writes do come from the preclear plug-in. maybe it's writing some kind of status on and on to the flash drive? anyway, it's kinda of a killer feature edit: after the preclear was successfully completed, these writings stopped and everything is back to normal; but the counter shows an impressive 733000 writes to the usb-stick.

+1 it might help others in the future when doing the same thang! thx.

sure thing – you're welcome.

ok, seems i've found my issue why only one container worked versus the other. the one which wasn't working had not clicked the setting "Allow for updates from the Webserver" (in the preferences setting of MakeMKV). after fixing this it got enabled.

hmm... for how long you run this container already? maybe i should try to rename/delete it's appdata folder and re-run/-config the container. maybe it then would clear things out.

hey Djoss, the latest development of MakeMKV brings the LibreDrive feature. it seems, that it isn't present in your container, is that right? out of curiosity it checked that against saarg's MakeMKV-RDP container and there it is present and working. is there anything special we need to do to get it working in your container? thanks for your great container!

i know, just wanted to give my experiences back – so it may be of some help to others who are reading here. usually (within other rdp sessions i use) there's always a username/password combination as credentials used. thx. for looking it up.