Saik0Shinigami

I have a self-hosted instance running for about the past 3-4 years. But pulling new PO Tokens isn't working anymore so my instance is kind of broken right now.

To be frank, it's unlikely you'll get a running instance operational at this point unless something changes.

Edit: You have to rotate IP addresses when the PO Token problem happens. But it's a gamble if the next IP you get from your ISP will be allowed by Youtube.

18-24 credit hour semesters... and summer courses when available.

Since I knew virtually most of the program going in, course load in general was stupidly easy to manage. But I would not recommend it unless you really know the material/subject matter.

Edit: there was heavy incentive... GI bill pays for 4 years of schooling. I have a few months left of that 4 year period left of my GI bill... But if I didn't take everything accelerated, I couldn't get the masters. So I just went full ham on the curriculum.

Well I don't mean to harp on it... Plex in this instance is much better off. When provided proof of the problem they fixed it. Jellyfin has had issues about this going back to 2019... 6 years ago. Still no fix in sight. And the first ticket I linked proved the concept can be abused. With the issues getting hidden because "We're closing this because we're consolidating... oh wait... we're closing it because we're splitting the issues out." I've legit had people tell me that the problems were fixed because they saw the issue closed.

And now I hear that JF is even deprecating SSL and mandating proxy or esoteric custom config to implement SSL themselves again... Seems they're going backwards?

I had Jellyfin setup for just myself because I'd love to get away from the risk of Plex screwing shit up (and to get off their SSO). But the frustration of the dev responses to some of these issues and the fact that I'm literally the only person who's able to deal with the restrictions needed to keep it secure... I just turned it off. I didn't want to deal with managing two systems because my kids/wife/other family couldn't figure out how to use it.

others are about media access

Yup, and these are the biggest risks IMO. I find the well organized, big media companies with deep pockets and a few basic scripts that we know to work to be the biggest vector of liability.

https://github.com/jellyfin/jellyfin/issues/1501
https://github.com/jellyfin/jellyfin/issues/5415#issuecomment-2071798575 (and the following comments)
https://github.com/jellyfin/jellyfin/issues/13984

A person's biggest threat running Jellyfin is going to be the media companies themselves. Sony (the company known for installing rootkits on people's computers) can pre-hash a list of their movies with commonly config'd locations/name schemas for their content and enumerate your system for if you have their content. Since you don't have any authentication on the endpoint, they're likely not violating any law through circumvention. The "random UUID" is just the MD5 hash of the path/filename. So it's actually highly guessable... especially for people using default docker configs and *arr stacks and you normalize names using these tools.

Their response was "this attack isn't in the wild"(as if they actually know... running a script and checking a few hundred thousand requests to go through a list of movies isn't all that taxing and users won't even notice it to report it... let alone have enough logging to notice it to begin with) and "it breaks compatability, so we don't want to do it". Which I find laughable. It turned me off from Jellyfin all together.

Edit: And because every time I bring up the issue I get downvoted for "fear mongering"... There are answers to resolve it... you need to use non-standard naming schemes in your files/folder structure and fail2ban. But that expects users to do that... And I could do that... but it's a security risk non-the-less and the developers response to the risk being what it is is what's scary to me.

Edit2: The LDAP one... I should clarify I don't care about that one since well... requires you to additionally config stuff that most users won't. But the media exposure issues are default and universal and require setting things "non-standard" to have any protection from, which users generally WON'T do.

Yeah the API token exposure in the URLs is another thing... And that can expose itself in all sorts of ways.

Jellyfin is not intended for direct exposure to the Internet.

https://jellyfin.org/docs/general/post-install/networking/

There are multiple ways of exposing Jellyfin to the outside - the most common ones are:
forwarding its Ports directly to the internet (not recommended!)
forwarding through a Reverse Proxy
using a VPN connection to enter the Network
use a VPS to Reverse Proxy to your home network

Intended... not recommended. The reverse proxy one should also not be recommended until they resolve the unauthed endpoints issue as well really. Security is a weak point on Jellyfin in general.

I technically did... But I had prior experience to my college degrees. Also blew through 6 years of degree in 3.5. Turns out college is piss easy if you already have the real world experience.

Broad statements are misleading.

Ignoring the context of the discussion is even more misleading. In the context of this conversation, ISPs providing consumer connections and obtaining grant money, my statement is 100% accurate.

That’s how you get fiber into a building or between buildings.

You just said multimode can’t do significant speeds at distance, yet claim that buildings separated by distance would be connected with it? That logic doesn’t hold.

Intrabuilding or intrarack Yes, you’ll find multimode fiber occasionally. But even these rare cases are increasingly replaced by single-mode as costs drop and bandwidth needs rise.

Everything else (ISP deployments, backbones, FTTH) Single-mode fiber dominates. I haven’t seen a single ISP deploy multimode for consumer-facing services over a typical network radius (~hundreds of meters to kilometers). The only minor exception is MMF from the building network room to an apartment unit, which is irrelevant for this discussion and would be EXCEEDINGLY rare as most buildings would just copper line to the unit. But even in that case... the 20+km from the head end to the building counts for much more than the 20meters to the unit itself.

For all practical ISP purposes, single-mode fiber is what’s in the ground/on the pole, and upgrades are handled via transceivers, not ripping out the cable.

OM4 multimode won’t push 10gb at 500meters no matter how good your hardware is.

But just because you said it...

https://www.corning.com/catalog/coc/documents/application-engineering-notes/AEN075.pdf

and OM4 is suitable for distances up to 550 m

https://www.fs.com/uk/blog/om4-multimode-fiber-faq-highspeed-connectivity-guide-9499.html

OM4: Supports 10 Gbps up to 550 meters.

https://www.timbercon.com/resources/calculators/om1-om2-om3-and-om4-fiber/

OM4 Not specified 500 m* 150 m 150 m
*The IEEE has yet to officially give a distance for 10GBASE-S on OM4 fiber. The distances are decided by the IEEE in 802.3, not The TIA or ISO/IEC cabling standards. Some glass vendors say 500 m, but most are now quoting “up to 550m.”

You absolutely can run OM4 at 10gbps at or over 500m depending on your optics/laser.

But Multimode was never the point of discussion as the whole thread is based around broadband services (virtually none of it serviced by multimode, if any at all) and grant money for rural area coverage. Any fiber upgrade in this scenario will 100% be SMF with no qualifiers. In my past 30 years of IT career all buried and pole mounted fiber is SMF that I've ever seen for an ISP. I can tell you for certainty that ever fiber I've buried in the past 10 years for several companies has been SMF. I'm not even sure that I've touched MMF in the past 5 years even in intra-rack setups, I think I might have gotten some with a government auction win about 8 years ago I wanna say? With costs of SMF at near parity for the cable itself and getting closer every year in the modules... it's a dying form factor and was never really in use for ISP services to begin with.

The context of the discussion does...

SpaceX doesn't provide in rack or in-building connectivity.

SpaceX is an ISP. You wouldn't have an ISP running multimode.

It is true.

Multimode (what I think you're trying to reference) isn't used in distance applications at all, it’s only for short in-building links. Anything that your ISP would provide you would be single-mode. Carrier/Backbone is virtually 100% SMF as well. SMF (OS1 and OS2) don't really have a bandwidth cap. It's all transceivers not the fiber.

But the point is that fiber that ALREADY in the ground, you can upgrade simply by changing the transceivers. It doesn't matter the length, SMF/MMF, or anything else... you just get a transceiver rated for the length of run (power of the led/laser, and the optics). The length is irrelevant otherwise as the presumption is that the install in the ground has been shown to work in the past already.

Old standard ITU-G.652 single-mode has been made to push multi-petabit transfers in lab environments. The only change was the transceivers. And to be clear, ITU-G.652 was standardized in 1984. Nobody rips out the fiber from the ground (caveat is that the cable itself hasn't degraded). You just upgrade the optics/transceivers.

“It's not the fiber that’s limiting—ITU-T G.652 defines physical specs (dispersion, attenuation), not throughput. Field trials over 96.5 km of real-world G.652 fiber showed 56.5 Tb/s using advanced DWDM and modulation

source: https://arxiv.org/abs/2108.01873

And upgrading is piss cheap. Just change transceivers.

Same fiber cable that does 1gbps can do 100tbps.

https://flashpointarchive.org/downloads

Archiving flash games is not a new thing... Nor is Internet Archives pioneering anything here. Flashpoint is massive... And you can download all of them and play them at will.