mason

Members
  • Posts

    95
  • Joined

  • Last visited

Everything posted by mason

  1. Sorry I have no idea how docker on the Synology works... for the normal container you can just start it with: docker run -p 5800:5800 -p 5900:5900 -v /path/to/config/folder:/config/xdg/config/kvibes -v /path/to/media:/movies -e PGID=1000 -e PUID=1000 mediaelch:latest You need to set the options and environments similar to this on the NAS I guess... make sure you have the right user and paths...
  2. Updated to latest MediaElch Version 2.8.18
  3. Upgraded to latest version 2.8.16
  4. yeah i know, but there was nothing running and nothing accessin it afaik. anyway, that rebuild was successfull without any errors now. thanks for the moral and tech support it's weird what issues cabling can cause, you'll never notice until you run something like unraid. so in conlusion: it looks like the issue was caused by a faulty breakout cable
  5. Yeah I know about the inner and outer sectors of a hdd. Right now, it looks like it sorted itself out, array is back to quiet mode and up to the proper speed. Dunno what happend or what might run in the background causing this... *fingerscrossed* Thanks for your reply!
  6. So I replaced the breakout cable and tried another rebuild of disk18, so far it is running. But the speed seems way slower, before maybe 150mb/s compared to 80mb/s now and the array "sounds" different... it "grinds" any idea whats the issue there? could this be the "quality" of the cable?!
  7. of course, but I'm planning on replacing more with 14tb
  8. Rebuild finished with the errors overnight. How do i start another rebuild on that disk? edit: found that part in the docs. Just ordered a new breakout cable for that hba and will rebuild disk18 again I guess. It was replace since it was an old one with some udma errors. and yeah I know, dual parity would be adviced, but there is nothing on that server that is irreplaceable. Also I would need another 14tb disk.
  9. I'm currently in the process of replacing disks in my server. While replacing a 4tb disk18 with a 12tb. Disk3 threw a ton of read errors but stayed online. I had issues with that disk prior to a parity where it would go offiline, after swapping the cable on this one I was able to rebuild disk3 successfull to get it back online with a valid parity. For my understanding right now i can't trust the disk integrity of the rebuld disk18, correct? What would be the proper steps to ensure data integrity there? should i swap back disk18 for the old one, make a new config and replace and rebuild disk3? rebuild didn't finish yet, bit I'm beyond the 4tb mark for the disk i replaced. spacehog-diagnostics-20210918-2210.zip
  10. there was a bugfix release today 2.8.12. .. no issue of the container. image is updated.
  11. Updated to the latest release 2.8.8 also using the version as docker tag to makes things easier Seems like the ppa failed for the base image... need to have a futher look Edit: PPA was fixed and new image pushed
  12. Updated to the latest release 2.8.6
  13. Updated to the latest release 2.8.4
  14. Need to have a deeper look it seems... the ppa and base image used aren't updated. will see what i can do since I'm by far no expert. edit: okay simple enough... updated to new version
  15. I have no problem with tv shows... api might be done, happens from time to time.
  16. Support for MediaElch docker container Application Name: MediaElch Application Site: https://www.kvibes.de/mediaelch/ Docker Hub: https://hub.docker.com/r/masonxx/mediaelch Github: https://github.com/mason-xx/docker-mediaelch Support tool for you media collection. Manage all your movies, tv shows, concerts and music. Import new files and automatically rename them. Scrapers - MediaElch comes with many scrapers including The Movie DB, The TV DB, IMDB, fanart.tv, The Audio DB and many others. Kodi - MediaElch creates nfo files for use with Kodi. Because of extensive configuration options other media centers are supported as well. Mostly based on https://github.com/Giftie/docker-mediaelch just fixed up an unraid template and some smaller settings. Bare with me, I'm pretty new to these things. Thanks. Post any questions or issues relating to this docker in this thread.
  17. Okay, some hours and 4 million tabs and stuff later.... here is a working version. https://hub.docker.com/r/masonxx/mediaelch I also made a template xml file.. but I'm not sure how to get this working. Do i need to host this on github to be able to add it as a repository? It didn't work with my local webserver... Feel free to give it a spin.. just add it to your template directory: /boot/config/plugins/dockerMan/templates-user mediaelch.xml
  18. Woohoo I won something. Never happened before.. thanks you guys I'll put it to good use
  19. Exactly what I am seeing, good to know where it comes from. Again, thank you for your excellent support.
  20. Great explanation thank you. Yeah I would loved to move to xfs, but since I only always replaced discs with rebuilds I never had the chance. Will defiantly start converting when I'm sorted initially now and have a better confidence. Any more explanations on the performance issue on fuller disks? I have hickups since ages, since my disks are always 99% filled. Sometimes browsing smb takes 30 seconds while more than one file operation is going on...
  21. Thanks I did that, but for my understanding. Why does this happend if the rebuild starts proper from the beginning and does finish without errors? This is the output of the check, It told me to repair the superblock. Then i did another check, which told me to rebuild-tree. I did that too and it came up with a handful of damaged files, no loss there. So far array looks fine. Can I be confident to go from here? I'm still a little estranged about the whole thing. Guess for any further step I'll wait for the replacement LSI controllers... and might switch to xfs in a longrun. thanks for your help so far Johnnie rebuild-sb: wrong block count occured (2929721331), fixed (2929721328) rebuild-sb: wrong bitmap number occured (1), fixed (0) (really 89408) Reiserfs super block in block 16 on 0x901 of format 3.6 with standard journal Count of blocks on the device: 2929721328 Number of bitmaps: 0 (really uses 89408) Blocksize: 4096 Free blocks (count of blocks - used [journal, bitmaps, data, reserved] blocks): 1955597332 Root block: 27832367 Filesystem is NOT clean Tree height: 5 Hash function used to sort names: "r5" Objectid map size 790, max 972 Journal parameters: Device [0x0] Magic [0x3036d1ad] Size 8193 blocks (including 1 for journal header) (first block 18) Max transaction length 1024 blocks Max batch size 900 blocks Max commit age 30 Blocks reserved by journal: 0 Fs state field: 0x1: some corruptions exist. sb_version: 2 inode generation number: 39385 UUID: c4f3b705-32f7-4d13-b095-ccb010fe7975 LABEL: Set flags in SB: ATTRIBUTES CLEAN Mount count: 632 Maximum mount count: Disabled. Run fsck.reiserfs(8) or use tunefs.reiserfs(8) to enable. Last fsck run: Never with a version that supports this feature. Check interval in days: Disabled. Run fsck.reiserfs(8) or use tunefs.reiserfs(8) to enable. ---- reiserfsck --check started at Sun Sep 16 07:15:45 2018 ########### Replaying journal: Replaying journal: Done. Reiserfs journal '/dev/md1' in blocks [18..8211]: 0 transactions replayed Checking internal tree.. finished Comparing bitmaps..Bad nodes were found, Semantic pass skipped 1 found corruptions can be fixed only when running with --rebuild-tree ########### reiserfsck finished at Sun Sep 16 08:25:10 2018 ########### Zero bit found in on-disk bitmap after the last valid bit. block 8211: The number of items (8) is incorrect, should be (7) the problem in the internal node occured (8211), whole subtree is skipped vpf-10640: The on-disk and the correct bitmaps differs. ---- Will rebuild the filesystem (/dev/md1) tree Will put log info to 'stdout' Do you want to run this program?[N/Yes] (note need to type Yes if you do):Yes Replaying journal: Done. Reiserfs journal '/dev/md1' in blocks [18..8211]: 0 transactions replayed Zero bit found in on-disk bitmap after the last valid bit. Fixed. ########### reiserfsck --rebuild-tree started at Sun Sep 16 09:01:46 2018 ########### Pass 0: ####### Pass 0 ####### Loading on-disk bitmap .. ok, 974123999 blocks marked used Skipping 97618 blocks (super block, journal, bitmaps) 974026381 blocks will be read 0%block 8211: The number of items (8) is incorrect, should be (7) - correctedec block 8211: The free space (64) is incorrect, should be (1256) - corrected ....20%....40%....60%....80%....100% left 0, 54896 /sec 12542 directory entries were hashed with "r5" hash. "r5" hash is selected Flushing..finished Read blocks (but not data blocks) 974026381 Leaves among those 964911 - corrected leaves 1 pointers in indirect items to wrong area 2 (zeroed) Objectids found 12558 Pass 1 (will try to insert 964911 leaves): ####### Pass 1 ####### Looking for allocable blocks .. finished 0%....20%....40%....60%....80%....100% left 0, 115 /sec Flushing..finished 964911 leaves read 964818 inserted 93 not inserted ####### Pass 2 ####### Pass 2: 0%....20%....40%....60%....80%....100% left 0, 0 /sec Flushing..finished Leaves inserted item by item 93 Pass 3 (semantic): ####### Pass 3 ######### ... [..]: The file [2 1723] has the wrong block count in the StatData (2290624) - corrected to (2290608) [..]: The directory [2 1720] has the wrong block count in the StatData (6) - corrected to (3) vpf-10650: The directory [2 1720] has the wrong size in the StatData (2624) - corrected to (1504) Flushing..finished Files found: 12165 Directories found: 379 Pass 3a (looking for lost dir/files): ####### Pass 3a (lost+found pass) ######### Looking for lost directories: Looking for lost files:5 /sec Flushing..finishede 0, 0 /sec Objects without names 13 Empty lost dirs removed 2 Files linked to /lost+found 13 Pass 4 - finished done 644856, 77 /sec Deleted unreachable items 2 Flushing..finished Syncing..finished ########### reiserfsck finished at Sun Sep 16 18:45:38 2018 ###########
  22. The rebuild just finished fine, without a single read error. Unfortunatly after a reebot the server is still showing drive1 as "unmountable no filesystem" like in the screenshot above, could this been an issue due to the 2 failed rebuild??