How would jellyfin be able to tell whether the video files in a directory are movies or tv? What does going nuts actually look like, and what causes it?
Not OP, but I've run into similar instances of Jellyfin "going nuts."
Mixed media type libraries are depreciated and "broken" according to the documentation[1], which is fair enough, but sometimes this results in weirdness if a TV-show is also part of a franchise and has associated TV-movies (e.g. the Battlestar Galactica reboot, Futurama, or Breaking Bad). If you want to keep those movies on your file system in a folder with the other stuff from the franchise, Jellyfin often can't handle it. And it's not obvious to new users whether these TV-movies belong in a TV-shows library or a movies library.
I've also noticed it cannot handle additional layers of folders (i.e. for Genres) in TV show libraries, but it can handle that layer in movie libraries. Failure mode (the "going nuts") looks like those genre folders recognized as bizarre or obscure television shows, and nothing scanned the next layer down.
I haven't looked into how their scanning algorithms work, but it's definitely frustrating that there's not a button or feature to say: "No, Jellyfin, this is a folder, not a show or movie. Try scanning again on the subtree starting here."
Honestly, any software that either silently/automatically reorganizes a user's files and folders (not Jellyfin, but there are others that do this... even FOSS projects) or demands a specific meta-hierarchy on the file system is frustrating to anyone who deliberately keeps their files and folders well-organized.
I bit the bullet years ago and just have separate folders for the two, using recommended naming conventions.
I realised it doesn't improve my life, to care about folder structure and naming, so much that I insist on retaining it and hobbling the media browsing frontend. The media browser brings in massively more metadata than I would have personally collected and encoded into the filepath/filename, and makes it nicely hyperlinked and searchable. Screenshots, posters, backdrops, cast, director, ...
You may think differently. In which case, enjoy your UI being a series of nested folders.
I do have a minimal level of categorisation, e.g. I can have filesystem paths like /tv/comedy /tv/drama, and then I have one "TV Shows" library made of multiple paths, including both /tv/comedy and /tv/drama. So I see the categories but Jellyfin doesn't have to.
What I have for mixed media are Jellyfin's Collections, where I can mix together films, TV series, music, books on any given topic. That's not accounting for TV show "specials" which live with the TV show, if TheTVDB.com honours it thusly.
> I realised it doesn't improve my life, to care about folder structure and naming, so much that I insist on retaining it and hobbling the media browsing frontend.
There's no good reason for any folder structure to hobble a media browsing frontend. There are multiple frontends I've tried for my personal library of ebooks (mostly Humble Bundles of software/hardware books), and a number of those frontends have an option that's basically one book per folder (i.e. all identically named files in that folder treated as different versions of the same book... epub, pdf, etc) and folders above that can be whatever you want. BookOrbit[1] supports arbitrary folder hierarchies and Readest[2] supports at least one level of intermediate hierarchy.
In the context of existing software counterexamples, Jellyfin's delicate sensitivity to folder meta-structure is a regression from the baseline expectation. But I'd agree that ultimately folder naming requirements for the media items themselves makes good sense.
> In which case, enjoy your UI being a series of nested folders.
When the Jellyfin UI reflects those nested folders, I can tell it to only rescan a specific subfolder when I add a movie, rather than checking the whole library for new content. Folders and hierarchical structure are objectively useful, though our search-addled brains make that less obvious than it used to be.
> There's no good reason for any folder structure to hobble a media browsing frontend.
Sure, but what I'm saying is that it was a price I was willing to pay. I tried a lot of other media browsing software and they just didn't meet my needs like Jellyfin did. Could Jellyfin be more flexible? Sure. Does it need to be for me? Not at the moment. I'm getting the benefit right away, and might stand to get more benefit in future if it becomes more flexible on path/filename parsing.
> a number of those frontends have an option that's basically one book per folder
Jellyfin already supports that, but currently only for movies. Seems entirely possible it could do that for books or TV episodes too, if someone volunteers the time to land the server and UI changes for it.
> When the Jellyfin UI reflects those nested folders, I can tell it to only rescan a specific subfolder when I add a movie, rather than checking the whole library for new content.
Jellyfin supports realtime monitoring with inotify so it can see new/updated files as you add them, but this depends on the filesystem supporting it, and also I think it still has a bug where doesn't work on library directory paths that are symlinks.
Jellyfin supports nested folders (Books, Music Videos and Other library types support a folder view), but their limitations are apparent: no homogenous filtering/sorting display, and for Music Videos and Other, no metadata collection.
Are you sure? At least with Kodi for specials like Futurama you make a Season 0 with them that the scrapers understand. Seems like Jellyfin understands that too: https://jellyfin.org/docs/general/server/media/shows
I guess for Theatrical TV show movies like The Simpsons Movie it might be more complicated, but worse case you always create or edit your own NFO files with something like MediaElch and have Jellyfin use those.
I think it's better to have genres in the NFO files and not in the folder structure. A show or movie can easily fall into two or genres which is not going to get captured by a single folder.
Thanks. My collection has grown to the point where I'm considering adding some kind of front end to index/search/filter but this means that Jellyfin will not be an option. Probably I'll just end up hacking together some minimal custom solution.
I think the authors treatment of backdoors and exceptional access is a narrow focus.
We will certainly see “front door” access as various places have or are attempting to enact client side scanning, id verified online access, software root of trust remote attestation, and the general attack on e2e.
Taken together your identity tied to unmodifiable software, necessary to access the web or modern economy with client side scanning and no e2e … is a front door.
All this has nothing to do with ai, bugs, hackers or security vulnerabilities, let alone backdoors
I haven't compared it for perf, but at first glance this appears to be an LLM (text-only) while both binary and ternary bonsai 27B models are VLMs (where the vision tower and the adapter MLP weights are unquantized and kept in float16).
Same way drm works, it’s going to be in layer of hw/sw that you don’t have control over. We don’t have commonly have control on the cpu, chipset, uefi. And on the top side things like widevine on the application layer
Yea things like this make more sense when you model the Democratic Party mostly as controlled opposition for the actual uniparty outside of a handful of instances
Yup. Once you realize neither party actually cares about any of the top debated political issues (individuals do, but the party doesn't) but they thrust them in everyone's face day in and day out BEACUSE the country is divided neatly in half and they are emotionally charged: abortions, LGBT rights, gun control.
Let the plebs wear themselves out so money can be extracted and power can be used without any fuss.
I can understand the myriad reasons for why a company would be inconvenienced by that.
But on the other hand, it seems like a reason for me to never use the vendor
reply