boomam

This is remarkably similar to my issue, but with exFAT or FAT32.

Thanks for outlining at a high level how it works. However i will be clear on this, the argumentative attitude is not an attitude, its sticking to facts based on the information that i had. I will point out that you begin being arsey because you took mentioning something 1-2x times as worthy of acting out - two wrongs dont make a right, but do not accuse others of their attitude when yours hasn't exactly been stellar from the off either, for whatever reason. If you do not intend to help further, then that's fine, its not affecting the system operationally, i'll just leave it as a bug until a future release either fixes it, or i get a chance to look at the code myself. It's not a huge issue to me tbh. However if you are willing to put water under the bridge, within the restraints of anonymity of information provided, i am willing to provide additional details to help. Your choice.

Thanks, but i'm aware of what he asked and as mentioned, the output was provided. The 1k/used/avail was valid and correct. Beyond physically seeing the block values, knowing the output verbatim provides no useful information for further diagnosis as he is not familiar with what the drive size and usage should be, whereas i am. There is no information beyond that, and no error information either. Getting stuck on 'but i need to know the exact blocks' doesn't provide anything additional. By confirming that the values are indeed correct on that output, but are not within the GUI itself, it is in effect confirming that the lookup that is done, as per his synopsis above, is not calculating or reading this information correctly for the GUI. Moving on, whats interesting to note, and it could be anecdotal as i dont have an old backup to verify, but i could have sworn that the calculation in the GUI was correct up until early last month. I have some old screenshots of when i was demo'ing Unraid to a friend where its showing correctly. Has anything changed in the last 1-2 months in how it gets the information for the GUI? Or has it always calculated it the same way?

As a test, i reformatted the disk from exFAT to FAT32, no effect. Didn't really think there would be in all fairness.

Output was provided/described - Initial run, no such file or directory Second run, shows correct usages. There was no further information so you'll need to believe me when i say the block usage/avail/etc is correct. re: /tmp Looking at /tmp, its at 8% usage, and occasionally spikes up a little higher when i'm transcoding something. Re: Diag file What specifically are you requesting/looking to see within it? I'm never keen in providing it as despite the anonymous option, it does not obfuscate as much as i would like. Are there specific metrics you want the output from to help diagnose?

Thanks, i saw that a moment after i posted, i re-updated my post: nm - running the command as sdX as the mount point, same error. Running it as the name of the mountpoint, 'Logs', returns the correct 1k-blocks, used and available.

Neither is the attitude. Its not constructive. Two mentions is not 'over and over'. I re-illiterated it once as often people miss key bits of information and didn't want people to fixate on 'must be your USB drive'. Anyway, your second comment doesn't make sense, can you re-explain what you are getting/asking at please? ##EDIT## nm - running the command as sdX as the mount point, same error. Running it as the name of the mountpoint, 'Logs', returns the correct 1k-blocks, used and available.

"no such file or directory". To confirm, this happens with multiple-USB devices. This is not exclusive to one USB drive.

Hi, Does anyone know if there's a display bug in that causes unassigned devices that are mounted, to show its used and free amounts as wrong? For example, i have a 32Gb USB Drive attached and mounted to dump logs too, used shows 0 B, and free 4.23 MB. Doing a disk lookup in CLI shows the stats correctly however. Its not drive specific either, happens with any drive I've attached in the same way. Any ideas? Thanks!

Refreshes dont help. Not tried add folder. Folders do not come and go. Missing from both. Not tried the other 'tip' i saw come up regarding the dev console in Chrome and whatnot - nothings changed, an update shouldnt break a pre-existing config. I'll likely look into it at the weekend, but for now im just gonna remove the app. 😞 Great idea/plugin though, just needs polish. 🙂

Latest update seems to have messed up my config, only seeing one folder, whereas before there were 5-6x. Known bug? Or intended?

...appears to have fixed the CPU usage issue. 🙂

Tbh, its not just that area of Unraid with hidden/non-obvious functionality. If it was me, perhaps the installing 'dialogue' also including the change log as something to read during? Just saw the update today, re-enabled, testing...

Change logs for app updates is reasonably well hidden in unraid i've noticed. With a few people commenting in various threads on the excessive CPU usage, are you aware of any regression, or are these the first occurrences you have heard of?

Hey, Do you have a change log of what was done? I've started having CPU time issues since the plugin was updated...i think.

Good to hear

You misunderstand. It does not default to either a network type, or leave a blank box for the IP variable. Its not a case of not knowing the local subnet. In combination with the general description not defining this as a step of configuration, there will be many installs that wont work as easily as you advertise. Having the variable be a default to, or a better description, would solve this issue. This is what other container templates do. There is no 'warns you' either as a workaround as you claim. The simple fact is that the description needs a minor adjustment to take this into account. As the creator, you can choose whether to take that step or not. Thanks.

Does default to anything for me, its blank. So the USP would be the better integration for mobile clients/multiple providers? ok. I can understand that comparativly. Thanks for responding!

I have read the description/guide on your git, yes. It is not as clear as it could be. I would suggest perhaps an adjustment to the template that Unraid shows to make it very clear, like other containers. Just a suggestion Anyway, seems to work fine with a dedicated IP. What would be the advantage of this container over something like Cloudflared? Just the choice of Google vs Cloudflare out the box? or does it offer some other things too?

Is the latest DoH-Server image/template missing parts? Documentation says it binds to port 8053/TCP, yet there are no variables in the template to pass this port though. Do i need to add that manually?

I can confirm that this container is of a much lower quality/attention to detail from linuxserver.io than they usually provide. After much faffing around and seeing DB auth errors in the log, what fixed it for me was: 1. Setting the IP to be the host (standard) and specifying the port for the Db in the same variable Example: Database host (DB_HOST) = UNRAID_IP:PORT 2. Making sure that the DB password had no special characters whatsoever. Mine seemed to error with ANY i picked. What a faff!

Running off a SSD cache, or HDD?

Not trolling at all. Just correcting the description of how ports works for others, as the statement at a purely technical level, was not accurate. You are correct however in that unique IPs gives you the ability to not have custom ports remembered, but its kinda pro/con sort of situation. Remember IP vs remember port. I would guess most people would just bookmark or go-to the main docker page regardless, so its somewhat moot, its a preference thing. Re: the variables on lancache - Not sure i agree, that's only defining what happens when you set 'true'. Not about what the default is, which is the important part. The devil is in the detail But i wouldn't worry about that one, at this point it doesn't appear that anyone truly knows, so i'm hoping the original container creator can chime in to clarify verbatim.

The documentation on the container is not exact enough to specify if something needs to be true or false on its variable, hence why i am asking. It is not uncommon, especially for OSS/similar containers/software's to operate with double negatives. Definition of default is key for understanding. So instead of assuming, where i have seen the documentation lacking, i have asked the question in the relevant support thread on this forum. Specifically, if the variable points out 'set to true to disable', does that mean we need to set it to 'false' to explicitly set it to enable? Your response was pointed out as you did not appear to have read what i had originally outlined, or perhaps misunderstood, but the end result is the same - the difference is that i have pointed it out to help move the conversation along, but you took it the wrong way. Moving on - A few others at the moment appear to have somewhat similar 'issues', including outside of this forum, as i have had a little time to loop back to this, i'm not entirely certain that everything is caching right now. With several PC's on the internal LAN, all with a variety of the supported services and platforms, yet the cached amount seems to be pretty low (<7Gb). Compared to the previous steamcache-bundle, which always hovered in the 15-20Gb range for me, this to me points at perhaps either a mis-configuration based on default settings, or an inherent flaw with the container perhaps? If anyone who has familiarity with how the container has been put together can help clarify the documentation/my questions on the true/false variables, then it would help ascertain whether the issue is an inherent fault, or perhaps a DNS routing issue (unlikely with such a simple setup, but stranger things have happened).

Not correct actually. As long as the ports & layer protocols are different and non of the containers are using things like net_admin, then all of them can use the same IP. However in the case of a DNS lookup, technically, you just need the relevant DNS ports, however generally speaking its better to dedicate it to its own IP to help segment ports off, and prevent issues with potential port scans on a DNS IP from uncovering other services. In the example screenshot given, as there are two containers trying to use DNS/53 (a typically dual protocol TCP/UDP service), then yes, separate IP's is recommended.