bungee91

Something to keep in mind.. When I update my graphics drivers, this gets reverted to non MSI. I'm not certain why that is the case, but with my GT720's I've confirmed this in Windows 10. Also that tool linked a couple of posts up is a really nice way to do this as opposed to creating the registry entry manually! Hopefully we can figure out a way to force this to stay enabled even when updating drivers.

I'm very surprised you had this issue with this specific card, unless ASUS is doing something stupid with their specific BIOS. I have 3 GT720's (1 MSI, 2 reference/OEM's), tested all of them with 2 different motherboards (ASRock, and ASUS), and they work flawlessly (I have tried to make them break, they did not, and I wasn't nice to them in testing!). I have CERTAINLY had these issues with previous tested cards (5450, and G210).

Thanks, much appreciated!

Would it be possible to update the OP with a description or picture (if needed for better explanation) of the listed plugins? If not, (and I may be missing this) a link to entries in the wiki explaining them? I know that time could be better spent making plugins, however without reading through the thread some of them aren't very clear, while others are obviously self-explanatory. Something like this: Active Streams - Monitor open connections and streams. Cache Dirs - Cache directories into RAM to minimize disc spin-up for directory listings S3 Sleep - Add the S3 sleep state into UnRAID (settings include .....) System Info - Display detailed system information (not at server, is it processes, ram, components, etc...?) System Stats - So many stats your eye will get all big and funny looking... System Temp - Display CPU/MB/etc... temps within UnRAID, displayed at bottom of webGUI System AutoFan - Regulate fan speeds based on temperature, settings, disc state, etc... Schedules - Schedule things (I have no clue) System Buttons - (I believe this allows setting of actions to mappable buttons, and also one button shutdown/restart? If not please advise) Local Master - for PoC purposes I also had noticed a decent amount of replies with people confused about getting the drivers or various sensors detected for fan related or temp related issues. I know there is some info in a wiki, some talk about a newer sensors-detect script, etc... Could this be linked, or explained or something for people trying to setup those plugins? I'm more than willing to do some legwork to help and categorize things as needed, however things change so I'd hate to recommend something viable from V5 that is totally different now in V6.

Understand, and have experienced this with other setups (read: not now, not with this card), however I don't have this issue. It always outputs video, regardless of state of link, receiver on or off, VM status, etc... I noticed this more previously with AMD cards years prior, lead me to have to buy a "DVI Doctor" (kept EDID to make it look like display was always present). Fortunately those days are behind me!

The GT720 in OE needs to have MSI interrupts enabled in order to fix the "stuck" symptom with audio output. I have tested with 2 models that I have, and both needed this. You do need to enable the pass-through in 2 places, and choose the Wasapi (is that what it's called?...sorry, not at machine) one, not the direct sound. I have passed 7.1 in various formats, all worked fine. I believe this is what Jon is talking about for the addition to beta 3, but checking for this or adding the needed file to enable doesn't take much effort. Info here: I have this same problem (but this is not issue of OE, because without KVM works fine) im still try to resolve this, im tried switch OFF MSI, map EDID, setup alsa etc. - for now nothing help UPDATE: resolved !!! create file in config folder of OE .config/modprobe.d/sound.conf and put line options snd-hda-intel enable_msi=1 (This is a bit off topic, but in the same realm). I also needed to enable this for my Windows VM that I run, as I was getting a glitch every so often where "demonic" audio would happen. I haven't had this happen afterwards. I have 2 GT720's actively being used (both in Windows environments) and they are solid, no host related issues regardless of what I do in the VM.

Is anyone running active streams in 6.1 without issue? I haven't had a lot of time to pinpoint, however I believe it is causing my VMs to power off after some time. I may just be crazy, but removing it seems to have fixed my issue.

Yes, this is done automatically through using the VM manager, I don't see this referenced as needing to be done within this guide.

Exactly!

A NIC is a device that UnRAID will bind, the stub effectively tells UnRAID to leave it alone, it is not allowed to be assigned to it. This way unRAID won't put it into use, and then you can pass the device through into your requested VM. If you do not use this, it will be assigned to unRAID and not be able to be used for pass through. Basically you stub it, and then add the proper line into your XML for the device slot that is listed. There is more magic going on in the background of the vm manager, as it will silently assign that device automatically to vfio-pci (I think that's still what it uses) for use in the VM.

That's good to know, thanks (also I think you're following me.. )

I'm not sure if this is needed anymore, however I am also just guessing. For instance if I go into the share page and click compute on a share, it will show me all the drives with that share on it. If I delete that folder from a drive, and hit compute again, it is now gone and no longer listed.

Not necessarily, but not sure.. If you haven't written anything to the appdata folder since the change, I would guess it would not. As soon as you did though, it would be there. However just create a folder called appdata on the cache drive and you would then have a folder there. That mapping is for a physical mapped drive (mnt/cache/appdata) , as opposed to a user share mapping (/mnt/user/appdata). So as an example if you added a folder called "media" on disk1, it is there as soon as you make the folder. The path would be /mnt/disk1/media no "share" needs to be created as it is a path. In that example if you wanted it as a user share, you would make "media" as a user share, and then you could point to /mnt/user/media and it would find the files that are in a "media" folder at the root of any drive. No, see below.

First off, welcome! It's actually even easier than that... (give or take) No need to stop the array to change a disk share to cache only, but you will need to move the files yourself. Also, no need to fix the mapping to the container... Regardless of which disk the files are on, you can still point it to /mnt/user/appdata and if it's set to cache only, it will only be on your cache directory! So.. (1) unRAID Main > Shares > appdata : select Use cache disk: only and remove any include/exclude, it's not needed.. Cache only is cache only, apply, done. (2) Move files from disk 1 to cache drive (this can be done in multiple ways, however you ABSOLUTELY don't want to copy from a user share to disk share (or whatever way that is)). The easiest way is to just use another computer and copy the appdata folder from disk 1 to the cache drive (if in Windows, use the basic file explorer copy/paste). If you do not currently export the disk shares, click on each disk (1, and cache), set export to yes for either SMB or NFS, now use SMB or NFS from another PC to copy it to cache, and when finished delete the copy from disk 1. ----- (If you don't feel comfortable using SSH please do not, it shouldn't be needed)----- I have noticed some issues at times attempting to copy in use or permission locked files, so if that's the case and you know how to use Putty to SSH in, just type this. cp -avr /mnt/disk1/appdata /mnt/cache/appdata Once it's successfully transferred (please verify contents prior to continuing by checking your cache share for the appdata folder) rm -rvf /mnt/disk1/appdata

One more for you, and the obvious question of.... How's it going (the point of this thread, not you, however, I suppose you also... ) Avermedia A188C 06:00.0 Multimedia controller: Philips Semiconductors SAA7160 (rev 01) It is also defined as a "multimedia controller" .

Tuner Card: AverMedia M780 (Combo PCI-E) 06:00.0 Multimedia video controller: Micronas Semiconductor Holding AG nGene PCI-Express Multimedia Controller (I technically have this uninstalled from my server right now, but have this output from a previous lspci result that I had ran, I would assume it'd report the exact same under Tools -> System Devices once I install it again).

Sure thing, attached... Image built fine, just had to be patient (read: go do something else!). syslog.txt

*I just read that others are having this issue... Again likely not expected, but if you are patient it will finish building the new image. Take a look at the image size growing through the cache directory share (or wherever, slowly) and you'll know it's working and not frozen. For some reason (IDK, maybe it's normal, but I doubt it!) when I delete docker.img and recreate a new exactly the same named docker.img it takes a LONG time to create it, like hours! I had this previously happen when I had a corruption issue (ran out of space), so I deleted my 10GB one, and made a new one with the exact same name 15GB. The UI just spins, and spins, however I can see that it is still going by looking on the cache drive and seeing the image size growing. The exact same issue that I had when doing this previously (10GB to 15GB) is happening now when I deleted and recreated for the new image with the No COW image. I'd assume not normal, thought I'd chime in, see if fixable. It will eventually go, but no lie almost an hour to build a 15GB image on an SSD cache drive.

Thank you, I think the data will be preserved just fine also I just wouldn't have had a clue this happened without you mentioning it (thank you BTW!). I think for ease in regards to a learning curve I will just mount the drive in a spare PC, load a live version of Linux, and copy the data over. Unless this is not recommended, it seems pretty straight forward.

So that would be a "yes".. Dammit! Ok, will need to load the old drive outside of the array and copy my files back to the new drive. I would have left it as RFS if I would have known this to be the case, honestly I don't think this is well described in the messages on the GUI (or I am dumb, but I think I am a tad more technical than the average "noobie").

I think I then just lost ~1TB of data, so let me make sure I read this right. I had a drive red ball for a write error. Stopped array, shutdown, swapped in a new precleared drive. Added new drive to that same slot, switched the file system to XFS (figured why not, perfect time to do this), clicked the format button I really want to do this, will format the new drive to XFS and add to array. This completed, array went back to a green status, ran a parity check and all passed. So in this process did I basically lose everything that was on the previous drive, and Unraid just added the new drive with no data and rebuild parity around that? If so that is unfortunate and confusing! I still have the old drive and I am sure I can mount it outside of the array and get the data back, just had no idea that was the case.

Thank you, updated!

I'm confused... You do not "start" cache_dirs with the "-q" option. That is how you "stop" a cache_dirs process that is already running. ( the -q option has it look for a file the running process had created containing its process ID, the "-q" process then kills that original process via the ID it found.) Cache_dirs in many cases DOES create one child process per mounted disk share. (unless you supply an argument to cache_dirs to NOT perform that function) These child processes are to purposely cause the mounted devices to be detected as "busy" when you attempt to stop the array. It then allows cache-dirs to detect those "busy" file-system messages and suspend itself when you are attempting to stop the array so the array can be stopped cleanly. The major issue people have had in the 64 bit world is the ulimit is set too low for many of them to fit their directory structure in memory. You can fix that issue by simply commenting out the lines in the script that set "ulimit". (or deleting them entirely) One person reported the newer version of the shell no longer sets $SHELL as /bin/sh when invoked as /bin/bash so therefore, cache_dirs could not be started from the "go" script. To fix that, delete the lines at the top of the script as shown in "red" here: #!/bin/bash if test "$SHELL" = "/bin/sh" && test -x /bin/bash; then exec /bin/bash -c "$0" "$@" fi Joe L. I was not starting it with "-q" I was just saying that is how I was stopping it, but still seeing another running. I was starting it just by running "cache_dirs". Thanks for the input, and the fix for using it with the Go script. I will add that in to my setup soon.

Is it normal for cache_dirs to show up as 2 PID's in the "top" listing? (see pic) When I start it from telnet, I see 2 of them show up. If I kill the one I started with "-q" it still has another 1 running. I can run the -q option again and it states no cache_dirs is running. If I stop the array the other one that was running is then cleared and no longer shows up. Once I restart the array it is also still not running. However once I start it in telnet 2 of them show up with different PID's. I am using v1.6.8 Unraid 6.0b6