I don’t know the answer to your question, though I suspect it’s that Jellyfin doesn’t support menus.

What I’ve always done is rip each track to a video file. Jellyfin’s movie metadata DOES support extras: https://jellyfin.org/docs/general/server/media/movies/ and video formats like mkv support additional audio and subtitle tracks. With multi-track video format and extras support in the Jellyfin native menus… it’s possible to rip the vast majority of DVD content into Jellyfin. But ISO is not the preferred format to do it.

The main thing you’d lose here would be interactive menu features or choose-your-own adventure video codes into menus. Those DVD titles are pretty rare though.

VLC might have DVD menu support for ISOs, fwiw. I have a vague recollection it might, but I’m not at all sure.

That’s an interesting report but it’s possible to “work” at different latencies. And unless you have specialized audio capture/playback hardware and have done some tuning and testing to determine the lowest stable latency that your system is capable of achieving… “works” for you is likely to mean something very different than it does to someone who does a lot of music production.

It remains an interesting question to some users whether Wayland changes the minimum stable latency relative to X and if so whether it does so for better or worse.

I’d consider asking in a Linux audio or music production community (I’m not aware of any on Lemmy that are big enough to have a likely answer though). If music production is a primary use case and audio latency matters to you, almost no general users are going to be able to comment on the difference between X and Wayland from a latency perspective. There may not be a difference, but there might and you won’t be likely to learn about it outside of an audio-focused discussion.

It may seem kinda stupid to consider that an accomplishment, but I feel quite genuinely proud of myself for actually succeeding at this instead of just throwing in the towel…

Way to go. I’ve been at this a decent while and do some pretty esoteric stuff at work and at home… but this loop of feeling stupid, doing the work, and feeling good about a success has been a constant throughout. I spent a week struggling to port some advanced container setups to podman a month or so ago, same feeling of pride when I got them humming.

It’s not stupid to be proud of an accomplishment even if it’s a fundamental one that’s early in a bigger learning curve. Soak it in, then on to the next high. Good luck.

This is a crosspost of a post in a self-hosted community that isn’t mine. You’ll either have to at-mention OP to get their attention here, or comment in the other post they made.

But I can cover this particular question as well. The “trick” duo uses, is that is sends the 2fa request out of band to the duo app. So the flow goes like this:

1. Android app tries to connect to Jellyfin, gets a login prompt.
2. Android app collects username and password from user and sends it to Jellyfin as normal.
3. Jellyfin takes the username and password and forwards them to the ldap server to find out if the user is authorized.
4. The ldap server checks the username and password against it’s local DB and they check out… but it doesn’t respond to Jellyfin yet.
5. The LDAP server asks the Duo API for 2fa verification.
6. The DUO service sends a push notification to the DUO app, which prompts the user to see if they really are currently trying to log into Jellyfin or not. User taps “yeah, lemme in to Jellyfin”
7. Duo app tells duo service it’s go time.
8. Duo API tells LDAP server that 2fa check passed.
9. LDAP server tells Jellyfin the username/password lookup was successful.
10. Jellyfin tells the app the login was successful and things go normally from here.

So the trick with DUO, unlike say TOTP codes… is that the app is none the wiser that 2fa is happening. It thinks it just sent a regular username and password to the slowest damn Jellyfin server in the world that takes 30s to decide if the login is good. But as long as it doesn’t timeout the login, the 2fa happens completely transparently to Jellyfin and the app… with the verification happening in a separate app and being a manger by the LDAP server, DUO servers, and DUO app.

So yeah, apps should work as long as they can handle very slow logins.

The headline of the article is just The History of the Modern Graphics Processor, though. OP is having a fever dream with that post title, it has nothing to do with the article title or with the article.

Did the government invent OP to make us question Betteridge’s law of headlines? Has the law of headlines become too dangerous to ignore?

Why would you use LVM to configure the RAID-1 devices? Btrfs supports raid1 natively.

Two tips:

I have not tried running WINE yet but I plan on doing so soon.

Steam “just works” on Linux, you can install it via flatpak (which I use) or from their deb repo. It includes “Proton”, which is a fancy bundle of wine and some extra open source valve sauce to make it nice and easy to use. Any game that runs on the steam deck also runs on Linux via proton, and there’s no messing around at all. It looks and feels just like steam on Windows, and thousands of games just work with no setup or config beyond clicking the big blue and green buttons to install and run. Not EVERY games works, but tons do. I’d heavily recommend this over raw wine to a beginner.

The second tip is not to ask what you can do on Linux. The answer, to a first approximation, is that you can do everything on Linux that you can do on Windows or OSX. I daily drive all three, and mostly do the same stuff on them. Instead, ask YOURSELF what you WANT to do on Linux. Then Google and ask us HOW to do it… or what the nearest approximation is if the precise thing you want to do doesn’t work on Linux.

cc @iturnedintoanewt@lemmy.world, not sure if you get reply notifications on cross-posts, but some good advice a out your Jellyfin question over here.

Very true and good points, and when it comes to snap I mostly agree with you. I would guess the “war on Ubuntu” going on is more due to Ubuntu’s history of making controversial decisions that go against the grain of what most other distros are doing at the time (creating and dropping Mir, creating Unity instead of using GNOME and then switching back to GNOME when they finally got Unity working well, installing an Amazon app out of the box in one version), many of which angered a lot of Linux community members before who are still angry despite Ubuntu rolling back most of those decisions, and they’ve found snap a great current scapegoat issue to use to vent their long-standing frustrations with Ubuntu at.

I agree with just about every word here. I lived through all this stuff. Mir and Unity were hugely disruptive to the OSS desktop community beyond Ubuntu and I was as salty about them as anyone. If someone is aware of this history and just fucking done with Ubuntu’s bullshit they’ll get no flak from me. I rarely see this coherent an argument made though, it’s much more often “snap bad, use this other distro that’s downstream of Ubuntu and shares all the same foundations but has a different default desktop and disables snap by default”, which I think is pretty nonsense and is rampant in the comments of this post.

But I’ve done my share of distro hopping and if someone wants to use something else for any reason or no reason… more power to them. I will make the counterpoint that no one has to care about snap specifically and if you just pretend it doesn’t exist then your life will be no different. And if history is any indicator, snap has about 2y left before they abandon it anyway.

Tell me more about why I care that snap is setting up loop devices and not that docker is setting up virtual ethernet devices and nftables chains. System tools do system things, news at 11.

I say again, this impacts my life not at all and there is nothing easier to ignore than snap.

… those “pending update, close the app to avoid disruptions” popups are kind of disrupting.

I don’t exactly disagree that it’s slightly irritating but:

1. No one declares war on an operating system the way snap haters have over a “restart to update” message. It’s an irritation, but it’s not an irritation proportional to the response snap gets out of people.
2. Restarting to enable an update or complete an update is not something unique to snap. Except for a tiny number of very advanced live-patching systems like the one some kernel updaters use, every updater either nags you to shutdown to do the update, nags you to restart to finish the update, or doesn’t nag you and the update just doesn’t take effect till you restart (apt falls in this category and it’s not unambiguously better than nagging because you’re silently vulnerable when security patches are shipped until you restart). So again, this is just an extremely unremarkable thing that tons of updaters deal with similarly.

I do nothing.

• I use the Firefox snap. It takes like 800 extra milliseconds to start up on my 10y old laptop and it moves my profile dir. It otherwise impacts my life not at all and is just fine. If it ever bothers me, there PPAs, flatpak, or a dozen other ways to install Firefox that are all perfectly simple.
• I install other stuff from flatpaks or PPAs or using docker.

The angst around snap is inscrutable to me. There are 30 million easy ways to install software and they all work on Ubuntu. There is nothing in my life that’s easier to ignore than snap.

I haven’t used Tuxedo, but on apt-based distros it’s pretty common for an auto-update daemon of some kind to run in the background on startup to either download updates, or at least download package metadata so some UI component can start nagging you to install the updates that are available.

If you wait a few minutes, the download should complete and you can do what you want. You can probably get away with killing it, especially if you use a gentle signal like HUP. I wouldn’t risk it though… if you corrupt your package metadata or worse… and actual important package… it can be a significant hassle to clean up the mess. And the cost of waiting 30s-5m and trying again is so low it’s hard to beat that as an approach.

If its happening a ton you can probably find and disable the auto-update thing but I don’t know what it would be on Tuxedo.

Old thread, but I just figured out what lead me to my confusion about Jellyfin filename/episode-names and wanted to follow-up for posterity.

The problem was that my episode names had something that looked like a year in them, and that was throwing the filename parser into some confused state:

stuff 2020 - s01e01 - episode name parses to an episode name of simply stuff, presumably because the year disorients Jellyfin. All the rest of the filename is omitted from the metata episode name, which isn’t fun.

s01e02 - episode name results in Jellyfin using the full filename (without the suffix) as the episode name as desired. Other formats can work as well, the important part is that 2020 has to be removed.

Anyhoo, thanks for pointing me in this direction, I’ve got a naming convention I’m much happier with now.

If it works it counts no matter how dumb you feel. Glad it’s sorted, good luck and have fun.

I don’t have great suggestions for improvement, but I can verify that I sometimes have to flip around between players to get a particular video to work properly. It’s rare that I have to go all the way to VLC, but your report doesn’t flat out shock me. Some ideas:

• Try https://github.com/jarnedemeulemeester/findroid as an alternative. I have both installed and flip back and forth between the official player and findroid. They’re both nice. Findroid may have different nuances in codec support though and maybe they’ll play in your favor.
• Fiddle with any hw/sw decoding settings you can find.
• Fiddle with the transcoding settings (sounds like you have… but try all the options)
• If necessary, reencode the file on disk on the Jellyfin server… at least as a test to see if you can get ANY codecs to work reliably.

I use both apps all the time, and I’d generally say they work great. But occasionally I get a weirdly encoded file I have to mess around to get to play on mobile. I haven’t tracked which codecs cause trouble though.

I don’t have a link handy, but I saw this reported before and when someone went to lemmynsfw to check the posts, they actually had been properly marked as nsfw.

My unsubstantiated theory is that federation is working pretty crappily right now and so lots of federation messages get dropped. When a new post or comment gets dropped you don’t notice because… well… you don’t see anything. But when a post makes it through and an edit gets dropped, that can be more visible.

So likely what’s happening is that on some small percent but medium absolute number of lemmynsfw posts, someone makes an honest mistake and fails to tag it. They either notice themselves and fix it, or a mod asks them to and they comply… so on lemmynsfw it looks right. But the federation message with the edit gets dropped by your instance, and for you and others viewing from there it forever remains sfw in error, even though all the right steps were taken. I’ve also heard mods discussing this happening with post removal moderation actions, the post gets removed on the community’s home instance, but the federation message containing the removal gets dropped by some big instance and the post blows up there anyway where the mods are actually unable to shut it down.

I don’t think there’s anything anyone can do about this other than maybe the lemmynsfw admins tuning their federation worker counts (though they may have already and that may no longer be needed in recent Lemmy versions), or the Lemmy devs working on federation scalability so a larger percentages of federation messages get reliably delivered.

This isn’t a terrible idea, but it’s also important to understand single-user and tiny invite-only instances as analogous to “leechers” in the torrenting world. The federation load that an instance instance imposed on other instances depends much more on the number of communities it subscribes to than the number of active users. If a user stops using Lemmy but leaves their instance up, it’s generating federation load for no reason.

Tiny instances are inefficient, and while it is desirable for the network to be able to scale to the point where it can reasonably support lots of them anyway, right now federation queues are backed up and messages are frequently getting dropped. Encouraging lots MORE tiny instances is probably not the efficient thing right this second. Rather, we’d want more users joining mid-sized instances that are not overloaded locally and that are making efficient use of the federation load they generate by using it to serve 100-1000 users rather than 1 or 2.

Liability is not binary. There is a qualitative change in risk as you transition from “I subscribed to 100 actively moderated communities that I read and am familiar with” toward “I subscribed to everything there is including the worst of the worst and I didn’t realize I was doing so and don’t look at the results”.

Also, moderation activities federate. So even if a rogue poster does “contaminate” the actively moderated communities on a well-admin’ed instance… when those mods and admins delete the offending material they’ll automatically cleanup your instance as well. As a result, it’s the creepy crawly communities that don’t clean up or don’t want to clean up that generate the lion’s share of risk.

Is it 100% safe to sub to well-moderated communities, no. You have to know your local laws and protect yourself. Do you do yourself favors by running lemmony? Also no. These two statements can be simultaneously true.