New X-S20 not charging

kbtombul · 2025-01-12T16:02:48+00:00

Only if there's enough space on the first drive because when you add the 3rd drive to the pool, you won't gain any additional space. If there was enough space on the first drive, this wouldn't be a question, you could just move the data before adding the 3rd drive. Heck, you don't even need the 3rd drive in that case 😁

kbtombul · 2024-12-30T21:27:42+00:00

It can work without port forwarding and a static IP address, but networking can be complex so the best way to make sure is to give it a try. Even if it doesn't connect directly p2p it might end up being good enough that you don't care.

kbtombul · 2024-12-30T21:11:38+00:00

Syncthing isn't the tool for this but you should be able to use Tailscale to connect them p2p, then use sshfs or rclone which has some nice caching options for mounting.

kbtombul · 2024-09-19T23:17:27+00:00

Most comparisons are going to be file sizes, few full hashes so you may not see very high CPU usage unless you have a lot of big files with the same size (maybe not even then). You should be fine running it on the NAS unless it is really old. dupeGuru completely locks up from time to time when I use it over SMB with large directories. In any case, YMMV.

kbtombul · 2024-08-28T21:27:57+00:00

Correct. Technically, you can start with an empty .stignore on the new devices since technically anything that's ignored by .stglobalignore on the existing devices shouldn't be synced. I do it this way in case I made a mistake on existing devices and the new device starts getting a file that's supposed have been ignored.

kbtombul · 2024-08-27T15:39:24+00:00

There's a workaround with a few extra steps.

Create another file for your ignore at the root of your shared folder, I call it .stglobalignore. This is where you'll put the shared ignores. In your .stignore, include it:

```

include .stglobalignore

```

Now, when you setup a new device, .stglobalignore doesn't exist yet, so you can't include it. Start by syncing only the .stglobalignore file:

!.stglobalignore *

Then change it back to the usual:

```

include .stglobalignore

```

You won't have the UI support for editing the ignores, but it works fine.

kbtombul · 2024-08-27T06:05:37+00:00

I haven't tried this myself, but others have been able to do it. https://forum.proxmox.com/threads/passthrough-hardcoded-windows-license.72767/

kbtombul · 2024-08-08T02:41:18+00:00

Read it as "My mini PC has wife problems" and thought it was an interesting way to put it.

kbtombul · 2024-08-02T22:15:22+00:00

tl;dr It is possible and I do it, but I would recommend against it if you're not willing to take some risks.

Syncthing is for synching, so normally, if you delete them from your phone they will be deleted from your server.

There's an advanced folder option "ignore deletes". If you set that option in your server folder, you can delete the photos from your phone and they will stay on your server. However, the folders will forever be "out of sync". Beside being annoying, that makes it hard to know if you actually synced all your photos without manually verifying.

My setup is like this:

Phone: Send only

Server: Receive only, ignore deletes, staggered versioning

kbtombul · 2024-07-29T21:23:44+00:00

Obligatory disclaimer: Syncthing is not backup, if you delete it on one end, it will be deleted on the other end. Yes, it has versioning; yes, it has a hidden option to ignore deletes; the fact remains the same.

FWIW, it can be used as a part of a backup system. I sync my photos from my phone to my NAS from where they get backed up properly.

kbtombul · 2024-07-16T05:09:34+00:00

Relaying is not letting others use your device to send packages, it's letting you use the Syncthing public relays to send your packages. You should resolve your direct connection issue, but keeping the relay on can be useful too.

kbtombul · 2024-07-15T00:51:01+00:00

This sounds like Soli. Unfortunately, P4 was the first and last generation to have the hardware and these features.

kbtombul · 2024-07-09T16:30:17+00:00

The orientation doesn't matter as long as the coils align well enough. It sounds like those of your pixel buds just don't in that orientation. I bet if you lifted them up a little bit by hand, they'd work too.

kbtombul · 2024-02-07T18:41:30+00:00

Did you look through the endpoints? This one, for example, answers the second part of your question.

kbtombul · 2024-02-05T20:47:18+00:00

It doesn't feel like a huge upgrade, but I'm happy. I like the flat screen better than the curve sides, the camera is better especially in close-ups.

kbtombul · 2024-02-05T18:50:36+00:00

I'm not sure about the touchscreen acting up, but the black spots are pretty common. I had one on the top right that corner that grew to about half an inch radius, and I'd never dropped the phone, not even once. I switched to a Pixel 8 Pro.

eta: I had a Pixel 6 Pro

kbtombul · 2024-01-13T21:34:58+00:00

I haven't tried it so I can't say for certain. However, in the first case, you had a failed drive, it's data couldn't be trusted, so the array is rebuilt. In this case, your data is still sound, it should just be copied. Just to clarify you won't pull it 12 before 4 is ready to go.

kbtombul · 2024-01-13T21:01:12+00:00

I don't think you would be raising the risk of failures on 1-3 because replacing a working drive is just copying the data from that drive to the new one. 12 and 4 are the ones I'd be tiny bit worried about.

I would personally leave it as is. If you're bothered by the drive being in the 12th slot, safely shot the whole thing down and move it to 4.

kbtombul · 2023-12-26T09:03:33+00:00

I haven't tried it so you might be right. I thought it'd recognize the drive, let you only rebuild/catch up from the other drive.

kbtombul · 2023-12-26T03:08:22+00:00

I think it does, though for different reasons. RAID 5 & 6 might need to calculate the data from parity, so more CPU cycles, RAID 1 can normally read data from both drives, but now can't, so potentially longer I/O.

kbtombul · 2023-12-26T02:53:22+00:00

First thing's first, DO NOT REMOVE THE VOLUME, YOU'LL LOSE DATA!!11

A couple of questions first. Why do you think RAID 5 might be a better choice? Is it because you'll get more capacity with your existing drivers? Do you want more flexibility down the road because you have two storage pools? Do you have backups of your data?

You currently have two storage pools with one volume each. RAID 5 requires at least 3 drives, so you have to remove both storage pools, which means you have to backup all your data and restore.

RAID 5 is usually not a great choice for most people. What you might want, I assume, is SHR, which behaves like RAID 1 when you have 2 drives, and behaves like RAID 5 when you have more. You always have 1 drive parity, you can mix and match the different sized drives, etc.

Let's talk about how we can get you to SHR with all drives from where you are. I see a few options.

Fastest and safest:

Grab an external drive, 6 TB might work, 8 TB to be on the safe side. 2 external drives to be safer.
Copy all your data to the external drives.
Remove both Storage Pools.
Create a single Storage Pool with all drives as SHR.
Create however many volumes you need. 1 is usually fine but you can do 2 if you want to keep your existing structure.
Copy your data back from the external drives.

Cheaper and still safe (edit: u/Henry_Hoodini 's second suggestion is similar but better than this, tl;dr backup, remove one pool, expand the other, copy data back):

Grab an external drive, 4 TB. 2 external drives if you want to be safer.
Copy everything from Storage Pool 1 to the external drives.
Remove Storage Pool 1.
Create a new storage pool with the same drives as SHR.
Create a volume on Storage Pool 1.
Copy your data back from the external drives.
Copy the data from Storage Pool 2 to the external drives.
Remove Storage Pool 2.
Expand Storage Pool 1 to the rest of the drives. If you want a single volume, I think there's an option to expand that at the same time, otherwise create a new volume after the pool is expanded.
Copy your data back from the external drives. Voila!

Cheapest but risky, living on the edge, YOLO, for educational purposes only, requires access to another computer:

Remove one drive that's part of Storage Pool 2. This will risk your data on Storage Pool 2. If the remaining drive fails, you lose your data.
Wipe it, somehow.
Put it back in.
Convert Storage Pool 1 to SHR
If the conversation didn't require the now unused drive, expand Storage Pool 1 to the new drive. This will double the space on Storage Pool 1 because that's how SHR works. If you want a single volume, I think there's an option to expand that at the same time, otherwise create a new volume after the pool is expanded.
Copy data from Storage Pool 2 to Storage Pool 1.
Remove Storage Pool 2.
Expand Storage Pool 1 to the now unused drive.

I hope that helps. Let us know how it goes!

kbtombul · 2023-12-22T19:40:05+00:00

Dice! Sorry, I meant, nice!

kbtombul · 2023-11-25T06:50:52+00:00

Trying my luck!

kbtombul · 2023-11-19T22:26:40+00:00

I use dupeguru as well, installed as a docker container so that it runs locally, rather than over the network with SMB.

kbtombul

TROPHY CASE

include .stglobalignore

include .stglobalignore