xthursdayx

Community Developer
  • Posts

    397
  • Joined

  • Last visited

Posts posted by xthursdayx

  1. On 2/6/2022 at 2:52 AM, chrispcrust said:

     

    I have the same issue in Logs - "socket: Protocol not supported" indefinitely.

     

    However, in the Nextcloud UI, mine is reporting successful ICE candidates (checkmark).

     

    Even with the "success", actually initiating a video call with Talk via WAN works for about a second, then quits out on me.

     

    Searched far and wide on this issue, this is a very complicated topic, don't think there are any other answers out there unless someone is an expert.

     

    OP has stated he is not an expert either.. and just FYI the fork of this docker from instrumentisto states: "PROJECT IS CLOSED AND ARCHIVED. NO MAINTAINING WILL BE CONTINUED." ... so this docker probably won't be getting further updates.

    Yeah, this is kind of the wall I've run into unfortunately. As you noted, I'm not an expert, and while I was able to get this container working with Matrix for video calls in the past, troubleshooting other use cases is beyond the scope of what I have time to dig into. Moreover, the development of Coturn in general is pretty specialized and slow - mostly undertaken buy one dev, and dockerized versions in particular have been difficult to develop and troubleshoot. I may try to dig into this again in the future and create my own docker image (and new Unraid template), but for now it's on a bit of an indefinite hold.

  2. On 6/15/2021 at 11:38 AM, Nilok3 said:

    Hello all. Whenever I run this docker container I get the following error: "chown: /home/docker/backups: Operation not permitted". I"m fairly sure this is because I'm trying to save all the github files to a harddrive that is not apart of the main Unraid array, but I'm not sure how to fix the permission error. It is specifically failing on line 20 (chown -R nobody /home/docker/backups) of the backup.sh script. Is there a way to give the container the permission it needs to save the files?

    Did you ever figure out this issue? I'm having the same problem, but not sure why. @lnxd have you run into this issue before?

  3. 25 minutes ago, steve1977 said:

    The docker seems to be working well. However, some weeks ago, the docker icon (the visual of Roon in the docker overview) disappeared. Doesn't impact functionality, but I like things to be nice & tidy. Any idea why it is gone and how to get it back?

    I've had this with a variety of my docker containers in Unraid. I'm not sure why, but sometimes the Dockerman interface just seems to lose track of the icon. Anyway, you can try deleting your container and reinstalling it with a new template (inputting the same settings) and see if that re-pulls the icon. That may help, but honestly, I've found sometimes they disappear and then reappear without a whole lot of rhyme or reason. 

  4. Hi, I used to have the iOS app working well, but for some reason the interface stopped updating my server. I deleted the server from the app but am now unable  to re-add my server, either by manual address entry or QR  code. I don't get any error code, just a perpetually spinning wheel. My firewall is setup to allow traffic from my phone to the server. Any idea what else might be preventing the connection, or a way to access a debug log?

  5. On 11/28/2021 at 1:18 AM, aussie_huddo said:

    Is there any way to enable the dark theme for this docker?

    I created a version with a dark theme installed. Change your container tag to xthursdayx/gpodder-docker:dark in your template and pull the image. You should have the dark theme installed then. 

  6. On 11/19/2021 at 6:58 AM, aussie_huddo said:

    Had some issues trying to get the web UI to load so I reinstalled the docker. 

     

    I can now access the webUI however there is no record of my podcasts and downloads that are in the folder.

     

    Can i import anything from existing appdata or just add podcast URLs and re-download?

    Sorry for the difficulties! gPodder should recognize the existing podcasts in your /downloads directory once you add the podcast URLs back into gPodder. Sorry for the extra step of having to re-add the URLs, but you shouldn't have to re-download your existing episodes at least. 

  7. @Ryonez @musicking and @stefan marton since the updated and rebased container was just pushed to Docker Hub, please try running Ferdi-server with the updated parameters described on Page 1 of this thread. The new Ferdi-server Unraid template with updated defaults should be parsed and available in Community Apps soon.

     

    If you are migrating an existing Ferdi-server container please see the migration instructions above. However, to be honest, I've found it smoother to just roll a new container from scratch after this update. 

    Please let me know if the new container fixes the issues you're having, or if you're still having problems. Cheers!

    • Like 1
  8. The new version of the Ferdi-server docker image has been pushed to Docker Hub.

     

    Existing users, please note: The latest updates to Ferdi-server and the Ferdi-server Docker image introduce changes to the default SQLite database name and location, as well as the internal container port. The new container port is 3333. If you would like to keep your existing SQLite database, you will need to add the DATA_DIR variable and change it to /app/database, to match your existing data volume. You will also need to change the DB_DATABASE variable to development to match your existing database. Please see the parameters in the Migration section below.
     

    Migrating from an existing Ferdi-server:

    If you are an existing Ferdi-server user using the built-in `SQlite` database, you should include the following variables:

    | -p 3333:3333 | existing Ferdi-server users will need to update their container port mappings from 80:3333 to `3333:3333` |
    | -e DB_PASSWORD=development | existing Ferdi-server users who use the built-in sqlite database should use the database name development |
    | -e DATA_DIR=/app/database | existing Ferdi-server users who use the built-in sqlite database should add this environmental variable to ensure data persistence |
    | -v <path to data on host>=/app/databases | existing Ferdi-server users who use the built-in sqlite database should use the volume name /app/database |

     

    If you are an existing Ferdi-server user who uses an external database or different variables for the built-in `SQlite` database, you should update your parameters accordingly. For example, if you are using an external MariaDB or MySql  database your unique parameters might look like this:
     

    | -e DB_CONNECTION=mysql | for specifying the database being used |
    | -e DB_HOST=192.168.10.1 | for specifying the database host machine IP |
    | -e DB_PORT=3306 | for specifying the database port |
    | -e DB_USER=ferdi | for specifying the database user |
    | -e DB_PASSWORD=ferdipw | for specifying the database password |
    | -e DB_DATABASE=adonis | for specifying the database to be used |
    | -v <path to database>:/app/database | this will strore Ferdi-server's database on the docker host for persistence |
    | -v <path to recipes>:/app/recipes | this will strore Ferdi-server's recipes on the docker host for persistence |

     

    **In either case, please be sure to pass the correct variables to the new Ferdi-server container in order maintain access to your existing database.**

     

    For more information please check out the Docker README.md on Github: https://github.com/getferdi/server/tree/master/docker

  9.   

      

    14 hours ago, xrqp said:

    When I look at the room container port mapping it only show 3 question marks. I cannot remember if that is normal.  All other containers show a 4 digit port number

    14 hours ago, xrqp said:

    I have narrowed it down to be a roon vs emby conflict.  I can run any and all containers, except emby, and roon works fine (both server and remotes). 

    13 hours ago, xrqp said:

    Can I assign a port number to the roon container?

     

    You shouldn't see any ports (or question marks) associated with your RoonServer container, since no ports should manually be assigned to the RoonServer container and your container should be running in host mode. Based on your screenshot, you do have your container network running as Host, which is correct. As I mentioned previously,  Roon's developers have stated that Roon runs on ports 9003/UDP and 9100-9200/TCP, however they've also mentioned that Roon may randomly assign TCP ports, and other troubleshooting has indicated that Roon conflicts with Emby and Roon, due RoonServer using port 1900, despite the devs never mentioning this. The way Roon manages port allotment is very annoying, and it's frustrating that Roon's devs can't (or won't) be more clear about what ports RoonServer uses.

     

    I looked into changing RoonServer's ports when I was considering rolling my own RoonServer image (to replace Steef's), but it is not possible to change the ports RoonServer uses. You can map your RoonServer container ports to different host ports if you run the container in bridge mode, however, there is no way to tell your various Roon endpoints and apps that your CORE server is running on a different port, so they will not be able to find your Roon CORE server if you do this. I don't know why your container shows three question marks for the port. In my experience, there should not be any ports listed at all, since the container is running in host mode. See my configuration, you'll notice no ports or local container IP listed:

    930420219_ScreenShot2021-11-08at12_50_16.thumb.png.2473ba5dfcae8dc601a8e3cbeba499a8.png

     

    The only way to make sure that your RoonServer ports do not conflict with any other running container on your UNRAID server is to make sure not to map any other containers ports to 1900, 9003, or 9100-9200. My suggestion is map your Emby DLNA port to another port, or just remove it as you already did. If you choose to stick with removing it, I'd also turn off DLNA and automatic port mapping within Emby. (In Emby, in Devices>DLNA, turn off “Enable DLNA Play To” and “Enable DLNA server”. In Advanced turn off “Enable automatic port mapping”). Roon plays well with Plex, which also uses port 1900 for UPnP discovery, so the problem seems to be with Emby rather than Roon. Apparently this is a known issue with Roon and Emby. You can read more about it here. Your safest bet for now is to keep port 1900 open, along with 9003 and 9100-9200.

     

     

    14 hours ago, xrqp said:

     

    The nag to update came on my ipad running roon remote.  It asked if I should update all devices and I replied yes. I assume, and it appears to update all remotes - ipad, iphone, Win10 desktop.  But I don't know if it can, or did, update the server in the unraid container, and I don't know how to check that. 

    You should have been able to see which devices needed to be updated when this update nag appeared. I assume it probably included your Roon CORE server, and if so, you would have been able to update it via your iPad Roon Remote app. You can't check whether this was the case retroactively though.

     

     

    14 hours ago, xrqp said:

    If I recall correctly, the last path, the data path, is a secondary location for some of my music.  Maybe I should delete that path map.

    The data path contains Roon's database, logs, and cache files (including those for RoonServer, RAATServer, and RoonGoer). Deleting this directory alone will only cause you more problems. If you want to reinstall RoonServer my suggestion is that you delete your entire appdata folder, delete your RoonServer container (and RoonServer image), and reinstall using the template in CommunityApps. 

     

     

    14 hours ago, xrqp said:

    My regular unraid parity check just completed today and reported, in a yellow box (not red box) "836 errors".  The previous one a month ago had no errors.  So today I ran "Fix common problems" and it says "no errors".  Today I ran for all 8 disks the "SMART short self-test" and all 8 say "Completed without error".

    Fix Common Problems will not recognize or fix parity issues. Your 836 parity errors are likely the result of an unclean shutdown/power loss (or more than one), or due to impending drive failure, though this should have been apparent when you rant your SMART tests. You could try to run extended SMART tests on your drives, but you should also run another parity test to see if it completes without errors. Either way, I'm not sure if this relates to any issues you're having with RoonServer since it seems that port 1900 may the culprit. However, if you still have issues with Roon data loss it might be that one of your drives is failing and you're having data corruption, or that your server is rebooting without a clean shutdown which is causing data corruption. However, as I noted previously, don't think this is an issue with UNRAID, but more likely an issue your server itself (either hardware, or MB bios).

     

    I hope this helps you get RoonServer running smoothly.

     

     

  10. 10 hours ago, xrqp said:

    Sorry for complaining, but it is info.   I got the usual nag to update roon.  I  knew if I said "no" to the update, it would nag constantly into the infinite future.  So I gave in, I updated roon from my ipad running Roon Remote, and now nothing works.  The 3 devices that run roon do NOT work.  the Unraid server with roon container - No web interface but I guess it is workin.  And I cannot figure out how to undo the update, and Roon website i was not able to find info, not even how to contact a HUMAN.  So I sent in a help request in "how to contact a human". 

    There is definitely humans here, so Howdy to y'all.  and if you got anything to add, I'm all ears (eyes?).  Friday night and roon ain't working blues.

    This container doesn't have a web interface because it is just for the Roon CORE server, which can only be accessed and controlled by Roon Remote or Roon (their terminology is a bit confusing and imprecise) running on another computer or as an app on a phone or tablet, like you're doing. When you say that you updated Roon via your iPad, do you mean that you updated the Roon CORE (running on Unraid), or the Roon Remote app on your iPad? Or both? If your install is broken then the only thing to do is probably to delete your Roon Server appdata folder, reinstall this Roon Server container and create the library from scratch.

    Unfortunately I'm not sure that we'll be able to help you figure out what is going wrong. Updating works fine for me using this container and my Unraid template, and it doesn't seem like anyone else has been having trouble lately. One thing I'd note is that the trouble you're having is similar to the trouble I had early in my attempts to get this container running on Unraid, before I properly separated the /app and /data directories within the Roon Server appdata folder. If you do decide to delete your instance and start from scratch, make sure to install Roon from Community Apps using the current template, and make sure to follow the template directory structure. If you've already done this and have your /app and /data directories properly set up, then the updates should be working. If they aren't, then I wonder if the problem is either related to your local network or if there is so issue with persistence on your Unraid server. I can't think what else would be the problem.

     

    The fact that you had updating problems before (as you mentioned here) but were able to successfully update (as mentioned here and here) and previously got things working again by uninstalling and reinstalling the Roon software on a separate remote PC is confusing to me and seems to indicate that the problem is with your network, rather than the RoonServer container itself, but I'm not sure. I haven't personally seen evidence to support your concerns about Unraid's "robustness", but I also haven't run into the problem of losing my music files before (or any other files) and haven't seen anyone else have this issue with Unraid (or Roon) either. I've had a drive fail before, but Unraid's parity system was able to reconstruct the data without any issues when I replaced the drive. My gut feeling is that you may still have an issue with your container settings, or are having more drive problems. Are you using a cache drive (preferably an SSD) to store your appdata directory? Outside of that it could be your local network settings (as I mentioned above), but it's hard to know.


    You can post your RoonServer container settings here if you'd like to confirm that they're correct. My best advice, other than that, is to check the SMART readings of your drive(s), use an SSD cache for your appdata directory, and check on your network traffic, making sure that your router/firewall is allowing traffic between your remote PC(s) and Roon apps and your RoonServer container/Unraid server on the ports I mentioned previously.

    Best of luck getting to the root of your problems.

  11. 1 hour ago, psycho_asylum said:

    I know it doesn't fix the issue you're seeing, but I've downloaded a few things in Japanese and Korean without any trouble.

    Hey, thanks for that @psycho_asylum. I've found the same result as you — no problem downloading (or adding to seed) files or directories with non-ascii characters. My main concern is about maintaining proper file and directory names of items that are long-term seeding but which have those non-ascii characters.

  12. @binhex Is there any way to get this docker container to work with non-ascii characters, for things like directories, for example? I have a number of torrents seeding that have East Asian characters in their file names as well as other non-ascii charaters (ü å etc) and currently when I add them to ruTorrent those characters are just skipped in the resulting filenames and/or directories. I previously ran ruTorrent using the Linuxserver docker image and didn't have a problem with these characters, so I assume that the issue isn't with ruTorrent (or rTorrent) but rather has to do with the locale encoding of your arch-base image? Since your base image has LANG set as en_GB.UTF-8 those characters should work, but perhaps some of the locale files are missing? Or it could be some problem with my container settings, but my setup is pretty simple. Any ideas? Thanks!

  13. On 10/19/2021 at 4:21 PM, highgear said:

    Just got an email from Roon about some major updates to Linux cores. I guess they’re switching from Mono to .NET which requires libicu to be installed ahead of the update. Any thoughts as to if anything needs to be done on our end for this to work properly?

     

    https://help.roonlabs.com/portal/en/kb/articles/linux-performance-improvements

    I'll contact Steef about it to make sure he's planning to update the core image. If not, I'll roll my own and update here. I'll report back here once I know though. 

     

    Edit: the necessary libraries are already installed in this image, so no changes are necessary. This has already been tested by someone running the beta update. Please see this Github issue for more info. Cheers!

    • Like 1
    • Thanks 2
  14. On 9/25/2021 at 12:20 PM, thunderclap said:

    Woops, sorry about that. Got my containers mixed up. Sorry about that.

     

    Update: So I completely removed xthursday's docker and purged all its files, installed your version and, strangely enough, the same error reappears.

    Yep, the issue is due to their being two approved templates for the same image in CA. Squid will have to decide which one to remove, and then you should no longer see this error in the Fix Common Problems plugin. In the meantime, you shouldn't worry about this error as it shouldn't impact your ability to use your Whoogle-search contiainer.

     

    Apologies if you added your template first @FoxxMD. I added mine because I didn't see one in CA and was using Whoogle myself, so I figured I'd share UNRAID my template, but it's possible that you'd already added yours by the time that mine updated in CA. 

  15. 20 hours ago, fmp4m said:

    I have the same issue as above however if you fix:

    https://raw.githubusercontent.com/xthursdayx/docker-templates/master/xthursdayx/whoogle-search.xml

    it wants 

    https://raw.githubusercontent.com/FoxxMD/unraid-docker-templates/master/foxxmd/whoogle-search.xml

    and if you fix that it wants the other and is stuck in a cyclic loop.

    As @Squid mentioned above, this is because both FoxxMD and I created templates for the same image. I think he's removed mine now, but I'm not sure as I'm out of town and can't check my UNRAID server at the moment. My best suggestion is to check CA and see which Whoogle template is listed, and then use that one. 

  16. On 7/10/2021 at 5:24 PM, juan11perez said:

    This is what I did with "user scripts"

    1. Created as script, that's simply a place holder for the docker compose binary. In my example it's called "06_docker_compose_binary". Just create it in the web ui. Add nothing.
    2.  A script that downloads the docker-compose binary, once a month, into the place holder script created in step one:
    #!/bin/bash
    #----------------------------------------------------------------------------
    # This script will update docker-compose script from github periodically    |
    #----------------------------------------------------------------------------
    
    COMPOSE_VERSION=$(curl -s https://api.github.com/repos/docker/compose/releases/latest | grep 'tag_name' | cut -d\" -f4)
    curl -L https://github.com/docker/compose/releases/download/${COMPOSE_VERSION}/docker-compose-`uname -s`-`uname -m` -o /boot/config/plugins/user.scripts/scripts/06_docker_compose_binary/script

     

    3. Add to /boot/config/go file:

     

    # COPYING DOCKER-COMPOSE ##########
    cp /boot/config/plugins/user.scripts/scripts/06_docker_compose_binary/script /usr/local/bin/docker-compose
    chmod +x /usr/local/bin/docker-compose
    ###################################

     

    That's it!

    It's updated regularly and doesnt need internet on server start.

     

    Hope it helps.

     

     

     

     

     

     

     

     

     

    Juan, you're a hero.

  17. 6 hours ago, jbuszkie said:

     

    You posted the space available for your cache and others..  But how much space do you have left in /var?  Was it full?

     

    The first thing I do is delete the syslog.1 to make some space so it can write the log, then I restart nginx.   Then I tail the syslog to see if the writes stop. My syslog.1 is usually huge and frees up a lot of space so it can write to the syslog

    The time before last time, I still had some of those errors in the syslog after the restart..  So I was going to stop my dockers one by one and see if it stopped.  And well it did with my first one.

    Two days ago when then happened to me..  I didn't have to do that.  the restart was all I needed...

     

    Yeah, you're right, I should have included that. I checked /var and it was not full. See:
     

    df -h /var
    Filesystem      Size  Used Avail Use% Mounted on
    rootfs           32G  7.0G   25G  23% /

    However /var/log does show as 100% full:
     

    ❯ df -h /var/log
    Filesystem      Size  Used Avail Use% Mounted on
    tmpfs           128M  128M     0 100% /var/log

    I deleted syslog.1 and syslog.2, restarted nginx and tailed my syslog. No more nchan out of memory errors, but I'm getting this error constantly:
     

    nginx: 2021/09/17 16:53:47 [alert] 2815#2815: worker process 11259 exited on signal 6

     

  18. I've just started running into this issue as well, on a machine running unRAID 6.10.0-rc1 with 64Gb of memory, which has always been plenty, though I too am guilty of leaving unRAID WebUI tabs open (as well as mosh/ssh sessions running). Interestingly, I'm able to access the pages of the WebUI and see the header and nav buttons, as well as the major sections of pages like the Dashboard and Main, however they're empty, not showing my disks, docker containers, etc. The only way I've been able to (temporarily) “fix” the issue is by restarting my server.

     

    I tried restarting /etc/rc.d/rc.nginx/, but it didn't make any difference, as you can see in these logs:

    Sep 17 02:25:29 vulfTower nginx: 2021/09/17 02:25:29 [alert] 25209#25209: worker process 32623 exited on signal 6
    Sep 17 02:25:29 vulfTower nginx: 2021/09/17 02:25:29 [alert] 25209#25209: worker process 32645 exited on signal 6
    Sep 17 02:25:31 vulfTower nginx: 2021/09/17 02:25:31 [alert] 25209#25209: worker process 32647 exited on signal 6
    Sep 17 02:25:31 vulfTower nginx: 2021/09/17 02:25:31 [alert] 25209#25209: worker process 334 exited on signal 6
    Sep 17 02:25:31 vulfTower nginx: 2021/09/17 02:25:31 [alert] 25209#25209: worker process 339 exited on signal 6
    Sep 17 02:25:32 vulfTower nginx: 2021/09/17 02:25:32 [alert] 25209#25209: worker process 350 exited on signal 6
    Sep 17 02:25:33 vulfTower nginx: 2021/09/17 02:25:33 [alert] 25209#25209: worker process 405 exited on signal 6
    Sep 17 02:25:33 vulfTower nginx: 2021/09/17 02:25:33 [alert] 25209#25209: worker process 565 exited on signal 6
    Sep 17 02:25:33 vulfTower nginx: 2021/09/17 02:25:33 [alert] 25209#25209: worker process 591 exited on signal 6
    Sep 17 02:25:34 vulfTower nginx: 2021/09/17 02:25:34 [alert] 25209#25209: worker process 594 exited on signal 6
    Sep 17 02:25:34 vulfTower rsyslogd: file '/var/log/syslog'[2] write error - see https://www.rsyslog.com/solving-rsyslog-write-errors/ for help OS error: No space left on device [v8.2102.0 try https://www.rsys
    log.com/e/2027 ]
    Sep 17 02:25:34 vulfTower rsyslogd: action 'action-0-builtin:omfile' (module 'builtin:omfile') message lost, could not be processed. Check for additional error messages before this one. [v8.2102.0 try https:/
    /www.rsyslog.com/e/2027 ]
    Sep 17 02:25:34 vulfTower rsyslogd: rsyslogd[internal_messages]: 561 messages lost due to rate-limiting (500 allowed within 5 seconds)
    Sep 17 02:25:34 vulfTower rsyslogd: file '/var/log/syslog'[2] write error - see https://www.rsyslog.com/solving-rsyslog-write-errors/ for help OS error: No space left on device [v8.2102.0 try https://www.rsys
    log.com/e/2027 ]
    Sep 17 02:25:34 vulfTower rsyslogd: action 'action-0-builtin:omfile' (module 'builtin:omfile') message lost, could not be processed. Check for additional error messages before this one. [v8.2102.0 try https:/
    /www.rsyslog.com/e/2027 ]

    ad infinitum

     

    I'm also getting these errors in my logs:

    Sep 17 02:32:54 vulfTower nginx: 2021/09/17 02:32:54 [alert] 25209#25209: worker process 4936 exited on signal 6


    Anyway, I tried running du to check my log sizes as well as df to check how full my cache drives and boot flash drive are, to see if I could identify the issue. You can see the results below. While my NGINX and Syslog are large, neither seem to be large enough to disable access to the WebUI, and neither of my cache drives (where I store my syslog backup).

    ❯ du -sh /var/log/*
    4.0K	/var/log/apcupsd.events
    0	/var/log/btmp
    0	/var/log/cron
    0	/var/log/debug
    88K	/var/log/dmesg
    1012K	/var/log/docker.log
    0	/var/log/faillog
    2.8M	/var/log/file.activity.log
    16K	/var/log/gitflash
    4.0K	/var/log/lastlog
    4.0K	/var/log/libvirt
    4.0K	/var/log/maillog
    0	/var/log/messages
    0	/var/log/nfsd
    52M	/var/log/nginx
    0	/var/log/packages
    0	/var/log/pkgtools
    0	/var/log/plugins
    0	/var/log/preclear.disk.log
    0	/var/log/pwfail
    0	/var/log/removed_packages
    0	/var/log/removed_scripts
    0	/var/log/removed_uninstall_scripts
    20K	/var/log/samba
    0	/var/log/scripts
    0	/var/log/secure
    0	/var/log/setup
    0	/var/log/spooler
    0	/var/log/swtpm
    69M	/var/log/syslog
    3.6M	/var/log/syslog.1
    0	/var/log/vfio-pci
    8.0K	/var/log/wtmp

     

    ❯ df -h /mnt/cache
    Filesystem      Size  Used Avail Use% Mounted on
    /dev/sdf1       466G  306G  157G  67% /mnt/cache

     

    ❯ df -h /mnt/cache_io
    Filesystem      Size  Used Avail Use% Mounted on
    /dev/sdk1       932G  244G  688G  27% /mnt/cache_io

     

    ❯ df -h /boot
    Filesystem      Size  Used Avail Use% Mounted on
    /dev/sda1       7.5G  893M  6.6G  12% /boot

     

    Any ideas? For some reason, I'm currently unable to download my diagnostics, but any advice or ideas would be much appreciated. Cheers!

  19. On 8/10/2021 at 11:21 PM, xrqp said:

    MY MUSIC FILES DISAPPEARED, from my music share.  

    It happened about 8 months ago and I recovered most/all of it by doing xfs repair. 

    It happened yesterday and I am still seeking advice at My music disappeared. before I do xfs repair.

    But I am wondering if unraid is not robust.  Or it could be my harddrive(s) fault.  Or it could be I just did a Roon update.  Anyone else using Unraid and Roon having this problem?

    That’s very alarming @xrqp! Glad you were able to resurrect your lost data last time and hope you’ll be able to again. My guess would be that problem is your harddrives or something about how your unRAID shares are set up. I’ve never had this problem or heard of anyone having it in relation to Roon. Sorry not to be of more help, but best of luck. And definitely let us know if you do end up finding some connection to Roon. I’ve already been working on either making a new base image or adding a PR to Steef’s, so it’s a good time if some work needs to be done.

  20. Interesting, I've been having some instability and temp issues recently and now I'm wondering if it has to do with the flashed Dell PERC H310 I have my server right now.

     

    In terms of the PIKE 2308 card, did you just follow the same directions cited above for the 2008 card? Or did you run into any differences?

    BTW, thanks for replying, despite the necro-thread!

  21. On 7/8/2021 at 10:51 AM, aurevo said:

    Also, thanks a lot for this, I'm using this (with the appropriate link, of course) as part of an existing script to install neofetch at the start up of the array, since the package NerdPack doesn't seem to work. 

  22. On 12/7/2020 at 5:35 PM, xthursdayx said:

    I'm not sure why, since it seems like you're no longer having this problem @ksignorini, but I'm not having this exact issue with neofetch. I'm on 6.8.3 and Nerdpack is up to date. Any ideas @dmacias?

    I'm still having this same issue with neofetch on the latest version of unRAID. The NerdPack interface shows neofetch-20200708-noarch-1.txz as downloaded but not installed, and my syslog shows "nerdpack: Installing neofetch-20200708 package..." while every other package I have installed says something like "perl-5.32.0 package up to date, checksum ok."

    Any ideas why it won't actually install?