koala784

Members
  • Posts

    13
  • Joined

  • Last visited

Posts posted by koala784

  1. On 2/16/2022 at 7:11 AM, falconexe said:

    Interesting tidbit...

     

    Without writing to Cache in any way (array operations) for 24 hours, I seem to be hitting 300-400 MB of writes per hour, and roughly 40GB per day, with just my running dockers. I suspect most, if not all of this, is Telegraph/InfluxDB/Grafana.

     

    image.thumb.png.e0561d3261db5cee3c91fe908f1ec4ed.png

     

    For anyone else using the UUD, are you seeing similar metrics?

     

    For my SSD, I have a manufacturer's suggested lifespan of 1200 TBW. If I did nothing but run appdata stuff (and never used the Cache for array activities), my drive would last roughly 82 years at this rate. Even if I wrote 1TB a day with array activity, it would still last 3.28 years.

     

    So I guess this puts to rest the fear of wearing out an expensive SSD Cache drive because of something cool like the UUD.

     

     


    Hi, I have a lot of write on my SSD cache. I've changed it a few months ago (also a 2GB / 1200 TBW Samsung disk), so it's not an emergency yet. The write's stats was similar with the older SSD cache.

     

    This is my current SSD write's stats (day / year) :
    image.thumb.png.cb484b9afa6ecb01e289bfebd2dade99.png

     
    I also think that it seems related to the "Telegraph/InfluxDB/Grafana" stack.

    There's a lot of things that Grafana is monotoring on my system (got a custom UUD dashboard, a Plex dashboard and a Nginx dashboard).
     

    I'm far of being an expert on unRAID or Linux system, so I'm not sure how I could confirm where the culprit is.
    I think I will try for a few day to set a new InfluxDB docker container with only a SSD write stats monitoring.

    I was going crazy with it so it's "nice" to see someone else having some thoughs about this :)

    • Like 1
  2. 18 hours ago, Squid said:

    For anyone having the spinner not disappearing, or a longer than usual startup time can you enter these commands and let me know if it's fixed. 

    wget -P /tmp https://github.com/Squidly271/community.applications/raw/master/archive/community.applications-2021.10.20-x86_64-1.txz
    installpkg /tmp/community.applications-2021.10.20-x86_64-1.txz

     

    Hi, it's working correctly now, the page startup is as fast as before the new version
    Thanks !

  3. 31 minutes ago, Squid said:

    I think I know where the extended startup time and possibly the spinner not disappearing comes from.  Do you guys happen to have some containers installed that are displaying the "?" for the icon on the docker page instead of a regular icon when there should be an icon present?

     


    I had one for some months (youtube-dl-material), I removed it (not using it anymore).

    I've also removed all the orphans images that I could see on the Docker page (advanced view).

     

    But I don't see any changes.

    If the "?" icon bug is a known one, I don't know anything about it.

     

    Here's a new log file after the cleaning.

    ca_log.txt

  4. On 10/18/2021 at 1:29 PM, koala784 said:

    Hi, thanks for the new update !
    Some changes are great, others are understable, but I'm wondering : is there other people affected by a longer charging page when clicking on the "apps" page ? It takes 15 seconds to show the apps on my side.

    I've already re-install the Community Apps plugin and clean the Firefox cache.

     

    On 10/18/2021 at 1:50 PM, Squid said:

    Startup time is mostly reflected by your internet speed with one exception.  If the drive container your docker.img (or folder) happens to be spun down.

    I can't stand any PHP errors appearing within CA ever, but unfortunately the OS isn't as hardened against this time of error, and in the case of a failure of this test previously, PHP errors would appearing throughout CA (and on the DockerTab)

     

    On 10/19/2021 at 12:06 AM, koala784 said:

    My internet speed is pretty good and stable, visible on the screenshot below.
    And my docker.img is on a NVME SSD set as cache so it's not spun down, there is something else.
    Also, I've been using UnRAID for at least two years, and I've never seen the apps page being slow more than 2 seconds, before this update

    But I'm surprised no one else have reported this yet

     

    Stats.png

     

    19 hours ago, Squid said:

    OK.

     

    Update just released which allows descriptions to be on the cards (defaults to be no).  Enable it in CA Settings

    Minor performance increase in certain cases

    Rearranged debugging

     

    If you've got issues with CA not loading / the spinner never disappearing then

    • Go to Settings.  The CA settings page is now in there also (User Utilities Section)
    • Enable debugging and apply
    • Go to the apps tab.  Wait at least 120 seconds
    • Go back to Settings, CA Settings and hit Download Log.  Upload the file here.

    (Also re-added 6.8.0+ compatibility - NOT TESTED)


    Hi, I've added my log file below.

    So I've no knowledge about code and dev' (and english^^), but here is what I see on the firsts line of the log file :

     

    The historic start like this :

    2021-10-20 19:57:31  POST CALLED (defaultSortOrder)

     

    And this last "POST action" is this one :

     

    2021-10-20 19:57:32 POST RETURN (getFavourite)
     

    But then there is a delay of 12 seconds into this "POST RETURN" :

     

    2021-10-20 19:57:44 POST RETURN (get_content)

    ca_log.txt

  5. 10 hours ago, Squid said:

      

    10 hours ago, koala784 said:

    Hi, thanks for the new update !
    Some changes are great, others are understable, but I'm wondering : is there other people affected by a longer charging page when clicking on the "apps" page ? It takes 15 seconds to show the apps on my side.

    I've already re-install the Community Apps plugin and clean the Firefox cache.

     

    Startup time is mostly reflected by your internet speed with one exception.  If the drive container your docker.img (or folder) happens to be spun down.

    I can't stand any PHP errors appearing within CA ever, but unfortunately the OS isn't as hardened against this time of error, and in the case of a failure of this test previously, PHP errors would appearing throughout CA (and on the DockerTab)

    My internet speed is pretty good and stable, visible on the screenshot below.
    And my docker.img is on a NVME SSD set as cache so it's not spun down, there is something else.
    Also, I've been using UnRAID for at least two years, and I've never seen the apps page being slow more than 2 seconds, before this update

    But I'm surprised no one else have reported this yet

     

    Stats.png

  6. Hi, thanks for the new update !
    Some changes are great, others are understable, but I'm wondering : is there other people affected by a longer charging page when clicking on the "apps" page ? It takes 15 seconds to show the apps on my side.

    I've already re-install the Community Apps plugin and clean the Firefox cache.

  7. On 4/8/2021 at 7:15 PM, Andiroo2 said:

    Having issues with the SpeedtestforInfluxDB docker today.  I can't get it to load (after a year of reliable use).  Logs show this error immediately upon starting the container:

     

    
    
    Loading Configuration File config.ini
    Configuration Successfully Loaded
    Traceback (most recent call last):
    File "/src/influxspeedtest.py", line 8, in <module>
    collector.run()
    File "/src/influxspeedtest/InfluxdbSpeedtest.py", line 176, in run
    self.run_speed_test(server)
    File "/src/influxspeedtest/InfluxdbSpeedtest.py", line 121, in run_speed_test
    self.setup_speedtest(server)
    File "/src/influxspeedtest/InfluxdbSpeedtest.py", line 71, in setup_speedtest
    self.speedtest = speedtest.Speedtest()
    File "/usr/local/lib/python3.7/site-packages/speedtest.py", line 1091, in __init__
    self.get_config()
    File "/usr/local/lib/python3.7/site-packages/speedtest.py", line 1174, in get_config
    map(int, server_config['ignoreids'].split(','))
    ValueError: invalid literal for int() with base 10: ''

     

    I am on InfluxDB v1.8.  Anyone else having issue with this container?  Thanks!


    I have the same issue since a few days :

     

    Loading Configuration File config.ini
    Configuration Successfully Loaded
    2021-04-10 08:57:21,453 - INFO: Starting Speed Test For Server None
    Traceback (most recent call last):
    File "/src/influxspeedtest.py", line 8, in <module>
    collector.run()
    File "/src/influxspeedtest/InfluxdbSpeedtest.py", line 171, in run
    self.run_speed_test()
    File "/src/influxspeedtest/InfluxdbSpeedtest.py", line 119, in run_speed_test
    self.setup_speedtest(server)
    File "/src/influxspeedtest/InfluxdbSpeedtest.py", line 71, in setup_speedtest
    self.speedtest = speedtest.Speedtest()
    File "/usr/local/lib/python3.7/site-packages/speedtest.py", line 1091, in __init__
    self.get_config()
    File "/usr/local/lib/python3.7/site-packages/speedtest.py", line 1174, in get_config
    map(int, server_config['ignoreids'].split(','))
    ValueError: invalid literal for int() with base 10: ''

     

    • Like 1
  8. 35 minutes ago, testdasi said:

    This is a known bug with Deluge (see bug report below). As binhex himself said "if the plugin is not made for deluge v2 then you will be out of luck until the plugin developer updates the plugin to work with python 3.x". Binhex seems to have implemented his own fix so I think you might have no choice but to use his docker instead.

    https://github.com/binhex/arch-delugevpn/issues/66

    Ok I'm gonna go with the binhex one for now, and try to find a workaround

     

    35 minutes ago, testdasi said:

    The DNS queries within your network is not encrypted e.g. DNS between the client (192.168.1.202) and the Pihole docker (192.168.1.3).

    It's the query out of the docker to the DNS resolver (e.g. from Pihole (192.168.1.3) to google (8.8.8.8)) that is encrypted.

    Ok I understand :)

     

    Thanks for your responses ! ;)

     

    EDIT: For the Label plugin issue on Deluge, your link was helpful, there is a workaround, thanks again ;)

    image.thumb.png.77bd9c0b99644f94a28c2272c8340a2b.png

  9. I've set Pihole-DoT-DoH like this on 192.168.1.3 (br0) : 

     

    UnRAID.thumb.png.f8d04afd8ae609a0fd7513200ce17ade.png

    Pihole is accessible on 192.168.1.3, and the logs show that the DoH proxy server is started :

     

    Pihole.thumb.png.2f80f5c01a152282a68c69dd765c3d11.png

     

    Logs.png.a1e1fb1ae531e06fe4e337b569babb80.png

     

    So i've set the 192.168.1.3 adress as my only DNS server on Windows :

     

    Windows.png.42f42e9c669e6de710fab59693500389.png

     

    But when I start Wireshark and visit a website, the DNS request are still visible :

     

    Wireshark.thumb.png.e3911c02f6505fd48661e2821b0a95af.png

     

    I'm not really good yet in networking, so I think i've miss something, but I don't know really what yet...

    EDIT: UnRAID DNS is set to 1.1.1.1

  10. Hi ! First, thanks for the works on this apps ! :)

     

    I have an issue with OpenVPN HyDeSa, if I activate the "Label" plugin, the plugin is disabled when I restart OpenVPN HyDeSa.

     

    It was working with binhex-delugevpn (another Deluge version).

     

    It's pretty annoyng when using Sonarr, Radarr and Lidarr (and the 4K versions of them).

     

    Did someone else have the same issue ?

    EDIT : some screenshots :

    The web.conf file (after a restart)
    2.png

     

     

    The plugins (after a restart)

    1.png

    EDIT2: After installing AutoRemovePlus, same issue : I can setting it up, but if I restart OpenVPN HyDeSa, the plugin is disable.

    EDIT3: AutoRemovePlus seems to work now, after a restart... I think it wasn't working correctly if activate with the Label plugin in the same time ; so the only issue is with the Label plugin.

  11. On 9/5/2020 at 1:45 PM, ich777 said:

    Eventually the game developers haven't update the game itself for linux.

     

    As I said, it's updated through SteamCMD and the container doesn't need to be updated.

    Eventually you understand it if I explain what the container does:

    The container looks for SteamCMD and installs it if it isn't found

    Then the container loads up SteamCMD and SteamCMD looks if the game is installed if it isn't installed SteamCMD downloads it

    Then the container starts the server executable that is downloaded through SteamCMD

     

    If you restart the container it happens in the exact same order as described above, I hope you understand now why the container don't needs to be updated.

     

    The container runs just a script that starts SteamCMD and executes all commands through it.

     

    I hope you understand now how this works.

    The container doesn't needs to be updated because SteamCMD does the update, the container contains just the script that executes all commands through SteamCMD.

     

     

    I would recommend to go to the Avorion forums and ask there if there the Linux version of the dedicated server isn't updated.

     

    EDIT: The container only needs to be updated if the developers change something at the startup for example the change the server executable or something like that but that would result in not starting or that it constantly looping (restarting)

    I've ended up by installing this container on unRAID :

    https://hub.docker.com/r/rfvgyhn/avorion/tags

    This one contains the last version (1.2).

    Thanks for your explainations and your time ! :)

    • Haha 1
  12. 15 minutes ago, ich777 said:

    Yes should be possible.

    These containers update on a restart of the container itself.

     

    If it doesn't do it please set the variable Validate gamefiles to 'true'

     

    Since all games are updated through SteamCMD and that is executed on every start/restart of the container (can't include the dedicated server files this would be a copyright horror... :D ).

     

    Hope this makes sense to you.

     

    EDIT: Forgot to say that this is mentioned in the Description of all my containers: 'Update Notice: Simply restart the container if a newer version of the game is available.'

    Thanks for the fast answer !

    So I've setup the "Validate gamefiles" variable to "True", and restarted the container, but it seems to be still running in 1.1.2 :

    Sans-titre.png

    It also seems that the container isn't updated since 6 months :

    image.thumb.png.0387a229325ec833be35d95c90d55b52.png

    Or again there is something that I don't know / understand^^