zoggy
Members
-
Joined
-
Last visited
Everything posted by zoggy
-
Bumping this as well
-
Why isn't this plugin/features part of unraid natively ?
-
you can see your load is 1.x which aligns with one of the cpus being pegged. your not showing all the processes in top.. try: top -b1
-
found this docker last night: https://hub.docker.com/r/celedhrim/kodi-server he used to be one of the guys that did the kodi-headless patch. he complained about how it wasnt fun to maintain the patch and that the increasing build times was exceeding the allowed time on dockerhub which was causing its own problems. he switched to doing fake Xorg ( with XPRA) and pulseaudio ( kodi complain is no sound card/daemon) no more patch to maintain, uses kodi ppa ubuntu image, which is much faster to build. but does result in more cpu/memory (as it has to waste cycles to do the full interface) and does rely on the ppa images (which only matters if kodi removed old images and you wanted to build an older version) so far its working just fine for me. sonarr talks to it and I see it updates everything as a normal linux box. to set it up I just installed the docker via CA docker (search for: kodi-server) since I wanted to get latest leia: celedhrim/kodi-server:leia added path 'data' and set it to my old kodi-headless dir: /mnt/cache/appdata/.kodi added 'port': 8089 (he exposes this one instead of the default 8080 --- so update advancedsettings webserver port to 8089 (or change mapping)) added 'port': 9090 (so websocket to the docker works)
-
Trying this docker out again. I had stopped because Leia support didnt come in a timely manner and I just used a firetv on the side to get by. Updated my docker from :Krypton to :Leia and noticed that it was only showing 18.3 Dug through github and found out that only the 'master' branch got updated to 18.5 (also looks like no one has been maintaining this docker?) Updated docker to just use master branch and now I see its showing 18.5 now. I see that its not able to scrape for new content however it fails to even curl to get the login token: 2020-01-21 20:31:13.916 T:22602176238592 NOTICE: ----------------------------------------------------------------------- 2020-01-21 20:31:13.916 T:22602176238592 NOTICE: Starting Kodi (18.5 Git:20200109-nogitfound). Platform: Linux x86 64-bit 2020-01-21 20:31:13.916 T:22602176238592 NOTICE: Using Release Kodi x64 build 2020-01-21 20:31:13.916 T:22602176238592 NOTICE: Kodi compiled 2020-01-09 by GCC 7.4.0 for Linux x86 64-bit version 4.15.18 (266002) 2020-01-21 20:31:13.916 T:22602176238592 NOTICE: Running on Ubuntu 18.04.3 LTS, kernel: Linux x86 64-bit version 4.19.56-Unraid ... 2020-01-22 02:31:13.937 T:22602176238592 NOTICE: ADDON: metadata.tvdb.com v3.2.3 installed ... 2020-01-22 04:05:42.202 T:22601646622464 DEBUG: GetEpisodeList: Searching 'https://api.thetvdb.com/login?{"apikey":"439DFEBA9D3059C6","id":281511}|Content-Type=application/json' using The TVDB scraper (file: '/config/.kodi/addons/metadata.tvdb.com', content: 'tvshows', version: '3.2.3') 2020-01-22 04:05:42.207 T:22601646622464 DEBUG: CurlFile::ParseAndCorrectUrl() adding custom header option 'Content-Type: application/json' 2020-01-22 04:05:42.207 T:22601646622464 DEBUG: CurlFile::Open(0x148e3818ca60) https://api.thetvdb.com/login 2020-01-22 04:05:42.486 T:22601731766016 WARNING: CActiveAE::StateMachine - signal: 22 from port: timer not handled for state: 1 2020-01-22 04:06:07.523 T:22601646622464 WARNING: Previous line repeats 25 times. 2020-01-22 04:06:07.523 T:22601646622464 ERROR: CCurlFile::FillBuffer - Failed: Timeout was reached(28) 2020-01-22 04:06:07.523 T:22601646622464 ERROR: CCurlFile::Open failed with code 0 for https://api.thetvdb.com/login: 2020-01-22 04:06:07.523 T:22601646622464 ERROR: Run: Unable to parse web site 2020-01-22 04:06:07.523 T:22601646622464 WARNING: No information found for item 'smb://husky/TV/TV/Black-ish/Season 06/', it won't be added to the library.
-
do you use SMB to access your context on the nas from plex?
-
using latest version on 6.7.2, inserted a new disk, going to preclear it but first I wanted to pull the smart details to record. /Tools/Preclear/New?name=sdn clicking on "Download SMART report:" results in nothing/this invalid url: /Tools/Preclear/%3Cbr%20/%3E%3Cb%3EWarning%3C/b%3E:%20%20copy():%20Filename%20cannot%20be%20empty%20in%20%3Cb%3E/usr/local/emhttp/plugins/dynamix/include/Download.php%3C/b%3E%20on%20line%20%3Cb%3E24%3C/b%3E%3Cbr%20/%3E/husky-smart-20200111-1706.zip
-
i held off 6.8 upgrade due to all the smb slowdown reports. anyone that had those, can you confirm if 6.8.1-rc1 resolved that?
-
Just to document, I've been seeing "eth0: failed to renew DHCP, rebinding" messages appear in 6.7+ Looking back it started with 6.7.0-rc8. rc7 and older did not throw the message. Seems to be cosmetic at least. 6.7.0-rc6 == good // dhcpcd: version 7.1.1 6.7.0-rc7 == good // no dhcpcd changes, logs last entry was: May 5 12:32:34 6.7.0-rc8 == bad // dhcpcd: version 7.2.0 May 6 10:02:35 husky dhcpcd[1603]: eth0: failed to renew DHCP, rebinding Looking at the source, I dont see anything that stands out: https://github.com/rsmarples/dhcpcd/compare/dhcpcd-7.1.1...dhcpcd-7.2.0
-
any chance we can get dhcpcd updated?
-
just to note, upgraded from 6.7.0->6.7.1-rc1->6.7.1-rc2 without problems. 6.7.0 cosmetic bug still shown every 20 hours:
-
ok, here we go: https://openbenchmarking.org/result/1906037-HV-190603PTS41,1906033-HV-190603PTS92
-
whew okay, I have an intel i3-3220 CPU and wanted to see how much performance I can get back with disabling the mitigations as noted. I upgraded to 6.7.1rc1 and spun up the Phoronix Test Suite in a docker vm and focus on the cpu test -- https://openbenchmarking.org/suite/pts/cpu The array was running but no activity was ongoing, and no other dockers were active. Test suite cycle took about 3 hours in a run, each test ran 3 times and deviations is noted. Ran first set as is with the mitigations in place then rebooted with syslinux cfg modification to disable the mitigation (still get some due to microcode used) and re-ran same tests to compare. results: https://openbenchmarking.org/result/1906037-HV-190603PTS41,1906033-HV-190603PTS92 can see that 2-14% increase on various things. The ctx-clock micro-benchmark for looking at the context switching overhead shows the big impact since Spectre/Meltdown Which is why you can see is the most drastic reported as it targets that specific area.. 87% difference! hope this helps for those curious
-
anyone else seeing this in 6.7.0 every 5 hours: I do dhcp with static assignments from my router. nothing has changed there recently (uptime on router was 85 days), rebooted this yesterday thinking it may have been the source but checked today and still seeing the messages. Looking back at my logs, looks like it started on the 6.7.0-rc8. as my logs from 6.7.0-rc7 and older does not have any of the entries. network is integrated into mobo, its a realtek: looks to be cosmetic as nothing shows any impact by it. looking at the unraid 6.7.0 release I see: dhcpcd: version 7.2.0 guessing this is the root cause. just fyi, latest is 7.2.2
-
the logical place is to go look at the security forum section about this issue which had nothing hence why I posted there and noted.
-
@limetech sorry for the cross post, but I came here looking to see if the CVE was already addressed.
-
I can confirm you will get a marvell warning from the plugin (although a bit vague): I get it because I have a Supermicro's SAS2LP-MV8 controller (based on the Marvell 9480 host controller). "Marvell" never shows up in my syslog anywhere. As others have noted, some Marvell controllers are fine (never been a problem and still is fine on 6.7.0) but it is more of piece of mind to us another brand for reliability.
-
what is different from 6.7.0 final and 6.7.0-rc8?
-
about to update to 6.7.x and noticed that since I've been on 6.6.6 the cron job hasnt kicked off the parity check in a few months settings: crontab -l # crontab -l # If you don't want the output of a cron job mailed to you, you have to direct # any output to /dev/null. We'll do this here since these jobs should run # properly on a newly installed system. If a script fails, run-parts will # mail a notice to root. # # Run the hourly, daily, weekly, and monthly cron jobs. # Jobs that need different timing may be entered into the crontab as before, # but most really don't need greater granularity than this. If the exact # times of the hourly, daily, weekly, and monthly cron jobs do not suit your # needs, feel free to adjust them. # # Run hourly cron jobs at 47 minutes after the hour: 47 * * * * /usr/bin/run-parts /etc/cron.hourly 1> /dev/null # # Run daily cron jobs at 4:40 every day: 40 4 * * * /usr/bin/run-parts /etc/cron.daily 1> /dev/null # # Run weekly cron jobs at 4:30 on the first day of the week: 30 4 * * 0 /usr/bin/run-parts /etc/cron.weekly 1> /dev/null # # Run monthly cron jobs at 4:20 on the first day of the month: 20 4 1 * * /usr/bin/run-parts /etc/cron.monthly 1> /dev/null 0 11 * * 0 /usr/local/emhttp/plugins/ca.backup/scripts/backup.php &>/dev/null 2>&1 cron.d/root # cat /etc/cron.d/root # Generated docker monitoring schedule: 10 0 * * * /usr/local/emhttp/plugins/dynamix.docker.manager/scripts/dockerupdate.php check &> /dev/null # Generated system monitoring schedule: */1 * * * * /usr/local/emhttp/plugins/dynamix/scripts/monitor &> /dev/null # Generated mover schedule: 5 8 * * 6 /usr/local/sbin/mover |& logger # Generated parity check schedule: 30 1 22-31 * 4 [[ $(date +%e -d +7days) -le 7 ]] && /usr/local/sbin/mdcmd check &> /dev/null || : # Generated plugins version check schedule: 10 0 * * * /usr/local/emhttp/plugins/dynamix.plugin.manager/scripts/plugincheck &> /dev/null # Generated unRAID OS update check schedule: 11 0 * * * /usr/local/emhttp/plugins/dynamix.plugin.manager/scripts/unraidcheck &> /dev/null # Generated cron settings for docker autoupdates 0 13 * * 0 /usr/local/emhttp/plugins/ca.update.applications/scripts/updateDocker.php >/dev/null 2>&1 # Generated cron settings for plugin autoupdates 0 0 * * * /usr/local/emhttp/plugins/ca.update.applications/scripts/updateApplications.php >/dev/null 2>&1 # Generated ssd trim schedule: 5 9 * * 6 /sbin/fstrim -a -v | logger &> /dev/null # Generated system data collection schedule: */1 * * * * /usr/local/emhttp/plugins/dynamix.system.stats/scripts/sa1 1 1 &>/dev/null
-
Nov 13 02:23:51 husky emhttpd: req (8): startState=STARTED&file=&cmdCheck=Check&csrf_token=**************** Nov 13 02:23:51 husky kernel: mdcmd (169): check nocorrect Nov 13 02:23:51 husky kernel: md: recovery thread: check P ... Nov 13 02:23:51 husky kernel: md: using 1536k window, over a total of 7814026532 blocks. Nov 13 11:41:35 husky kernel: mdcmd (170): spindown 1 Nov 13 11:41:38 husky kernel: mdcmd (171): spindown 4 Nov 13 11:41:38 husky kernel: mdcmd (172): spindown 8 Nov 13 11:41:39 husky kernel: mdcmd (173): spindown 9 Nov 13 11:41:39 husky kernel: mdcmd (174): spindown 13 Nov 13 14:42:11 husky kernel: mdcmd (175): spindown 8 Nov 13 14:42:12 husky kernel: mdcmd (176): spindown 13 Nov 13 14:42:35 husky kernel: mdcmd (177): spindown 9 Nov 13 14:42:53 husky kernel: mdcmd (178): spindown 1 Nov 13 15:00:09 husky kernel: mdcmd (179): spindown 3 Nov 13 15:00:09 husky kernel: mdcmd (180): spindown 5 Nov 13 15:00:10 husky kernel: mdcmd (181): spindown 14 started parity check, you can see that several drives have spun down since it started (and some even re-spundown) but theres never any logs of the drives spinning up?
-
docker > add container > "Add another Path, Port, Variable, Label or Device" modal is not using the standard styling,
-
that is painful to read. thankfully looks like just an oversight? all other buttons are fine that I've seen
-
Upgraded to 6.6.1 at end of Sept and no issues. Looking at my logs today I see that a few days ago there is: Oct 9 16:37:30 husky kernel: mce: [Hardware Error]: Machine check events logged Oct 9 16:37:30 husky kernel: mce: [Hardware Error]: CPU 1: Machine Check: 0 Bank 0: 9000004000010005 Oct 9 16:37:30 husky kernel: mce: [Hardware Error]: TSC b2dad2eb3ea6f Oct 9 16:37:30 husky kernel: mce: [Hardware Error]: PROCESSOR 0:306a9 TIME 1539121050 SOCKET 0 APIC 2 microcode 20 Which I've never seen before and did not appear to be service impacting. I'm not able to dig into this as mce events are not written to standard logging.. (should unraid come with mcelog?) husky-diagnostics-20181012-0935.zip
-
with active streams and latest 6.6 ui.. its easily to accidentally cancel a stream when you go to click on the 'top' image
-
Thank you for this, I will have to see if this will allow me to run GL again
