dd?

I’m not sure that there is much for actual server side support for cross posting just yet, but there is a way, at least on the web UI: if you click the two overlapping squares under you post title, it’ll open a new post with a link to the previous post and its content quoted underneath. It feels more like a work around for cross posting, but it does work.

I was referring to Rule 3 of the community:

3. Not regarding using or support for Lemmy

TL;DR: There is no singular answer to your question, imo. Essentially just run the instance transparently, reliably, and actively, and it will be attractive to people.

I’m not sure that there is one “best way” to grow an instance. An instance is essentially the fundamental governing framework for how the users interract with each other. You structure the rules around how you believe the users on your instance should interact, and those who agree with those rules will be drawn to them. Ideally, for sustainable growth in an instance, you also need reliable server infrastructure – the instance should be responsive, and have a reliable uptime. An instance’s admins must also actively moderate content. An instance with inactive moderators is not sustainable, and will quickly delve into hosting unwanted content on the instance which is undesirable for users.

This post possibly violates Rule 3 of !asklemmy@lemmy.ml.

Flatpak – It’s not without it’s own issues, of course, but it does the job. I’m not fan of how snaps are designed, and I don’t think canonical is trustworthy enough to run a packaging format. Appimages are really just not good for widespread adoption. They do what they are designed to do well, but I don’t think it’s wide to use them as a main package format.

I’ve heard that ReFS is supposedly replacing NTFS, on Windows.

For your reference, please see the updated post. I ran a S.M.A.R.T test, and the drive is indeed borked.

Thank you very much for all of the extra information!

I ran a S.M.A.R.T short test, and, yeah, the hard drive is quickly dying:

=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: FAILED!
Drive failure expected in less than 24 hours. SAVE ALL DATA.
Failed Attributes:
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  1 Raw_Read_Error_Rate     0x002f   001   001   051    Pre-fail  Always   FAILING_NOW 1473

That disk certainly isn’t healthy.

For my own future knowledge, what, exactly, in the logs, led you to that conclusion?

image the whole thing with ddrescue

Since you mention “image”, I’m assuming that I would need a drive at least equal to the size of the source drive to store the image? The issue is that the source drive is 2TB in size, so I would need to source another 2TB drive (at least) to store the image.

Unfortunately, I cannot rename the files (extraneous reasons out of scope here).

If its only one season you could manually name them S01E01 etc.?

Unfortunately, I cannot rename the files (extraneous reasons out of scope here).

Whats the reason it doesn’t identify it?

I’m assuming becuase it doesn’t follow the format of S1, S2 etc for the first season. The show that I have has the first season self titled, then the other 3 are numbered in the proper way.

Did jellyfin wrongly identify the series as a version of it that doesn’t have this season?

Very interesting idea! But, unfortunately, no I don’t think that is the case here, as it’s the first season that is not being identified with the last 3 are being identified just fine.

Unfortunately, I am unable to downgrade to LTS. I need the latest kernel version for a my WiFi card (I’ve had a ton of annoying driver issues with this specific card that seem to now be fixed in the latest few kernel updates).

Nothing logged.

I have the exact same issue. I’ve never been able to see any errors in the logs. Essentially just says “going to sleep” then that’s it.

Using Nvidia with closed source drivers by chance?

No, I have an AMD GPU.

some hardware specs might help others with assisting you.

Noted! I’ll update the post.

Ah, dang, yeah that would do it. Thank you!

It appears I have misread the stack exchange posts I was looking at. I thought I read that they said that chown, by default, traverses the symbolic link, but, in actuality, what they were saying was that it, by default, changes the ownership of the target file of the symbolic link.