CHBMB

Community Developer
  • Posts

    10620
  • Joined

  • Days Won

    51

Everything posted by CHBMB

  1. I don't use Plex and am on mobile atm so difficult to do much. It would probably be easier to roll back to a backup. If you don't have backups then I would definitely make some before you attempt any database repair. Sent from my Mi A1 using Tapatalk
  2. Post a screenshot of your Unraid Nvidia Page and a copy of your docker run command. Sent from my Mi A1 using Tapatalk
  3. So my Emby trancoding settings look like this. Do you have Emby Premiere?
  4. From someone that tries to support docker on both Unraid and Synology, my overwhelming impression is I wouldn't personally touch a Synology with a 10 foot barge pole. Closed system, weird docker implementation which we see lots of issues with that we can't seem to get to the bottom of.
  5. As a troubleshooting, you could try our container as that's the one we test with. Sent from my Mi A1 using Tapatalk
  6. https://support.plex.tv/articles/202796273-why-are-there-old-or-duplicate-server-entries-in-the-dashboard-sidebar/ It's because you've installed a different PMS container, Plex thinks you have two different servers.
  7. Not that I'm aware of. And you haven't really done much in the way of setup, probably as easy to nuke and pave.
  8. As an aside I know our container has some advantages that the LT version doesn't if you end up using hardware transcoding
  9. This is the support thread for the LinuxServer version of Plex, the run command you posted is for the LimeTech version of Plex. Depending on how you look at it, you're either in the wrong thread (Use the LimeTech support thread) or you've configured your machine incorrectly (You should be using our version)
  10. I think it's working fine now @saarg although the more I read it the more I'm getting confused.....
  11. More to the point, you're not even using the LinuxServer container 'limetech/plex'
  12. Great, thanks for letting me know And thanks for all the kind words people!
  13. This was an interesting one, builds completed and looked fine, but wouldn't boot, which was where the fun began. Initially I thought it was just because we were still using GCC v8 and LT had moved to GCC v9, alas that wasn't the case. After examining all the bits and watching the builds I tried to boot with all the Nvidia files but using a stock bzroot, which worked. So then tried to unpack and repack a stock bzroot, which also reproduced the error. And interestingly the repackaged stock bzroot was about 15mb bigger. Asked LT if anything had changed, as we were still using the same commands as we were when I started this back in ~June 2018. Tom denied anything had changed their end recently. Just told us they were using xz --check=crc32 --x86 --lzma2=preset=9 to pack bzroot with. So changed the packaging to use that for compression, still wouldn't work. At one point I had a repack that worked, but when I tried a build again, I couldn't reproduce it, which induced a lot of head scratching and I assumed my version control of the changes I was making must have been messed up, but damned if I could reproduce a working build, both @bass_rock and me were trying to get something working with no luck. Ended up going down a rabbit hole of analysing bzroot with binwalk, and became fairly confident that the microcode prepended to the bzroot file was good, and it must be the actual packaging of the root filesystem that was the error. We focused in on the two lines relevant the problem being LT had given us the parameter to pack with, but that is receiving an input from cpio so can't be fully presumed to be good, and we still couldn't ascertain that the actual unpack was valid, although it looked to give us a complete root filesystem. Yesterday @bass_rock and I were both running "repack" tests on a stock bzroot to try and get that working, confident that if we could do that the issue would be solved. Him on one side of the pond and me on the other..... changing a parameter at a time and discussing it over Discord. Once again managed to generate a working bzroot file, but tested the same script again and it failed. Got to admit that confused the hell out of me..... Had to go to the shops to pick up some stuff, which gave me a good hour in the car to think about things and I had a thought, I did a lot of initial repacking on my laptop rather than via an ssh connection to an Unraid VM, and I wondered if that may have been the reason I couldn't reproduce the working repack. Reason being, tab completion on my Ubuntu based laptop means I have to prepend any script with ./ whereas on Unraid I can just enter the first two letters of the script name and tab complete will work, obviously I will always take the easiest option. I asked myself if the working build I'd got earlier was failing because it was dependent on being run using ./ and perhaps I'd run it like that on the occasions it had worked. Chatted to bass_rock about it and he kicked off a repackaging of stock bzroot build with --no-absolute-filenames removed from the cpio bit and it worked, we can only assume something must have changed LT side at some point. To put it into context this cpio snippet we've been using since at least 2014/5 or whenever I started with the DVB builds. The scripts to create a Nvidia build are over 800 lines long (not including the scripts we pull in from Slackbuilds) and we had to change 2 of them........ There are 89 core dependencies, which occasionally change with an extra one added or a version update of one of these breaks things. I got a working Nvidia build last night and was testing it for 24 hours then woke up to find FML Slackbuilds have updated the driver since. Have run a build again, and it boots in my VM. Need to test transcoding on bare metal but I can't do that as my daughter is watching a movie, so it'll have to wait until either she goes for a nap or the movie finishes. Just thought I'd give some background for context, please remember all the plugin and docker container authors on here do this in our free time, people like us, Squid, dlandon, bonienl et al put a huge amount of work in, and we do the best we can. Comments like this are not helpful, nor appreciated, so please read the above to find out, and get some insight into why you had to endure the "exhaustion" of constant reminders to upgrade to RC7. Comments like this are welcome and make me happy..... EDT: Tested and working, uploading soon.
  14. Post your docker run command, link to this is in my signature, you may need to enable signatures on your forum setting. Sent from my Mi A1 using Tapatalk
  15. My feeling is if that warning isn't enough, then nothing can save them........
  16. I think this is resolved, we just need to be able to make the actual Nvidia build work now. No ETA
  17. See the post above yours tvdb changed their API Sent from my Mi A1 using Tapatalk
  18. You can't and we don't control the upstream driver version either. So you will have to play a waiting game.
  19. Yeah, I can see that, you offer it for half price maybe you get twice as many people buying. I don't work for LT, just a happy customer, like I said, historically there haven't been BF sales, so I wouldn't hold your breath though. Sent from my Mi A1 using Tapatalk
  20. Well, yeah, everyone who wants to purchase anything would like it cheaper, but historically Unraid doesn't normally do "sales", I think it's important to remember that LT is a small company, not a massive multinational, they got to put food on the table the same as the rest of us.
  21. It's never been on sale as far as I know, although when I bought my license in 2011 the pricing was a little different with the option to buy a second reduced price key, to cover for a potential USB stick failure as online replacement keys weren't a thing back then. I think the general consensus from the community when it's been discussed before is that Unraid represents good value for money at it's usual price and we have understood that has meant LT don't offer Black Friday deals.
  22. rc7 not building with the same issue as rc6. Waiting for some advice from LT If I don't post anything else, it's cos I don't have anything to add, no need to ask.
  23. You'd have to make your own proxy config file if we don't have one (I haven't checked) but in theory it should be possible. Although you don't need to for the VPN to work, just the VPN port forwards, the webui port can remain closed and only LAN accessible.
  24. OK, so identical to me, so things that might be worth looking at that could potentially be different. config.php nextcloud reverse proxy conf Nextcloud version (I'm on 17) Default file If you post I'll check, but I need a bit more to go on.