I love the top gear reference, but surely May would have been the obvious choice, Hammond is just asking for a crash!

I can’t see that log, the url appears to be truncated.
This is a weird one.
I assume your movie library in Jellyfin is targetted at the root? /media/Filme ?
I also assume you have your localisation set to french, have you tried temporarily setting it to us english and restarting the docker instance?
I’ve seen weird things happen if the docker instance starts before the mount, so if /data/Filme is a mount, it’s worth manually restarting your instance:
sudo docker restart jellyfin

Do you have nested libraries? Like a library pointed at /media and another one pointed at /media/Filme and maybe another at /media/Filme/Comedies ?
https://github.com/jellyfin/jellyfin/issues/8518

I’m pretty sure Firefox doesn’t know how to cast, that’s a chrome feature.
Secondly, a chromecast dongle can either be targetted locally by an app (such as chrome) or over the internet via https.
If you are just hosting on your windows laptop, you probably don’t have a domain with TLS, yes?
From localhost (the laptop itself), if you run chrome, you can probably cast to your dongle whilst on the same LAN.

If you have one of the newer Chromecasts with the remote, you can simply install the Jellyfin app on it directly, and address your Jellyfin install by IP and port.

Plex uses some fancy redirection work around these limitations, but it relies on an external service that they provide.

When you set up your libraries, it’s important that you point the path at the root folder, jellyfin expects a fairly specific naming convention.
Here’s how it is suggested to setup your tv shows for instance: https://jellyfin.org/docs/general/server/media/shows

Simplistically, lets say you have 2 shows called “Friends” and “The Witcher”, each with multiple seasons, and your NFS mount is /mnt/media.
You’d create something like: /mnt/media/tv
That’s where you’d point your tv library, at that “tv” directory. It doesn’t actually matter what the directory is called, but the library should be of type “shows”.
Under that /mnt/media/tv directory, you would create a directory for each show, and it would be the name of that show, so you’d get: /mnt/media/tv/Friends/ and /mnt/media/tv/The Witcher/
Then under those directories you would create seasons, to put your episodes in, ie /mnt/media/tv/The Witcher/Season 01/The Witcher - 01x01 - The End’s Beginning.avi
/mnt/media/tv/The Witcher/Season 01/The Witcher - 01x02 - Four Marks.avi

If you pointed the root of your library at /mnt/media/tv/The Witcher/Season 01/, it would probably fail to parse the episodes.
If you create your library as /mnt/media/allmystuff/ and just ram everything in there, it’s unlikely to find anything.
This may all seem a bit complicated, but there’s lots of tools that are useful to automate this process.
I personally recommend https://sonarr.tv/

If you are doing all of the above correctly, we’ll have to dig a bit deeper for more details.

As for “unsupported formats”, that most commonly happens when you have enabled hardware acceleration and it’s not working properly.
Whilst there’s several reasons why it may not be working, to rule it out, try temporarily disabling Hardware Acceleration under Dashboard -> Playback -> Transcoding.
The system should fall back to CPU transcoding which may be slow (hardware dependent), but at least it should function.

I don’t know if Leo cares about that anymore. He’s been saying he’s done with Twitter for a few weeks at least.

At least a year.

But in a recent TWIT (2 weeks ago maybe), all of the guest panelists admitted that they were all still maintaining their followings on Twitter and hopeful that they could move to Threads.

It’s all just whores being whores, which is what Elon is relying on.

The US (which is where I assume you are), has the second largest one in the world in current operation:
https://en.wikipedia.org/wiki/Bath_County_Pumped_Storage_Station

Short answer, it scales fine.
Now you need to find someone to pay for it.

The Back to the Future trilogy is good for a re-view.

I was on a customer site with a laptop and no internet access.
I tried to use my preferred diff tool meld to compare the current configuration file with the backed up copy and meld just wouldn’t start…
Turns out an update of windows had decided it was evil and removed it since I’d last used it, silently as far as I am aware.
This is straight up evil as far as I’m concerned.

I am now inspired to search for a way to disable that though.

Yes, but you would be seeing ALL posts from everywhere your instance knows about.

I kind of like the idea of being on lemmy.world, filtering to say aussie.zone and getting it to show me local.
Or being able to simply get a list of every community on another instance.

These are cool ideas.

Not that I’m aware of.
The information would certainly be in the database, but I don’t know how to access it.

I mean yes, but that’s not a federation problem.

To completely strawman AND slippery slope what you’re saying:

As a car safety pro, who primarily deals with car crashes:

STOP

TOWING

TRAILERS

Agreed, dangerous, I don’t want numpties doing it.
But it’s a large part of why I have a car.

I want to be clear, that I disagree with his “federation is stupid” point, but email has problems right now.

Theoretically it’s federated, theoretically you can spin up your own mail server and self host.

But even if you do that absolutely perfectly (SPF, DKIM, DMARC etc), you can falsely end up on spam list, that effectively block delivery of your email to large segments of the network for days if not weeks.

Whilst theoretically federated, email falls under the broad dominion of google, microsoft and a couple of other large players.

JavaScript (TypeScript) has access to cookies (and thus JWT). This should be handled by web browser, not JS. In case of log-in, in HTTPS POST request and in case of response of successful log-in, in HTTPS POST response. Then, in case of requesting web page, again, it should be handled in HTTPS GET request. This is lack of using least permissions as possible, JS should not have access to cookies.

JavaScript needs access to the cookies, they are the data storage for a given site.
To protect them, the browser silos them to the individual site that created them, that’s why developers haven’t been able to easily load cross domain content for years, to mitigate XSS attacks.
The security relies on the premise that the only valid source of script is the originating domain.
The flaw here was allowing clients to add arbitrary script that was displayed to others.
You’re dead right that only the way to fix this is to do away with JavaScript access to certain things, but it will require a complete refactor of how cookies work.
I haven’t done any web dev in a few years, this might even be a solved problem by now and we are just seeing an old school implementation. 🤷

I never owned a console, but I distinctly remember playing this, so there must have been a PC port some time in the early 90s.

Classic game.

The condescension in that makes it clear that the smug social network is whichever one the author happens to use.

20 years of professional developer experience and some outsider knowledge of what Facebook has done in the past.

I’m not a cheap whore Meta, I expect to get PAID.

I’m only one voice screaming in the darkness, but I want to be clear.
These are not risks. These are certainties.
And the only thing we can do about it is refuse to participate in their bad faith actions, for whatever good that will do.

Maybe the client is faster/prettier/can show videos/uses less data/integrates with their phone better.
Maybe it’s got features that clients here lack such as the ability to host larger images or video.
Maybe the user is sick of responding to conversations over there and it not being federated, so they are ignored.
Maybe using the Threads app is just faster (because it’s local instead of batch federating).

If I was in charge of product design for Threads, I would be literally crawling the issue listings for Lemmy/Kbin and the associated clients looking for complaints and implementing solutions for those problems.
Then I would make a list of every limitation within the system and make sure Threads exceeds that baseline.

And then when I had made the software better in every measurable way (because I am paying a large team of developers to target those pain points), I’d start adding features that ActivityPub doesn’t, especially if ActivityPub instances would find those features hard to implement.

I’d make damn sure that every time ActivityPub changes from a source outside Meta, I’d drag my heels on implementing that feature, so that instance hosts are forced to choose between implementing the new version, or maintaining compatability with Threads.

Why would a user here move there?
Because their spouse/coworker/friend tried to send something for the 50th time and the message just never came through.

Threads will mainstream threads.
Any good content here will be available to the Threads users, who will be oblivious to where it is coming from.
Eventually, Meta will take steps to break compatability, and lots of the most prolific contributors from here will move to Threads exclusively (for a host of valid reasons).
When it is no longer in Meta interest to federate, they will stop.

The fediverse will continue, but it will be weakened by it’s temporary reliance on Threads (who could afford to host large images/videos/etc, have lower latency, etc etc).

Individual instance owners can do literally whatever they like.
Put up ads.
Charge a subscription.
Anything.

Let’s say instance A is hosting a community that everyone on instances B and C love to participate in.
But A want’s to earn some money so they start charging access to their local users.
This doesn’t effect users of B and C at all, because the data is federated.
The owner of A get’s grumpy and defederates B and C.
The users on B and C find somewhere else, either on one of their instances, or on D.

Everybody wins.