Just seemed like a more appropriate fit. As I’m sure we’ve all thought about good ol’ JD eating house pets whilst in the shower. When we aren’t thinking about sultry couches, anyways.
Just seemed like a more appropriate fit. As I’m sure we’ve all thought about good ol’ JD eating house pets whilst in the shower. When we aren’t thinking about sultry couches, anyways.
I see we’re doing some better numbers over here in showerthoughts!
Why would I recommend Fileflows? It was a little more user friendly in my experience without requiring pulling in configurations from other sources. I know there are repos chalk full of Tdarr settings and configs, but for simple setups and DIY I preferred the Fileflows interface. The end result is basically the same, so pick your poison.
Isn’t AMD’s HEVC/265 still decent, specifically? I feel like I read that somewhere years back. 264 has always been a weak spot for them, however.
I might recommend fileflows over tdarr- but either way some kind of similar solution is almost mandatory with the grab bag of arbitrary encodings you find out there.
Software-wise, it seems that the relatively fast adoption of flatpaks and other containerized formats somewhat solves the typical dependency hell that was so common in Linux just a few years back (and to some extent still is an issue today depending on your distro and use case). The hardware support side is a little harder. That’s going to be up to vendors to play nice with the Kernel team and/or introduce reasonable userland software that doesn’t break the golden rule. Until Linux gets more market share the latter isn’t likely to happen. A nice side benefit of the emergence of immutable and/or atomic distros is that users can play around and try things with much lower risk of bricking their systems, so I’d also consider that a step closer in the “it just works” department.
Very true. But brute force checking through tons of different settings for each camera you need to configure is not fun. I couldn’t seem to find any kind of “known working configs” database or anything either. Every camera seems to be different in what it expects, outputs, authenticates, etc. Once it’s set up, I agree, maintaining the config is easier. Having all your cameras match in model and firmware version probably makes the whole endeavor MUCH easier.
AmCrest and Frigate together are SO good. Integrating Frigate with Home Assistant was also insanely easy for quick viewing and notifications. That initial Frigate config is a bit of a bear- but once you’re past that I cannot speak more highly of it.
hunter2
My friends and I all LOVED the pick-up nature of SG1. We’re all adults with busy lives, so hopping into a ~5 minute casual match was just so easy. And the casual nature made it feel like we could have success without “grinding” the game. I guess that is explicitly not the intent of SG2.
The shift from “we’re making a fun and relatively casual arena shooter with a neat gimmick and extremely rewarding fundamentals” to “we’re making a generic e sport shooter” was swift and, frankly, uncalled for.
Even with nvme drives which supposedly “don’t need” to use BFQ, I STILL always swap it since it maintains responsiveness across the system during heavy IO loads. I used to have similar full system freezes when downloading steam games which notoriously overload your IO in Linux. BFQ was the solution every single time.
Edit Try following the instructions detailed in this post to add a systemd rule to set the scheduler: https://stackoverflow.com/questions/1009577/selecting-a-linux-i-o-scheduler
The second answer that shows an actual rules.d file example has always worked for me. If using nvme or old school spinning rust you’ll need to change it up a bit. Instead of “noop” set it to “BFQ”.
Try swapping to BFQ io scheduler and see if that makes a difference.
Anyone who ritualistically buys Dell. I believe Intel is on the record as having called Dell “the best friend money can buy.”
Are you on Gnome, KDE, or some other desktop environment? I know KDE Wayland and Nvidia do NOT play nice (presently).
Are you running it through Lutris? Steam with Proton? That error seems decidedly like a Wine specific problem, which Proton should have ironed out at this stage for this particular game.
*Unless you’re trying to play on hardware with incomplete Vulkan support. Then it’s a hardware support problem that is unlikely to be fixed in a reasonable timeframe.
Ooooh okay. Yeah, I avoided the playstore version. I’m pretty sure I had read somewhere early on that the Playstore version would lack features or otherwise be behind in some ways due to complying with certain Google specific requirements to be allowed on the storefront. Kind of like KDEConnect.
I’ve got it opening YouTube links by default… At least from within other apps. In Firefox I can also hit “open in app” and it pops right up. Casting works too.
I’m going to assume it’s not Universal Blue… But parts of your description reminded me of it.
I believe it’s more a “the PS3 CPU architecture was an absolute nightmare and emulating it is difficult/slow” more than it had anything to do with the graphics rendering portion- which is typically where phones would have made the most substantial advancements. There are specific instruction sets that need to be supported by any CPU emulating PS3 to run anywhere near native speed… And I don’t believe much work has been done for ARM cpu’s to support the needed instructions in mobile devices.