jumperalex

Can you inspect the contents of those .url files?

This needs to be added to the OP and/or the WIKI please

@Gog and @ tigerdoc That is great news! Thanks so much for answering, that's very helpful. Now I just need to convince my full unraid friend to do it I think I'll be able to EDIT: which makes me thinks, maybe we should start a matching service for people to agree to share storage backups

Barakthecat, how is this still working out for you. I'm interested in setting this up with a buddy but wanted to get more details. Basically just how hard was it? Any tips / tricks? I'm assuming you need static IPs? or does crashplan.com facilitate that even in the free version? Thanks in advance.

I'm about to vote NO, because I don't use them, but I like this idea because it solves one of my very recent conundrums. I've found myself doing what others have said, forcing shares to specific a specific drive. The problem is, I hate that. It makes me feel limited in a way that I specifically choose unRaid to avoid. CacheDir solves some of the problems spin-up groups solves, but not all, so I was forced to put some of my shares (like acronis backup which would time out) onto the same drive. But those backups are my biggest growth consumers of data and I'd like to avoid being stuck on a single drive. So, while I am voting NO right now, I have actually considered implementing spin-up groups just this very weekend.

Now we need an iperf docker to test virtual performance ?

It depends, on what else the drive is doing. For example if you are using the cache drive as your temp storage and you have files being downloaded, multiple plex streams, mover running etch then you can get stuttering. If nothing else is going then you are correct that you want notice the difference. I would like to use ram but unfortunately do not have enough memory. That is indeed a very valid point. I do forget my server is fairly single function at a time use. But I hope it would take a lot to really cause tmp-storage related studdering.

You're right ... it is rediculous ;-) OK I mean i understand the thinking, but seriously, there is enough data out there to show it would take you YEARS to even come close to wearing out the drive. You'll want to upgrade before then.

I've gotta say ... the "lag" seen from storing to disk vice RAM is, or should be, inconsequential. Most spinners can write a transcoded stream to platter as fast as the CPU can generate it. That is, unless you're server is on the Top-100 list of world super computers ;-) And if not "as fast" as the CPU can push it, then at least "fast enough" so it wouldn't cause stuttering or overly prolong the time till Plex throttles back after its buffered what it considers enough. I mean really, in most any modern hardware combination I can imagine, the transcode stream storage location speed is not the bottle neck, it is the cpu doing the transcoding. I use my SSD for tmp storage and when transcoding a full-rate blueray rip my 8-core AMD is pegged (until it throttles) and certainly isn't waiting for the stream to write to disk.

Obligatory xkcd post http://xkcd.com/927/?cmpid=pscau

Mind sharing while we wait

Its a plugin, so it should install just like any other plugin. go to the plugin install tab/section and use the url in OP.

Now that's a reason I can get behind. I personally don't have that concern, but I can surely see others might. Of course. As with all things it is a question of degrees and use case. I can see the benefits, I just don't know that I'd agree they are very big. The same can be said for the down side. Most people probably won't run into problems with enough ram / few enough streams. Of course "enough" ram is relative depending on how many of those other functions, which might have i/o contention, they are running and how ram intensive they are. I'm really not trying to be completely contrary. I think it is great that you've presented the option and there are surely valid use cases. My nit pick is only that SSD endurance statistically isn't really one of them. Yes they wear out, but they do it at a rate so as to not matter when you are looking at even a high use case giving 20 years of endurance. Cut it in half, or even a quarter and you're still looking at a practical useful life beyond how long most of us will keep these drives before upgrading. Ok I don't want to beat a dead horse so I'll bow out until I have something else useful to add to the conversation. Again, thank for the attention to Plex, no matter what I DO appreciate that fact.

Thank you. There's so much FUD about SSD wear that I see all sorts of goofy workarounds in lots of places. Your write up was quite succinct. I think the biggest driver of that is confirmation bias. People forgetting that stuff fails early. They hear about, or experience, an SSD failure and it validates their feelings that SSDs must be treated with kid gloves. But an HDD fails and they call it what it is; poor QC, poor shipping, dumb luck whatever. Sure there were some models known for having problems [cough] OCZ [cough] but even those were over blown anecdotes versus actual data. They were also usually failures due to poor firmware and not wear of the actual chips. In any case, it doesn't hurt to have options so I can't argue with that.

Yeah that was just one link from that search query. Others, like yours, had success though they generally admitted to not finding much benefit (usually related to stream initiation speed which was their goal). Its not a horrible idea, and you are right flash does eventually wear out. I just don't know that it is enough to matter or to drive change absent other benefits. Change for change sake and all that [shrug]. For sure, I'm glad to see you posting the method, regardless of use case, because it means Limetech is "on it" with regards to plex archdraft: if you look at the link / search term I posted you'll see that it does indeed apply as an alternative method for general linux install. You'll also see discussions about using ramfs vs tmpfs (iirc) and the possibility of rollover into swap if you run out of ram etc etc. That means you need to have swap of course; I do not but I also am not planning to change transcoding to ram right now as can probably tell. StevenD: can you characterize the memory usage with those three streams? Keep in mind you need to let them run to completion to get the full story. Plex does not discard .ts files until the stream is stopped. So usage will grow and grow until that point.

The age old dependancey problem. :'(

hmmm an interesting think piece. I can certainly see the benefits in some cases, but I would disagree that SSD wear is of any real concern. By your own stats you're only looking at writing 430mb to the SSD. I don't know how long that video is, so I started from your 12mbps value (a reasonable, but even high one) and turned that into 129,600 MB/day or 127GB/day if you were to run a single stream for 24 hours non-stop. Per this article http://techreport.com/review/27062/the-ssd-endurance-experiment-only-two-remain-after-1-5pb it is reasonable to expect ~ 1PB of writes before seeing the start of errors (some drives a bit less, some drives MUCC more). But based on 1PB = 104,8576GB that means we can push a 127GB stream, non-stop, for 8256 days, or 22.6 years. I mean sure, there are other write operations going on our SSD's but I think it is fair to say even if we doubled, or tripled our daily SSD write throughput we're still safe from hitting the endurance limits. My real concern with transcoding to RAM is that pushing three or four simultaneous transcoded streams might stretch the memory limits of some people, though it is unlikely for most. I will add that even in the Plex forums there are discussions about dealing with /tmp (iirc?) writing to ram instead of disc and being a problem. This is just the first link I found in a google search of "plex /tmp ram" https://forums.plex.tv/index.php/topic/119669-issues-with-tmp-on-ram/

I try ... very little ... but I try

IM too lazy to do the work, so imagine a suggestion that is an acronym which breaks out to something like, A Name For All Those Having No Sense Of Humor And Taking Life Too Seriously

Hmmm working for me. Which is to say... It works... So what is different?

You know there is gimp for Windows right? Not try8ng to b3 checky, just letting you know there are free options available for Windows

Stale, old, previous, outdated, whatever you want to call it. So long as there is an EASY way to revert, from the webgui, is all I think we want.

What do we do when, not if, there is a bug in the updated plug-in and we need to roll-back to a working version? Or is that what you mean by forget/ignore? If so, what do you mean by "forget/ignore?

Another thumbs up for Checksum. Go ahead and look into md5deep but I can tell you right now (and probably repeating the threads you read and my own posts) md5deep does not have all the built in functions that Checksum does. It generates and validates hases, that is all. It will not append new hashes (vs. regenerating the entire set of hashes), delete hashes of removed files, nor update hashes of changed files (vs just adding a new hash to the list leaving an orphaned hash). You can certainly script all that, but that is what Checksum does for you. I've pinged Corz to encourage him to re-attack the linux version of the checksum. It is missing a lot of functionality because he doesn't use it personally anymore. That said, the linux version can help you generate that initial set of hashes vice moving everything over your network for windows to generate. It is indeed a good bit faster. Then use the windows version for later management (synchronization) where only new files must move over the network. You can also use the linux version for a faster disaster check (i.e. after a parity fail). Finally ... if I get the big, or if you're so inclined, you could create a docker (or VM) with wine and checksum installed and then you can operate it all on unraid using VNC or RDS.

?!?!?! Wait what? I mean people have dealt with this problem before? And have come up with reasonable solutions? Sorry this theme has come up a bunch lately IRL so I was just amused. Good find!!