𝕽𝖚𝖆𝖎𝖉𝖍𝖗𝖎𝖌𝖍

       🅸 🅰🅼 🆃🅷🅴 🅻🅰🆆. 
 𝕽𝖚𝖆𝖎𝖉𝖍𝖗𝖎𝖌𝖍 𝖋𝖊𝖆𝖙𝖍𝖊𝖗𝖘𝖙𝖔𝖓𝖊𝖍𝖆𝖚𝖌𝖍 
  • 1 Post
  • 10 Comments
Joined 2 years ago
cake
Cake day: August 26th, 2022

help-circle



  • Photoprism’s app space is pretty bad, but there is an completely hacky yet reliable solution for Android:

    1. PhotoBackup
    2. The PhotoBackup server on your Photoprism server
    3. A cron job that runs the photoprism import command every few minutes.

    Since I’ve had this set up, it’s worked as well as Google Photos ever did for keeping my phone snaps synced to the server. It’s been more reliable than SyncThing for my data, reacting and syncing faster, and it doesn’t mysteriously periodically just stop running like SyncThing.

    I don’t know if PhotoBackup is available for iOS, but if it is, it works a treat.


  • I’m in no way an expert, and, frankly, I casually disregard canon if it offends me. But I can think of a few potential reasons to have a transporter room.

    • It removes variables from the transporter process, making it safer and more reliable. You either know exactly where you’re sending people from, or receiving them to, so it’s one less thing to have to adjust.
    • It’s a staging area. Even without transporters, today staging areas - where you get everyone together and they mentally prepare to move as a group - are important.
    • When receiving, the transporter pad has a lot of extra security options; you can transport things into secured environments. I feel as if they tended to do this more in TOS, but I don’t have an example off the top of my head.

    I think the main thing is that it’s just safer, because one end of the transfer is a fixed, known constant. You can beam people directly to med bay, but you’re adding variables and risk, so you only do it in emergencies.


  • Honestly, I think Android is fucked for debugging stuff like this. I installed a program on mine and my wife’s phones - different makes & models - and configured them exactly the same, including the app settings in the OS. Mine works perfectly and barely shows up in battery use, near the bottom. Her’s drains her battery even when she’s not using it, regularly running at 50% of total battery consumption.

    With Android YMMV is the rule, rather than the exception. There’s just too many variables.


  • It’s the main way I sync my phone.

    I have a different app for photos, but SyncThing on my phone, and on my desktop, and again on one of my home servers, do most of the download and data syncing.

    Occasionally I’ll have to manually run SyncThing; I’m not certain that Android is reliably starting it after reboots, but for the most part it just does it’s thing really reliably. There is a lag; it can take a few minutes for changes to sync - it’s not immediate. For me, this isn’t a problem, and I’d rather that than a battery suck, so I haven’t messed with it.





  • A studio should be able to afford a good LTO tape drive for at least one backup copy; LTO tapes last over 30 years and suffer less from random bitrot than spinning disks. Just pay someone to spend a month duplicating the entire archive every couple of decades. And every decade you can also consolidate a bunch of tapes since the capacity has kept increasing; 18TB tapes are now available: $/MB it’s always far cheaper to use tape.

    They could have done that with the drives, but today you’d have to go find an ATA IDE or old SCSI card (of you’re lucky) that’ll work on a modern motherboard.

    But I’d guess their problem is more not having a process for maintaining the archives than the technology. Duplicating and consolidating hard drives once a year would have been relatively cheap, and as long as they verified checksums and kept duplicates, HDs would have been fine too.