Leaderboard

Updated the links since the ones in the OP are no longer working... (Yes I had nothing else to do )

App name: NowShowing v2 Docker Hub: https://hub.docker.com/r/ninthwalker/nowshowing/ Github: https://github.com/ninthwalker/NowShowing Wiki: https://github.com/ninthwalker/NowShowing/wiki (A lot of good info) The NowShowing docker provides a summary of new media that has recently been added to Plex. You can select to have it generate an email and/or create a web page for your users to visit. NowShowing is the successor of the popular plexReport docker. The original brainchild of bstascavage (https://github.com/bstascavage/plexReport). Further developed by NinthWalker & enhanced by GroxyPod, NowShowing adds additional improvements and features in a friendly, easy to install docker. Note: v1 is still available, however all work and updates are being done on the new v2. It is recommended to do a fresh new install of NowShowing v2. New for v2: Same great Email/webpage as v1 All new Web Interface for settings and customization Library Filtering! Tautulli Statistics Integration New user Setup Wizard Announcement Emails Easy Plex token retrieval Most email providers supported BCC users instead of multiple emails Password protected with Fail2ban support On-Demand and Test reports Web Log Viewer Bug Fixes & Quality of life enhancements _________________________________________________ Installation: Preferred installation method: From the Community Applications 'APPS' section in unRAID. Install the new "NowShowing v2" app. You can also install by adding the following template repository: https://github.com/ninthwalker/docker-templates/

Problem with that is that if you don't create a new backup everytime the drive configuration changes, then you can potentially wind up in a situation where when starting the array writes will trash what unRaid *thinks* is your parity drive (but may in fact not be if you changed the parity drive with another and didn't re-backup) Because of this case, CA's backup doesn't save the super.dat file, but instead creates a text file with the current drive assignments (and since most people will run the backup weekly or so, it'll pretty much always be up to date)... (And nothing says that you have to have the backup destination in CA to be on the array (I don't) )

Sounds like the time to switch to Radarr if you ask me.

When both interfaces have "bridge" enabled, they are available to the VMs as br0 and br1. This would allow you to create a first VM attached to br0 for communication with one network, and create a second VM attached to br1 for communication with the other network. Both VMs can be set up to access shared resources as you wish.

if you installed the smc patch for 10.12.4, then you need to remove <qemu:arg value='-device'/> <qemu:arg value='isa-applesmc,osk=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx'/> <qemu:arg value='-device'/> <qemu:arg value='isa-applesmc,osk=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx'/> from your xml.

You only need to forward the ports the apps themselves might require. And there won't be many. Port forwarding is only used for the outside world to communicate with an app. Not for an app to communicate with the outside world. You never forward port 22 or 80. If you require ssh access outside your network use a vpn Sent from my LG-D852 using Tapatalk

Try hitting up @CHBMB for an actual guide. I know there's one floating around here that he uses..

First off, you are under attack from Vietnam, Russia, and Great Britain (damn brits). Take your server out of your router's DMZ. There is zero reason to have it in there. (Also make sure you set up notifications on your server. Fix Common Problems will alert you to any future attacks) The crashing: It started with this: Apr 17 09:15:21 APURVA-SERVER kernel: kernel BUG at fs/btrfs/ctree.h:1763! Apr 17 09:15:21 APURVA-SERVER kernel: invalid opcode: 0000 [#1] PREEMPT SMP Apr 17 09:15:21 APURVA-SERVER kernel: Modules linked in: xt_CHECKSUM iptable_mangle ipt_REJECT nf_reject_ipv4 ebtable_filter ebtables vhost_net vhost macvtap macvlan veth xt_nat iptable_filter ipt_MASQUERADE nf_nat_masquerade_ipv4 iptable_nat nf_conntrack_ipv4 nf_nat_ipv4 nf_nat ip_tables md_mod tun vmw_vmci bonding e1000e ptp pps_core r8152 mii coretemp kvm_intel kvm i2c_i801 i2c_smbus i2c_core ata_piix sata_sil24 intel_agp intel_gtt agpgart video backlight acpi_cpufreq [last unloaded: md_mod] Apr 17 09:15:21 APURVA-SERVER kernel: CPU: 2 PID: 27287 Comm: btrfs-transacti Not tainted 4.9.19-unRAID #1 Apr 17 09:15:21 APURVA-SERVER kernel: Hardware name: HCL Infosystems Limited HCL Desktop/DQ57TM, BIOS TMIBX10H.86A.0042.2011.0120.1116 01/20/2011 Apr 17 09:15:21 APURVA-SERVER kernel: task: ffff8803937dc500 task.stack: ffffc9000ee50000 Apr 17 09:15:21 APURVA-SERVER kernel: RIP: 0010:[<ffffffff812d406b>] [<ffffffff812d406b>] lookup_inline_extent_backref+0x3a1/0x53b Apr 17 09:15:21 APURVA-SERVER kernel: RSP: 0018:ffffc9000ee53b60 EFLAGS: 00010283 Apr 17 09:15:21 APURVA-SERVER kernel: RAX: 0000000000000032 RBX: ffff8803729f0af0 RCX: 0000000000003000 Apr 17 09:15:21 APURVA-SERVER kernel: RDX: ffffffffffffd000 RSI: ffff88026dcbf800 RDI: ffff88026dcbc000 Apr 17 09:15:21 APURVA-SERVER kernel: RBP: ffffc9000ee53c00 R08: 0000000000004000 R09: ffffc9000ee53b20 Apr 17 09:15:21 APURVA-SERVER kernel: R10: 0000000000000000 R11: 0000000000000003 R12: 0000000000000032 Apr 17 09:15:21 APURVA-SERVER kernel: R13: 0000000000003783 R14: 00000000000000b2 R15: 0000000000000000 Apr 17 09:15:21 APURVA-SERVER kernel: FS: 0000000000000000(0000) GS:ffff88041b280000(0000) knlGS:0000000000000000 Apr 17 09:15:21 APURVA-SERVER kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 Apr 17 09:15:21 APURVA-SERVER kernel: CR2: 00007ffe8284b020 CR3: 00000003b38e9000 CR4: 00000000000006e0 Apr 17 09:15:21 APURVA-SERVER kernel: Stack: All that can be dicerned is that the file system is btrfs. This limits the cause to either the cache drive or the docker.img You should Check Disk Filesystem on your cache drive. If that gets you nowhere, then delete the docker.img and re-set it up.

Remove the no modify flag -n

If enable disable array auto-start by editing disk.cfg on your flash drive (config/disk.cfg) and changing startArray="yes" to "no". Then start the array in maintenance mode and check filesystem on disk1 (md1):

Dear ninthwalker, Yet again, Thanks so much for your brilliant contributions to this community. Now Showing is alive and kickin' over here! Impeccable! -Jimmy

You can type: mover stop This will stop the 'mover' when it's finished coping the current file being copied. If there are unmoved hard links to files already moved, those will be copied as files instead of recreating hard links upon next run of the 'mover'.

Your course of action is to figure out which key is actually valid... Rename Pro1.key to be Pro1.key.bak, then reboot. If the array starts up fine then you're good to go. If not, rename the file back and rename the other file to Pro2.key.bak and you'll be good to go and FCP will no longer bitch and complain to you about that. Here's the reasoning behind the test (and why FCP complains about it) unRaid when it starts up looks at the key files and matches it up to the GUID of the flash drive. If there's more than one key then it looks at each .key file until it finds one that matches. That's nice and convenient, as if you have multiple unRaid servers, you can throw all of the .key files you are using onto each flash drive and never have to worry about which actually belongs to which server. The problem is IF you have multiple servers and multiple key files on the flash drive. (which are valid for the other server(s). If your flash drive happens to die, then the course of action is to copy over the contents from the dead/dying flash drive to the new flash drive, boot up unRaid, and transfer the registration to the new flash. But, you've got 2 perfectly valid (ie: not blacklisted) .key files -> which one does unRaid pick to transfer to the new flash (and blacklist the old one in the process). It doesn't know which flash GUID actually died, so currently it throws all the files up in the air and picks one at random. Which means that your other server(s) flash drive might in the process get incorrectly blacklisted. BTW, I've been informed that this process when the system finds multiple key files is going to change come 6.4

Yep got it working after using this. https://www.dropbox.com/s/1f39m1bew9uhyio/HDMIAudio-1.1.dmg?dl=0 Awesome. Thanks again :). Happy days, i'll update again if the GTX 1080 works, currently working with a GTX 950

My hunch was correct, it's the SAS2LP crashing. These sometimes help: -disable vt-d if you don't need it -check for a board bios update -use the controller in another slot (you should change it in this case anyway as it's in the x4 slot that shares the DMI with all other disks, I think you have an empty x8 CPU slot, it should be there for best performance) If none of the above helps consider getting an LSI controller.

Stop array, unassign both disks, start array, stop array, re-assign both disks in their original slots, start array to begin data rebuild and parity sync.

Like I said before since you rebooted we can see what happened, but SMART for both disks is OK and since they are both on a SAS2LP it could have been the typical SAS2LP issue. You can rebuild disk1 and sync parity at the same time using the existing disks, if there are issues again be sure to grab the diags before rebooting. PS. You're still on v6.2, you should update to latest release. PS2. Disk1 has a lot of UDMA_CRC errors: 199 UDMA_CRC_Error_Count 0x003e 200 001 000 Old_age Always - 11330 These may be old and unrelated but if this value continues to increase you need to replace that SATA cable.

No, you are supposed to go to Tools -> Diagnostics and post the zip, preferably after the problem but before rebooting, looks like you rebooted, but post them anyway so we can at least check the SMART reports.

You've had write failures to parity 2 and disk 1, so unRaid has disabled the disks. All the files are showing because unRaid is doing what it's supposed to do: emulating the contents of disk 1, and the surviving parity disk is still protecting the array. You should post your diagnostics before you reboot so that the community can see what led up to the dual failure, and advise on a course of action.

It would be interesting to see what % of the unRAID market need/want the additional features. While stability and security of my data is #1, if I couldnt add capabilities like I can now through docker (previously plugins), I probably would have moved to a new platform by now. VM's on the other hand, I have no need for at all. If LT had that info of what % of their clientbase want what, it would be interesting to map that against LT's combined development effort in those areas to see if it matches., No point putting 25% of Dev effort into VM integration of only 5-10% of the userbase use/want it.

Just add / edit an existing template and change the repository to be plexinc/pms-docker