Capt.Insano

Community Developer
  • Posts

    296
  • Joined

  • Last visited

Everything posted by Capt.Insano

  1. I am running this docker with the deafult (latest) tag. Current version: HTS Tvheadend version 4.3-1979~g8fc2dfa7e I am not sure if that is currently recommended or not? When recording via autorecs the recordings fail with a file missing error, the scheduled recording "starts" there is no file outputted: During a "recording": Status > Subscriptions lists the output as 0kb/s and there is no file created in the unRAID filesystem It is not a permission issue (either filesystem or user permissions) as: If I stop the autorecording and start it manually via either WebUI or Kodi the recording works correctly. The Priority and DVR Configurations for the autorecs are the same as manually triggered recordings but only manully triggered or schedued recordings work. I have tried searching this bug in regular tvheadend forums but got nowhere. Anyone here having the same issue?.
  2. I did, infact they were already installed but I also updated them and all drivers to latest stable: virtio-win-0.1.208
  3. I followed your recommendation of changing my VMs to hibernate instead of shutdown, any other recommendations seeing as libvirt is the culprit?
  4. Anyway of figuring what was using Cache? If I monitor top/htop during a shutdown would that tell me?
  5. @JorgeB Sorry, I didn't realise there were other logs: Attached are the 2 zips dated today from /boot/logs Are these the diags that you were after? Thanks for the help BTW tower-diagnostics-20211019-0953.zip tower-diagnostics-20211019-1001.zip
  6. Hi @JorgeB, Diags were attached to the post above yours, these were the diags from the latest unclean shutdown (this morning) that caused the parity check again. I will try and stop the array manually again and time it when I get home but as per one of my prev posts above; the last time it took 1 min 9 secs to stop and the disk timeout in my settings is now 180 secs
  7. Spoke too soon, Just tried another clean reboot there and again a parity check started after power up: Diags attached again. Any further advice? tower-diagnostics-20211019-1001.zip
  8. This seems to have fixed it. Increasing the timeout to a high vaue (180 secs in my case) has ensured enough time for safe shutdown even in the event of a Windows update during VM shutdown. Thanks @Frank1940. Update: See below, problem returned after array runnning for any length of time.
  9. I timed how long it took to stop the array from the Main tab: 1 minute & 9 Seconds. Could it be that 90 secs is not long enough in my setup for all my VMs (x3) and Docker Containers (x30+) to shutdown fully if something like a windows update kicks in? I am going to up the timeout to 180 secs and see if a parity check starts on reboot.
  10. Everytime I reboot or shutdown my system a parity check starts when it powers back up. I am aware from reading other topics that this usually means an unclean shutdown but there is no errors appearing in the syslog during the shutdown process. I have read a very similar topic here: I based on that topic, have tried replacing my flash-drive to a new one and have tried chaging the shutdown timeout as per this comment in above thread: "Timeout appears to be kicking sooner than it should, go to Settings - Disk Settings and change the shutdown timeout to a different value just to re-apply, set it to like 60 secs." But still I get a parity check starting after reboot. Diags Attached, I would greatly appreciate any help. Thanks to all. tower-diagnostics-20211018-1428.zip
  11. EDIT: Nevermind! Found the below comment that explains governors on Intel Pstate driver: _________________________________________________________________________________ Original Post: Under CPU Scaling Governor I have no option for ondemand, not sure if this is normal? Running unRAID 6.9.0: Is this as expected? Thanks a million for your work.
  12. I imagine this may be an issue for others so posting my experience here: After upgrade from 6.8.3 (all smooth), I removed the following from my go file: modprobe i915 chmod -R 777 /dev/dri I then created the blacklist override as per release notes and rebooted: touch /boot/config/modprobe.d/i915.conf This correctly loads the i915 module: root@Tower:~# ls /dev/dri by-path/ card0 renderD128 However the permissions seem to be an issue: root@Tower:~# ls -la /dev/dri total 0 drwxr-xr-x 3 root root 100 Mar 3 11:57 ./ drwxr-xr-x 16 root root 4320 Mar 3 12:02 ../ drwxr-xr-x 2 root root 80 Mar 3 11:57 by-path/ crw-rw---- 1 root video 226, 0 Mar 3 11:57 card0 crw-rw---- 1 root video 226, 128 Mar 3 11:57 renderD128 Emby will not use hardware transcoding unless I also issue the following command and then restart the container: chmod -R 777 /dev/dri As such I have added that command back into my go file. Is this the correct action to take or is there something else that sould be done regarding the permissions of /dev/dri for container usage? Congrats @limetech & team for another great release.
  13. I just download this container for the 1st time and I am getting the same errors in my log unRAID 6.8.3
  14. Sorry to wake an old thread but I see that psutil has been removed from the image (no clue when, just noticed this issue today!!). This seems to break the System Info page in HTPC Manager: I have tried installing psutil via NerdPack to the host system but this is not working either. Am I missing somthing? As always, thanks for all your work.
  15. I have been running an unRAID server for just shy of 7 years and last night for the first time I received an alert of some read errors on a disk. disk 3 (WD Red 3TB) on my array shows 153 read errors. I re-ran parity check as a precaution and no errors reported. I also ran an extended SMART test (attached) and the drive passed. I would really appreciate advice on whether I restart the array to clear the errors or should I be looking at replacing the drive? Thanks to all tower-diagnostics-20200715-1846.zip WDC_WD30EFRX-68EUZN0_WD-WCC4N6PH4FP8-20200715-1838.txt
  16. Sorry for delay, below is my config: Hope it helps
  17. Anyone interested in getting murmur up and running on unRAID in (COVID-19 lockdown!) 2020 see my post here:
  18. Sorry to bring up an old thread but with the current COVID-19 lockdown happening I needed a gaming VOIP setup to get back into some games I had not played in years! I used to love the positional audio and sound quality of Mumble so I went looking at hosting a murmur server on unRAID In case anyone is in the same boat, the docker image from here : https://hub.docker.com/r/goofball222/murmur/ runs perfectly on unRAID and is up to date with the latest murmur 1.3. Simply follow the path, port and variable instructions on the dockerhub page and it works great. Thanks to Coppit for his versions previously!
  19. Anyone know how to use the "theme folders"? I have been trying to add 3rd party themes from here: https://github.com/artyuum/ruTorrent-Themes but I cannot figure out how to add them persistently to this docker container. Thanks in advance
  20. Thanks a million @binhex. I am away for the next week but will defo get on it once I am home!!
  21. I had actually tried that container prior to posting but I could not get my .opvn file to be correctly seen by the container, I kept getting errors in the log about no configuration file found. I do not want to be too off topic but, would you mind posting a picture of your configuration if you have it successfully working? Otherwise: @binhex do you have ant interest in making such a container with unRAID based settings?
  22. I was actually coming here to ask for the same thing! 1. Would it be possible to get a Privoxy/OpenVPN container without any associated app? 2. Is it possible to run a privoxy container on a static IP (Custom: br:0)? Anytime I try and set a static IP for a Privoxy/OpenVPN container the proxy fails when connected from my Win10 laptop. Thanks a million for all your hard work binhex!
  23. Marking this as solved! No problems since, Thanks a million johnnie.black!
  24. According to that post you linked it was to be fixed in kernel 4.14. Seeing as I am on unRAID 6.6.6 and running kernel 4.18 why it is still a problem? root@Tower:~# uname -a Linux Tower 4.18.20-unRAID #1 SMP Fri Nov 23 11:38:16 PST 2018 x86_64 Intel(R) Xeon(R) CPU X5675 @ 3.07GHz GenuineIntel GNU/Linux
  25. I will try that right away! Thanks so much. I will report back after a few days/week whether problem is fixed with about command.