starred/Lidarr-Lidarr

Fork 0

mirror of https://github.com/Lidarr/Lidarr.git synced 2026-03-03 00:26:58 -05:00

Warning when hardlinking and metadata tagging enabled #628

New issue

Open

opened 2026-02-20 12:04:47 -05:00 by deekerman · 8 comments

deekerman commented

2026-02-20 12:04:47 -05:00

Owner

Originally created by @tommyalatalo on GitHub (Oct 6, 2019).

Is your feature request related to a problem? Please describe.
When a torrent client is used, along with hardlinking and metadata tagging of the files, the files in the torrent client are corrupted as the metadata is written to the hardlinked files which then won't match the checksums in the torrent client.

Describe the solution you'd like
There should be implemented a prominent warning that if there is a torrent client used with both hardlinking and metadata tagging enabled, the torrent client data is very likely to be corrupted.

AB#396

Originally created by @tommyalatalo on GitHub (Oct 6, 2019). **Is your feature request related to a problem? Please describe.** When a torrent client is used, along with hardlinking and metadata tagging of the files, the files in the torrent client are corrupted as the metadata is written to the hardlinked files which then won't match the checksums in the torrent client. **Describe the solution you'd like** There should be implemented a prominent warning that if there is a torrent client used with both hardlinking and metadata tagging enabled, the torrent client data is very likely to be corrupted. [AB#396](https://dev.azure.com/Servarr/7ab38f4e-5a57-4d70-84f4-94dd9bc5d6df/_workitems/edit/396)

deekerman added the

Type: Enhancement

Priority: Medium

labels

2026-02-20 12:04:47 -05:00

deekerman commented

2026-02-20 12:04:49 -05:00

Author

Owner

@MammothJerk commented on GitHub (Jan 31, 2020):

I was wondering why only my music torrents were getting these errors, this seems to be my problem as well and it was driving me crazy.

@MammothJerk commented on GitHub (Jan 31, 2020): I was wondering why only my music torrents were getting these errors, this seems to be my problem as well and it was driving me crazy.

deekerman commented

2026-02-20 12:04:49 -05:00

Author

Owner

@IllMethods commented on GitHub (Apr 21, 2020):

Yep, having the same issues...

Mine setup

Transmission
Lidarr
Hardlinking
Rescan and Fingerprinting set to always

Not sure what else to add, but only happens to torrents involved with Lidarr.

@IllMethods commented on GitHub (Apr 21, 2020): Yep, having the same issues... Mine setup Transmission Lidarr Hardlinking Rescan and Fingerprinting set to always Not sure what else to add, but only happens to torrents involved with Lidarr.

deekerman commented

2026-02-20 12:04:49 -05:00

Author

Owner

@IllMethods commented on GitHub (Apr 21, 2020):

Just found this...

Overview
Lidarr can write metadata for matched tracks to the audio file (e.g. ID3 tags). This data contains the track title, artist track number etc. as well as MusicBrainz identifiers. The result should be similar to that of MusicBrainz Picard, though we currently don't populate all of the fields that Picard does.

Note that if you enable this option then the files on disk will be changed. If the files are part of a torrent you are seeding then the torrent will be corrupted.

Makes sense since the files that are hardlinked are the same files you are still seeding... Changes made to the hardlinked files with happen to the seeded files also...

Write Metadata to Audio Files - turn this option off
Possibly also change file date and scrub existing tags

@IllMethods commented on GitHub (Apr 21, 2020): Just found this... Overview Lidarr can write metadata for matched tracks to the audio file (e.g. ID3 tags). This data contains the track title, artist track number etc. as well as MusicBrainz identifiers. The result should be similar to that of MusicBrainz Picard, though we currently don't populate all of the fields that Picard does. Note that if you enable this option then the files on disk will be changed. If the files are part of a torrent you are seeding then the torrent will be corrupted. Makes sense since the files that are hardlinked are the same files you are still seeding... Changes made to the hardlinked files with happen to the seeded files also... Write Metadata to Audio Files - turn this option off Possibly also change file date and scrub existing tags

deekerman commented

2026-02-20 12:04:49 -05:00

Author

Owner

@Elmeromoto commented on GitHub (Sep 25, 2023):

Yeah this is a horrible setting. It can (and does!) completely destroy a person's ratio and break their seeding. It needs a lot more controls built around it.

@Elmeromoto commented on GitHub (Sep 25, 2023): Yeah this is a horrible setting. It can (and does!) completely destroy a person's ratio and break their seeding. It needs a lot more controls built around it.

deekerman commented

2026-02-20 12:04:49 -05:00

Author

Owner

@john-parton commented on GitHub (Jul 27, 2024):

If hardlinking used "reflink" or "block cloning" on linux, this wouldn't be a problem. Is there a way to tell Lidarr to use cp --reflink?

@john-parton commented on GitHub (Jul 27, 2024): If hardlinking used "reflink" or "block cloning" on linux, this wouldn't be a problem. Is there a way to tell Lidarr to use `cp --reflink`?

deekerman commented

2026-02-20 12:04:49 -05:00

Author

Owner

@mat926 commented on GitHub (Oct 25, 2024):

I've been having this problem too. The current workaround I have is disable hardlinking. But the biggest downside to that is the files are copied and that would take up twice the disk space. Is there a better option available that doesn't take up twice the space and still have metadata tagging enabled?

@mat926 commented on GitHub (Oct 25, 2024): I've been having this problem too. The current workaround I have is disable hardlinking. But the biggest downside to that is the files are copied and that would take up twice the disk space. Is there a better option available that doesn't take up twice the space and still have metadata tagging enabled?

deekerman commented

2026-02-20 12:04:49 -05:00

Author

Owner

@john-parton commented on GitHub (Oct 25, 2024):

If your filesystem supports it (btrfs and recent zfs), cp --reflink always will make a COW copy of the file. This original copy wouldn't take up any space, but once the file is modified, it will take up some. The amount is dependent on filesystem implementation and configuration, as well as dependent on the exact operation of the tagging code.

Most likely the benefit would be largely negated for small files like audio files, but it could be nice to test.

@john-parton commented on GitHub (Oct 25, 2024): If your filesystem supports it (btrfs and recent zfs), cp --reflink always will make a COW copy of the file. This original copy wouldn't take up any space, but once the file is modified, it will take up some. The amount is dependent on filesystem implementation and configuration, as well as dependent on the exact operation of the tagging code. Most likely the benefit would be largely negated for small files like audio files, but it could be nice to test.

deekerman commented

2026-02-20 12:04:50 -05:00

Author

Owner

@Lord-Valen commented on GitHub (Apr 18, 2025):

If hardlinking used "reflink" or "block cloning" on linux, this wouldn't be a problem. Is there a way to tell Lidarr to use cp --reflink?

github.com/Lidarr/Lidarr@d8850af019/src/NzbDrone.Common/Disk/DiskTransferService.cs (L346-L391)

Seems that lidarr will try to reflink as long as the source and target disks use the same format out of btrfs, zfs, and xfs, and it is not told to hardlink. "Copy" will reflink and keep the original and copy. "Move" will reflink and delete the original afterward. It wouldn't be too hard to have the same flow in the hardlink mode, but seeing this it seems to be a deliberate choice. If we want reflinks, we should probably just use the copy mode.

@Lord-Valen commented on GitHub (Apr 18, 2025): > If hardlinking used "reflink" or "block cloning" on linux, this wouldn't be a problem. Is there a way to tell Lidarr to use `cp --reflink`? https://github.com/Lidarr/Lidarr/blob/d8850af0193846df6de6ec38d67bfabffe58e86b/src/NzbDrone.Common/Disk/DiskTransferService.cs#L346-L391 Seems that lidarr will try to reflink as long as the source and target disks use the same format out of btrfs, zfs, and xfs, and it is not told to hardlink. "Copy" will reflink and keep the original and copy. "Move" will reflink and delete the original afterward. It wouldn't be too hard to have the same flow in the hardlink mode, but seeing this it seems to be a deliberate choice. If we want reflinks, we should probably just use the copy mode.