FlexGunship

Members
  • Posts

    22
  • Joined

  • Last visited

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

FlexGunship's Achievements

Newbie

Newbie (1/14)

0

Reputation

  1. Hey all, that seemed to improve things, but I've seen the issue again. Sorry for the delay. I moved 3000 mile, my daughter was born, and I started a new job.
  2. Test in progress. Transcoding some Plex, copying some trivial files, etc. Will report back.
  3. Put it in maintenance mode, and run on disk2 (removed the -n argument). Results below: Phase 1 - find and verify superblock... Phase 2 - using internal log - zero log... - scan filesystem freespace and inode maps... - found root inode chunk Phase 3 - for each AG... - scan and clear agi unlinked lists... - process known inodes and perform inode discovery... - agno = 0 - agno = 1 - agno = 2 - agno = 3 - process newly discovered inodes... Phase 4 - check for duplicate blocks... - setting up duplicate extent list... - check for inodes claiming duplicate blocks... - agno = 2 - agno = 0 - agno = 1 - agno = 3 Phase 5 - rebuild AG headers and trees... - reset superblock... Phase 6 - check inode connectivity... - resetting contents of realtime bitmap and summary inodes - traversing filesystem ... - traversal finished ... - moving disconnected inodes to lost+found ... Phase 7 - verify and correct link counts... done
  4. Tried many times... the system hardlocks pretty aggressively. Even locally, with keyboard and mouse on the server, you can't navigate. The syslog is the best I've gotten so far.
  5. Same problem... diag.zip doesn't help since it refreshes on boot. I have the syslog attached below: syslog
  6. Thanks, just enabled. I can probably induce the issue later by redownloading artwork for Plex, or just doing a heavy file transfer. Will post results after.
  7. Material update #1: Performed repair on filesystem, looks good. Blew away all of my dockers, and rebuilt everything. Mostly back to normal. Previous problem h as begun expressing itself in the old way again. Image of monitor on server attached as well as logs after a reboot (had to reboot, response was too slow). athena-diagnostics-20210207-1644.zip
  8. Thank you. After taking proper precautions, I'm running it now. Will update when complete. I'll research this. But I believe I've done it before. The large docker.img size is likely due to album art, etc. for Plex.
  9. Per your request. athena-diagnostics-20210202-2055.zip
  10. I can't find any relevant log data, but I'm worried I'm looking in the wrong place. Instead, I hooked up a VGA monitor to the server and took a photo (below). The symptoms are benign mostly, but can actually take down my home network in some rare cases. System boots well. Runs flawlessly for 1-2 days. But, eventually, something like this appears on the monitor. More rarely, it generates HUGE amounts of network traffic, and grinds everything to a halt. I'm considering running a repair on the xfs filesystem on disc1 (md1). But I also understand that can come with risks. To date, I've not lost any data that I know of. However, I believe this issue has randomly claimed some of my Dockers in the past. Happy to provide any/all other info if someone could provide some guidance. EDIT: was wrong... evidence is in the log file. See attached. athena_log_jan29.txt
  11. I fresh install of the docker AFTER fixing the xfs filesystem error seems to have resolved things. Error messages gone. License working. Just an awful coincidence. Thanks to those who helped.
  12. Okay, I resolved the license issue after fixing an xfs filesystem problem on one of the disks (miracle of miracles). You can see below that the license is now recognized. However, I still get the error message spam indicating an issue with file permissions: FileBot 4.9.2 (r8046) JDK8 JNA Native: 5.2.2 MediaInfo: 18.08.1 Tools: fpcalc/1.4.3 p7zip/16.02 unrar/5.61 Extended Attributes: OK Unicode Filesystem: OK Script Bundle: 2020-12-01 (r724) Groovy: 3.0.6 JRE: OpenJDK Runtime Environment 1.8.0_252 JVM: 64-bit OpenJDK 64-Bit Server VM CPU/MEM: 8 Core / 15 GB Max Memory / 57 MB Used Memory OS: Linux (amd64) HW: Linux 6b4207f600d8 4.19.107-Unraid #1 SMP Thu Mar 5 13:55:57 PST 2020 x86_64 GNU/Linux CPU/MEM: Intel(R) Core(TM) i7-6700 CPU @ 3.40GHz [MemTotal: 67 GB | MemFree: 64 GB | MemAvailable: 65 GB] STORAGE: btrfs [/] @ 314 GB | fuse.shfs [/watch] @ 7 TB | fuse.shfs [/config] @ 7 TB | fuse.shfs [/output] @ 7 TB | fuse.shfs [/storage] @ 7 TB DATA: /config Package: DOCKER License: FileBot License P22573292 (Valid-Until: 2022-02-05) (process:1019): dconf-CRITICAL **: 07:07:05.919: unable to create file '/tmp/run/user/app/dconf/user': Permission denied. dconf will not work properly. (process:1019): dconf-CRITICAL **: 07:07:05.920: unable to create file '/tmp/run/user/app/dconf/user': Permission denied. dconf will not work properly. (process:1019): dconf-CRITICAL **: 07:07:05.920: unable to create file '/tmp/run/user/app/dconf/user': Permission denied. dconf will not work properly. (process:1019): dconf-CRITICAL **: 07:07:05.920: unable to create file '/tmp/run/user/app/dconf/user': Permission denied. dconf will not work properly. (process:1019): dconf-CRITICAL **: 07:07:05.920: unable to create file '/tmp/run/user/app/dconf/user': Permission denied. dconf will not work properly. (process:1019): dconf-CRITICAL **: 07:07:05.920: unable to create file '/tmp/run/user/app/dconf/user': Permission denied. dconf will not work properly. (process:1019): dconf-CRITICAL **: 07:07:05.921: unable to create file '/tmp/run/user/app/dconf/user': Permission denied. dconf will not work properly. (process:1019): dconf-CRITICAL **: 07:07:05.921: unable to create file '/tmp/run/user/app/dconf/user': Permission denied. dconf will not work properly. (process:1019): dconf-CRITICAL **: 07:07:05.921: unable to create file '/tmp/run/user/app/dconf/user': Permission denied. dconf will not work properly. (process:1019): dconf-CRITICAL **: 07:07:05.921: unable to create file '/tmp/run/user/app/dconf/user': Permission denied. dconf will not work properly. Done ヾ(@⌒ー⌒@)ノ
  13. I'm having a new problem with FileBot container after about a year. My license expired, and I had to purchase a new one. I deleted the old license file, added the new one and restarted. This coincided with some new files appearing in the watch folder. These are the messages I'm getting: The last line is spammed 8 - 10 times. I assumed a permissions issue.... so I chmod'd everything in appdata/FileBot to 777 to test, but there is no change in the symptoms. I've also reinstalled the docker with no change. Has anyone seen this issue arise when adding a new license file? I assume I've borked the ownership or premissions somehow. Thanks.
  14. Hi, I'm having some issues after migrating from the "coppit" docker to the "jlesage" docker. 1) I tried parsing over the same renaming arguments, but it didn't work at first -- changed to default {plex} for further testing -- originals below Music/{n.$QUOTE_FIXER}/{album.$QUOTE_FIXER}/{media.TrackPosition.pad(2)} - {t.$QUOTE_FIXER} Movies/{n.colon(' - ')} ({y}) [{vf} {channels}]/{n.$QUOTE_FIXER} {vf} {af} TV Shows/{n} ({y}) [{vf} {channels}]/{episode.special ? 'Special' : 'Season '+s.pad(2)}/{n} - {episode.special ? 'S00E'+special.pad(2) : s00e00} - {t.${QUOTE_FIXER}.replaceAll(/[!?.]+$/).replacePart(', Part $1')}{'.'+lang} 2) I have working subtitles logins, etc 3) I bought a fresh license for Filebot The docker runs one iteration about 50% of the time, but invariably ends up throwing this in the log (and stops working): Full log is attached with a few batches of test files in the log. Has anyone else seen this issue? amc.log