sheppp

Members
  • Posts

    75
  • Joined

  • Last visited

Converted

  • Gender
    Undisclosed

Recent Profile Visitors

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

sheppp's Achievements

Rookie

Rookie (2/14)

0

Reputation

  1. An alternative way to do this without changing the static IP address on your UnRaid server is to go into your eero app, go to "Settings", "Network Settings", "DHCP & NAT", and click on "Manual IP". You can then do the following: -Ensure that your "IP address prefix" matches that of your old server (example: if your previous router's IP was 192.168.1.1, you should use the "192.168.0.0" default prefix for this eero setting). -Set the "Subnet IP" to that which was on your previous router (example: if your previous router's IP was 192.168.1.1, the "Subnet IP" in this eero field would be 192.168.1.0) -Set the "Subnet Mask" to 255.255.255.0 (the eero app default will likely be 255.255.0.0, but don't use it or you won't be able to save the eero app's manual IP configuration) -Set the "Starting IP" to that which your old router started with, PLUS a number which is more than the total of number eero devices that you plan to use (router and satellites). This is because the eero devices will automatically be given IP addresses starting with xxx.xxx.x.1 - and increase from there. (ex: if you plan to use 5 eero devices, you should set this "Starting IP" value ABOVE xxx.xxx.x.5 - I would set it higher than that in case you want to add more eero devices later. To be on the safe side, I would start at xxx.xxx.x.20, or in this case, 192.168.1.20). -Set the "Ending IP" value to the same number as your previous router ended with (example: xxx.xxx.x.254 or in this case, 192.168.1.254) -Click "Save", then "Reboot" when prompted - and wait several minutes. After this, you will see that you will be able to locate your UnRaid server by typing its old static IP address into your web browser. BTW, after being in the chaotically inconsistent and problematic Netgear Orbi world for many years, I have found the eero environment much, much more user-friendly and reliable. The eero Pro 6e night is still very young, though ...
  2. Thanks!! That worked. For those like me that don't work much in Linux and can't remember anything about what was previously "learned" about using it, I used Putty to telnet in and used the command: ' reiserfsck --rebuild-tree /dev/md10 ' to repair the file system on my 10th drive. I really appreciate the help from you (itimpi, johnnie.black, and Constructor)!
  3. I attempted to do this via telnet/putty with the command, "reiserfsck --rebuild-tree /dev/sdq" (where "sdq" is the Unraid-assigned name of the drive), however, I received the message, "Failed to open the device '/dev/sdq'". What am I doing wrong? Thanks.
  4. I ran the check and received this message: I have never run --rebuild-tree before. Does anybody have any suggestions re how to do/fix this? Thanks.
  5. I have had my Unraid server for many years with no major issues. Today, I found that I cannot write to my the server from any of my Windows machines. I get a "Error 0x8000FFFF: Catastrophic failure" whenever I attempt to do so - with my cache drive turned off on my shares (I can write to the server when the cache drive is on, however, my cache drive is not moving data onto the shares. I could, however, move files from my cache drive to a share via Midnight Commander. I checked the syslog (see attached) and found the following: "Sep 15 12:38:25 UR1 kernel: REISERFS warning: reiserfs-5090 is_tree_node: node level 15518 does not match to the expected one 2 Sep 15 12:38:25 UR1 kernel: REISERFS error (device md10): vs-5150 search_by_key: invalid format found in block 903401453. Fsck? Sep 15 12:38:25 UR1 kernel: REISERFS (device md10): Remounting filesystem read-only Sep 15 12:38:25 UR1 kernel: REISERFS error (device md10): vs-2140 finish_unfinished: search_by_key returned -2" and "Sep 15 12:56:14 UR1 root: Fix Common Problems: Error: Unable to write to disk13 Sep 15 12:56:14 UR1 kernel: REISERFS error (device md14): reiserfs-2025 reiserfs_cache_bitmap_metadata: bitmap block 753664 is corrupted: first bit must be 1" I have rebooted the server and NONE of the disks are red-balled. If you have any ideas re how to possibly resolve this, I would greatly appreciate it. Thanks. ur1-syslog-20190916-0321.zip
  6. You have to use ntfs-3g to write. I do it all the time. Unassigned devices works for this. I just formatted a drive in my Windows box with "plain" NTFS and transferred it to my UnRaid box. I then mounted it via the "Unassigned Devices" plugin as a non-array drive. After this, I mapped the /var/lib/mythtv/ location to the NTFS drive (in the MythTV docker/container) with no issues. For a non-Linux guy like me, it's fantastic because I don't have to mess with the Linux command line AND all of my recordings are easily accessible/playable/archivable via my Windows boxes.
  7. I finally found out what my problem was re not being able to record from the on-screen guide - and it was on my end. For whatever reason I never created a "Directory" in the "Default" group within "Storage Directories". Once I did this, I had instant success. I'm really sorry for wasting your time on this. Hopefully, however, somebody else will benefit from my idiocy. Thanks again for all of your help. Sparkly, at the risk of increasing the size of your already exploded skull, you are back to being brilliant. Sorry that I every doubted you!
  8. One of my MythTV problems has mysteriously cleared up with a simple reboot of my UnRaid box! I'm sorry that I didn't try that earlier. I now get livetv to transfer to my non-array drive. Thus, the only problem that I have left to resolve is why I cannot record via my onscreen guide. Again, live tv records with no problems AND I when I switch over to my other Ubuntu MythTV stand-alone box, I can record via the onscreen guide from it. I am utilizing Kodi on the same client computer (I merely change the IP in the Myth add-on), so I doubt that Kodi is the problem. Again, when I remote into the MythTV docker, I don't seen any recordings from the onscreen guide in any of the var/lib/mythtv sub-folders (the live tv recordings are there so I know that something is working). Thus, I don't think that it is a docker mapping problem. Regardless, here are my current MythTV docker mappings (the "disks/ST31000340AS_9QJ0MD34-part2" partition is my non-array drive): /home/mythtv /mnt/cache/.docker/myth/ /db /mnt/cache/.docker/myth/data/ /var/lib/mythtv /mnt/disks/ST31000340AS_9QJ0MD34-part2/myth/ Thanks in advance for any suggestions that you might have.
  9. Password: Linux 4.0.4-unRAID. Last login: Mon Aug 31 20:04:50 -0700 2015 on /dev/pts/0. root@UR2:~# ls -lah /mnt total 0 drwxr-xr-x 21 root root 420 Aug 31 20:04 ./ drwxr-xr-x 18 root root 380 Aug 31 20:03 ../ drwxrwxrwx 4 nobody users 32 Aug 30 15:13 cache/ drwxrwxrwx 7 nobody users 168 Aug 20 22:23 disk1/ drwxrwxrwx 7 nobody users 168 Apr 13 2013 disk10/ drwxrwxrwx 7 nobody users 168 Mar 1 2014 disk11/ drwxrwxrwx 7 nobody users 168 Apr 11 2014 disk12/ drwxrwxrwx 7 nobody users 168 Nov 21 2014 disk13/ drwxrwxrwx 7 nobody users 168 Aug 21 15:03 disk14/ drwxrwxrwx 3 nobody users 21 Aug 30 21:57 disk15/ drwxrwxrwx 6 nobody users 144 Apr 6 2014 disk2/ drwxrwxrwx 7 nobody users 168 Apr 6 06:51 disk3/ drwxrwxrwx 7 nobody users 168 Sep 28 2013 disk4/ drwxrwxrwx 7 nobody users 168 Apr 6 2014 disk5/ drwxrwxrwx 7 nobody users 168 Aug 24 2013 disk6/ drwxrwxrwx 7 nobody users 168 Mar 10 2013 disk7/ drwxrwxrwx 7 nobody users 168 Sep 7 2013 disk8/ drwxrwxrwx 7 nobody users 168 Feb 22 2013 disk9/ drwxrwxrwx 3 root root 60 Aug 31 20:04 disks/ drwxrwxrwx 1 nobody users 32 Aug 30 21:57 user/ drwxrwxrwx 1 nobody users 168 Aug 30 21:57 user0/ root@UR2:~# The "disks" drive is my non-array drive that I mounted with "Unassigned Devices".
  10. No problem. In the big scheme of things and life this whole virtual TV thing is pretty meaningless. Nonetheless, now that I'm into it this far, I'm determined to figure it out somehow. Many thanks for your valuable time and input.
  11. Yes, I re-formatted it last night as XFS and re-mounted it via "Unassigned Devices" - but nothing changed. It shows up as a separate drive when I go into my UnRaid box via Windows too. Yet, when I map to it via the Myth docker (by clicking in the box and navigating to it vs. manually typing the text, so as to avoid transcription errors), nothing transfers into it (which, because of my OS guide recordings issue, would only be my livetv files).
  12. Thanks CHBMB. I saw Saarg's TVHeadEnd docker post/thread, but it looked as if there were still some loose ends, so I decided not to mess with it. Besides, I was somewhat familiar with the Myth interface. Perhaps I'll have to re-consider - after I figure out Sparkly's "smooth talking beast" ways to buy me some more time at home ...
  13. CHBMB, my guess is that Sparkly likely has several tents - in addition to a sizable alimony payment - that he could loan to you. My stand-alone Myth box points to a separate drive as well. Are you using TVHeadEnd in a VM or a docker?
  14. Trurl: I'll post my latest mappings when I get home tonight PST (provided that I still have a home and family to go back to - after wasting my life away the past couple of days trying to figure this out). Thanks for the cmd line text - when it comes to Linux, I'm a bumbling idiot (which is partially why I originally wanted to format my non-array drive as NTFS because it simplifies things for me). Johnodon: Thanks much for your volume mappings. They give me something else to try. If all else fails, I'll probably have to place my recordings on the array as well (provided that I can get them to record properly) unless somebody comes up with a way to successfully point to a non-array drive. CHBMB: I'm using 6.0.1 (not any of the 6.1 RC versions). You are correct re suspecting a setting in Kodi (v15.1), however, I have Myth working fine via a separate Ubuntu box AND when I point back to it, I have no problems with recordings. BTW, I merely copied most of those settings into the docker version of Myth - although it's certainly possible that I screwed something up when I did it. Again, thanks much to all of you for taking your time to help me. It is appreciated more than you know!