I have always had issues with playing high bitrate BluRay remuxes, with HDR and DTS 5.1+ audio. Granted the last time I tried JellyFin was January 2025 so it is possible this has changed.
I've been using Jellyfin for roughly 5 years, most of my library are Blu-ray remuxes (50-100 GB) and I haven't had a single one fail to play. My setup is Apple TV with Infuse connected to a LG C9 with a modern Yamaha receiver.
Transcoding is a whole can of worms I chose to avoid by playing everything directly.
Infuse is the magic ingredient that avoids the codec/transcoding issues other people sometimes experience. It supports direct play of pretty much every possible video thx to its built-in codecs. I’ve been using it for 2 years and I don’t think I had a single case of transcoding. It is paid, but worth it IMO.
This is almost certainly a you problem. Tons of people play remuxes with Jellyfin.
I would check that your client supports the requisite codecs, and has a sufficient network connection. Or alternatively check that your server has enough horsepower (GPU or CPU) to transcode.
Are you sure the client and the server are powerful enough? Do they support all required codecs? I have issues with 4k movies because my Jellyfin is served by a mac mini, and my client is an old Android tablet that doesn't support hardware decoding, but that is hardly Jellyfin's fault. Though they just updated ffmpeg to the latest version, so it might help.
It's something that's been bugging me for a while: once we reach a "good enough" small model, and qwen 3.8 27b is already getting damn close to it, does it make sense to just bake weights and everything directly into an ASIC, and use that for highly optimized inference? AFAIK only groq and cerebras are moving in that direction, and only to be providers themselves... It would be a dream to buy one for <$1k.
This is exactly what Taalas has already done, and the reason they got quickly acquired by AMD. Their chip runs Llama 3.1 8B at 17k tok/s, and even if llama 3.1 is dated, I can think of many problems I could use it for, especially at those speeds. They're certain to be working on a newer set of weights by now.
"Sean we forgive you" became a meme for a reason. The fact that to this day they keep working on the game is truly noteworthy; they could have called it quits at any point in time, especially after NMS got good enough.
Obviously it's not purely ego driven (if at all), so I wonder how the financial aspect plays into that narrative.
I suppose the fact that it sold so much throughout the years gave them enough runway to actually work on it with no worries? And I suppose that people would be skeptical of a new game launch by this studio, thus dooming them to work on NMS for eternity... we'll see how Light No Fire's launch will do.
That and I'm pretty sure they are using NMS as a backport target to test systems for Light No Fire (which is an instant buy for me, Hello Games have completely redeemed themselves in my eyes).
> so I wonder how the financial aspect plays into that narrative.
I've been wondering about this for a few years now. Do they really sell enough new copies of the game to fund development of several new expeditions a year? I suppose they must, but it's still surprising - more so as the years went on.
Honestly though, at a certain point, they could've started charging for the expeditions as DLC and I wouldn't have even complained.
I wonder if the ports play a role in getting additional updates over the years. Every year or so, NMS gets a port to a different platform, with a sales bump, and maybe part of that process includes adding just a little bit more to the base game.
at this point, i think they continue because of the goodwill it builds. as the other comment says, light no fire will be an instant buy for me because of the support they've given no mans sky over the last decade
Programming, as in manually typing the code, is a means to an end.
While I do enjoy coding, building things is what was rewarding, not actually laying down brick after brick after brick after brick.
I've done that for 10+ years. The fact that I don't have to do that anymore is a relief that cannot be overstated. I only have to check on the code that The Ideal Intern produces while I focus on what actually matters, and that is: Building The Thing.
It's all about how you use it and how careful you are with it, and the fact that today there are people IN THE FIELD that still question this baffles me.
Soon you won't be doing anything. At best you'll just be a bag of meat attached to automated processes you don't understand in order to take legal liability for it.
Literally a scapegoat, except of a different species.
That would be an interesting legal case. I would expect it to lead to negligence on the part of the employer for lack of training, etc rather than attach to the employee pressing the button.
Are employees usually liable for process-related issues? Like individual employees weren't liable for dispensing too-hot coffee but McDonalds was liable. Or how cops aren't liable in their individual capacity if it was a failure of training, etc.
For instance: give John the job of monitoring the HR AI so it isn't racist. To do that he needs to do impossible task of checking 10,000 automated resume evaluation decisions per day. No one can do that, so eventually he just approves them all.
Then if the system is determined to be super racist, you proceed to blame it on John, and fire him for being negligent and not doing his job. You put out a press release, and hire Steve into John's role. Your decisive actions show you're taking the problem seriously and the company isn't to blame.
As is so often the case SMBC has already got a comic for this. I sincerely regard Zach Weinersmith (and also separately Randall Munroe) as two of the most pertinent voices in modern philosophy.
Gemini is the only LLM I've ever experienced that decided on its own to tell me that something was a bad idea. Which, ok, in itself it's not a bad thing, we actually need more of that instead of the pathological sycophancy that all current models suffer from.
But in a physical robot? Yeah, that thing is going to punch me in the face, eventually. Or worse.
I use Sonnet and Opus everyday. Believe me, it's very common they tell me that something is bad idea, write a rationale and suggest better solutions.
Gemini doesn't remember almost anything after 2-3 follow ups. I have to paste the same "system prompt" at the top of each message and it still doesn't understand it.
Basically all of Big Tech is betting it all on Red that this whole AI business pays off before they end up losing everything. And I get it, it would be unwise to stay behind and ignore what could very easily turn out to be humanity's greatest invention since pizza. But still, is there seriously no other way to go about it instead of collectively running head first, hands behind at a breakneck pace, while risking the complete collapse of ... well, everything? I suppose not, especially considering it's a technology with potentially massive military and social impact on a global scale, or even beyond that if we're being particularly delusional. Though one has to wonder who will end up paying the tab, and I think that we all know the answer to that.
I’d argue that it's still ahead of a lot of modern systems.
Aside from the loading times, the thing is incredibly fast. I invite you to try one if you have the chance, as words don't make it justice. I can't think of anything today that comes close to how instantly it responds to user input, even iOS feels sluggish in comparison.
It had only a few kilobytes of memory, a bunch of CPU cycles and a dream, but By God they made damn sure not to waste a single instructions and it shows. We need to go back.
In case someone wants to see for themselves how "instantly" it really was. Skip to ~9:50 when it gets real sluggish.
Edit: if you don't wear nostalgia glasses, you can watch the bits of screen being redrawn piece by piece after something moves or a menu closes. Everything is flickering. Opening and closing a menu takes up to one second. The text being typed in the editor lags. This is not more responsive than a modern system, far from it. Obviously.
To give a corresponding example, try moving the mouse while loading from floppy disk on Windows 95, ten years later. The mouse pointer judders!
This does not happen on a 1985 Amiga, even with a fraction of the CPU power, which it needs all of it to redraw UI damage as seen.
The reason is that the Amiga system prioritised input processing above normal tasks, it had preemptive multitasking where hardware timers triggered a CPU interrupt to let the kernel switch to a new timeslice, and of course reading a floppy disk was done with hardware interrupts and DMA transfers because the OS knew exactly what hardware it was dealing with, while PC compatibles couldn't guarantee those transfer modes (https://wiki.osdev.org/Floppy_Disk_Controller) so Windows 95 would inevitably handle floppy drives with polling.
Windows 95 was hamstrung by DOS compatibility. If you installed OS/2, you could have butter-smooth mouse cursor movement even while formatting a floppy disk and running a DOS (or even Windows!) VM in another window. And if you had a XGA card (which no one did) you had a hardware mouse cursor sprite, just like the Amiga (except only one boring sprite and no cool audio/video tricks)
There were SCSI floppy drives. Rare, though. However, with the right controller, not necessarily Adaptek, and drivers for it, they enabled all of that, too.
If the Amiga's mouse-pointer sprite was removed and the pointer was rendered onto a bitmap, it would still be 50Hz. There is more than enough time to do that.
The flawless refresh rate comes from the fact the update is executed as part of a level 3 priority CPU interrupt triggered by the vblank refresh. Interrupt code reads the hardware register of a dedicated chip that has been measuring the mouse's potentiometers this whole time, to see how much they've moved. The mouse itself is a passive device.
It then sends a input event to Intuition, whose priority 20 input.device task (the highest priority task in any normal Amiga system) processes the event and updates the hardware sprite coordinates, but could equally write it onto the bitmap. It has the time to do that because everything else in the system waits for it.
Compared to a modern PC, which also uses a hardware cursor... the mouse is an active device and sends its own potentiometer readings as USB input events, which arrive to be processed by an independent USB subsystem in the kernel and is bundled with all the other USB traffic from devices attached on the same bus. A vblank interrupt couldn't get the mouse coordinates even if it wanted to.
I should correct myself here and say it's not potentiometers, but that the mouse has vertical/horizontal wheels that let infrared light through to detectors, and the hardware is counting a quadrature-encoded pair of pulse trains, so it can tell how many steps back/forward each axis has moved.
It also estimates that, if the hardware counters are sampled every vblank, it's accurate (no missed wraparound) for the mouse moving at up to 3km/h! But it's still possible to whip the mouse around faster than that, so action games might like to sample the mouse more often than once per frame.
Apple loved doing things in software, ever since Woz wrote the Apple II disk routines in software so their floppy drives didn't need their own controller (the Commodore machines had a whole second CPU running an operating system in theirs). This is also why the one thing that WOULD lag the cursor on a classic Mac was formatting a floppy disk, since it required interrupt-level timing.
Even to this day Apple loves running things in software - the speakers on modern Mac laptops are driven in software - macOS has a daemon that runs and adjusts the speaker volume, tracking the sound pressure sent to them to keep them from being blown out. When Asahi Linux added speaker support, they had to reimplement this from scratch.
I had a sidecar with my Amiga 1000, which allowed you to use an XT MFM hard drive + controller card for the Amiga side. Once kickstart + the software loaded, it was incredibly fast. It was weird having a full IBM PC + Amiga in one conjoined machine.
But I agree that predictable slowness is a thing. One only need to discuss traffic jams vs a 20 minute car trip without them.
Hence the caveat "Aside from the loading times," :)
The "instantly" refers to user input: clicking a button, typing, or moving the mouse was as fast as it could possibly get because of how close the OS was to the bare metal, with no fluff bogging down the experience. Simply put, there were no wasted frames, as there were none to waste. Nowadays, at the very least, you get a couple millisecond of latency. That was not the case here.
Also, this is a machine from NINETEEN EIGHTY F//G FIVE, and it's still probably faster than your average PC running Windows 11.
The GUI was fast because it was fixed layout, MUI on the Amiga was slow as well. We tend to go that way to get UI that is easy to create. You see the same in all GUI libraries the more CPU you have the more you use it.
MUI was slow because it was written in C and went all-in on BOOPSI, as well as supporting fully dynamic layout. It could likely have been faster, but the sort of people who paid for it were also the sort of people who bought CPU accelerators.
Also gp talks about input responsiveness (e.g. key and mouse input), and that has indeed much less latency on those old-school home computers than on modern systems where each input event goes through layers and layers of abstraction bloat before causing a visible change on the display.
Floppy based Amigas were incredibly clunky. Each file shown in the Workbench GUI has its own icon file (".info" file) which is loaded separately, resulting in additional time for each file in a "drawer" (Amiga folder.)
AmigaOS couldn't be described as a RTOS proper, not like QNX. For one, it had a forbid() system call which would stop the scheduler from pre-empting the current running process. It had no guarantees on latency, which is the essence of a RTOS.
It had a very simple static absolute priority scheduler and very little that could cause long pauses (like virtual memory), which made it much more predictable in scheduling than more sophisticated schedulers like in Windows, Linux, and MacOS. At one point I had an A1200 and a Linux Pentium 300-ish, and CD-writer on both systems. I could trust the Amiga to write CDs without creating a coaster every time, where the Linux box would succeed only 2/3 the time due to the unpredictable scheduling and it running the buffer dry.
So it wasn't a real RTOS, but it definitely behaved more like one that what we have now.
That particular tool's purpose was actually to shift the Amiga's very simple RTOS-like static priority scheduler more towards a more complex fairness-based scheduler like Linux/Windows currently has, making it less real-time than before. Yes, you could make rules that could elevate certain tasks by name matching automatically, giving you more control and predictability, but that's not something you couldn't already do.
reply