• 0 Posts
  • 26 Comments
Joined 1 year ago
cake
Cake day: June 17th, 2023

help-circle

  • Side note. Don’t use hardware acceleration with TDARR. You will get much better encodes with software encoding, which is great for archival and saving storage.

    Use hardware acceleration with Jellyfin for transcoding code on the fly for a client that needs it.

    If you know what your client specs are, you can use TDARR to reencode everything to what they need and then you won’t have to transcode anything with Jellyfin.


  • You are correct that if you are on thee moon and have a cs-133 atom with you is second will take that many transitions. And if you do the same thing on Earth, a second will take the same number of transitions.

    But things get weird when you are on earth and observe a cs-133 atom that is on the moon. Because you are in different reference frames, you are traveling at different speeds and are in different gravity wells time is moving at different rates. This means that a cs atom locally will transition a different number of times in a second from your point of view on Earth vs one you are observing on the moon.

    And it would all be reversed if you were on the Moon observing a clock back on the Earth.

    They already have to account for this with GPS satellites. They all have atomic clocks on them but they don’t run at the same speed as clocks that are on the ground. The satellites are moving at a great speed and are further from the center of the earth than us, so the software that calculates the distance from your phone to the satellite have to use Einstein’s equations to account for the change in the rate of time.

    Relativity is weird.










  • I think that having a strong public domain is good for everyone. For instance properties like Sherlock Holmes really took off once it was in the public domain and people could write spin-offs and whatnot without worry that a copyright lawyer would come along and sue them.

    Linux is the same thing, Amazon using the kernel and stuff to build an OS on doesn’t take anything away from anyone else who uses Linux as a desktop or server environment, and in fact can lead to some good pass back, even if it is just that the devices are easier to root. Take a look at the Open-wrt project, where Linksys built their router on top of a Linux kernel and it led to a whole ecosystem of open routers. People went out of their way to buy a WRT-42G just with the intent of rooting it, and Linksys got their money either way.




  • When you get a new drive, you could move some of your library to it, like just the movies or tv or whatever. Then you only need to update one library.

    Are you using Linux? You could set it up to mount the new drive into the existing file structure. That way you would not have to change any configurations.

    It might also be handy to configure Jellyfin to save the nfo metadata with the media files so it doesn’t have to re match everything if the path changes.

    I definitely had data indexed at /Mount/driveA/movies and when I moved it to driveB it was a bit of a pain.

    In the long run you might want to invest in a NAS or something. That way you can just add more drives as needed.



  • The problem most of these examples and counter examples make is only showing simple code and assuming that you always want to apply the patterns of abstracting things or not.

    This is the real problem. Without context of what the project is for we can only speculate on what the “best practice” is. If my problem is that I have a directory with 2000 videos in it, and I need to process all the ones with an English language track, I am going to write a one-off bash script, and not a huge C# project filled with the OO concepts.

    But if the method is one of 10,000 needed in a huge project, then sticking with the coding guidelines of the whole project is more important for maintainability. A dev coming in 36 months later who is familiar with the code base would have less problems going through an abstracted setup, just because they have experience with the project and can make assumptions from that.


  • The code on the left is more readable. It is easy to follow and see what is happening at each step.

    That being said, the code on the right is easier to maintain. If the requirement comes down the pipe that we now need to support a new pizza topping it is easy to jump to the add toppings method using the IDE instead of scanning the entire monolith procedural function. Or if we now need to add support for take-and-bake, we can just modify the small entry method.

    This also assumes that we are not needing to reuse any of these methods. If you want to add toppings to a sandwich or a salad, better write another huge method like the one on the left, or add a ton of nested if/else or switch statements. If you use the style on the right you can reuse the add toppings method without worrying about if you should preheat the oven for a salad.

    The author chose a very simplistic requirement for an example and it is all well and good until you let it fester in a code base for ten years, with multiple interns maintaining it and end up with a huge spaghetti code monster to deal with.