Oh absolutely, I agree with the best practice! I just didn’t know the real world efficacy of dropping packets near the NIC to mitigate DDOS load. There is certainly a performance limit but where that limit exists has been nebulous for me.
I recall a certain amount of overhead in IPTables “allow only from” situations but I’m not sure whether it’s enough to make a DDOS any kind of viable on a server in this configuration.
Do you happen to know how effective the strategy is?
Server admin here, you can do this in a way that avoids lemmy even knowing anything has changed. Read through all of this and do some googling first if you don’t know the specific commands to use!
First, you need to set the remote volume to automatically mount correctly on system restarts. On Linux, this is done by adding an entry for it to /etc/fstab if one does not exist already. Once done, ‘mount -a’ will mount the volume.
Mount your remote volume to the filesystem and rsync the folder you want to migrate off-server to it. Take the lemmy service offline, rsync again to catch any changes from when you started.
Now, you can move the old folder that lemmy has been using elsewhere - I recommend renaming it by appending “.old” or something.
Next, you need to make a symbolic link. This link should point from the old folder’s original path and point to your remote volume. Once done, make sure everything is there and that file permissions match the ones in your .old folder - file permissions are important and you may need to recursively set them if your lemmy service runs on a different user than you were making these changes with.
Finally, say a prayer to the machine spirit, waft the holy incense, perform the ritual whack with a wrench, and start the lemmy service. Make sure everything is running properly before you walk away!
The only issue you’re likely to run into is that remote volumes are constrained by network bandwidth. This may slow down load speeds, so some kind of CDN caching solution is recommended.
This sounds about right. They use PlayReady DRM so a browser extension might be able to pull the decryption key during playback. One could download that same stream from that playback season then use ffmpeg with the pulled key to decrypt.
Theoretically. I’d have to do more tinkering than I’m willing to try right now. WideVine is so much easier - just pull some keys from Android.
The best solution might just be to use a VPN like Mullvad, set torrent software like qBittorrent to only use the Mullvad network interface in advanced settings for safety, and grab the video from something like 1337x in a decrypted format.
The DFXP file should just be subtitles
The MPD file is most likely the one to work from - I suspect it is set up to reference the local audio and video files. Try opening it in VLC and see if it plays. If so, something like Handbrake should be able to transcode it all to your preferred format.
Well, you’d need to find a crack separate from a repack because they aren’t in a format that lets you grab the data you need.
Also worth considering that your crack needs to match the game version in most cases. Updates to binary files are likely to make older crack versions incompatible. I tend to just download the repack and add the repack exe to Steam to make everything integrate well and to avoid automatic updates breaking the game.
If you haven’t already, you could try resetting the app’s storage before trying again. It won’t prevent the bug for others but it could get it working for you!
The CLI has more functionality than the API, so you might have better luck listing all entries that way then looping through the details of each entry if the list doesn’t contain the datetime.