I’m running Jellyfin on a Debian-server in my home, and I have the associated media folders set up as samba shares so that I can transfer any new media from my laptop to the server through Dolphin (KDE file manager).

This has for the most part worked very well (except slow speeds), but I’ve had an issue recently where the files are not copied over properly. This resulted in glitches in for example music files that would stop playback. I checked the checksums of some of these files, and they were different from source. Seems like the glitchy files are missing some data, but at no point were I notified about this. It works fine after I removed the files and transferred again, and now the checksums match.

Is this a common issue with samba, or could it be a sign that my HDD is acting up?

  • Bldck@beehaw.orgEnglish
    0·
    2 months ago

    rysnc might be a faster and more reliable option. It can compress the files for transfer and does checksums after the transfer is complete

    I used something like this to transfer 12 TB from offsite to onsite with zero failures

    
rsync -arvzip --progress /path/to/host /path/to/destination

    You can set up a screen and let this run in the background all the time

    • cyberwolfie@lemmy.mlOP
      0·
      2 months ago

      Thanks! Glad to know rsync includes check after transfer, as I’ve just recently used it to backup everything on these drives to another hard drive that will not always be spinning. But I did not consider using it to transfer new media onto these hard drives.

      I’ll try to use it to resync the files that were acting up.

      • Bldck@beehaw.orgEnglish
        0·
        2 months ago

        Depending on your file structure, you could probably keep this running all the time so you don’t have to manually intervene in the future

          • Bldck@beehaw.orgEnglish
            0·
            2 months ago
            1. Open a screen
            2. Start an rsync job to maintain parity between source and destination
            3. Exit the screen, but keep it running
            4. Now rsync will be running in the background until you kill it

            You can reattach the screen whenever you want to check on status, change parameters or kill it

    • eldavi@lemmy.ml
      0·
      2 months ago

      and since op is using kde, they can use a konsole with dolphin to drag and drop /path/to/host and /path/to/destination as well.

      • Bldck@beehaw.orgEnglish
        0·
        2 months ago

        Thanks for sharing! I’m a pure headless Linux user, so I don’t know much about desktop environments

        • eldavi@lemmy.ml
          0·
          2 months ago

          i’m headless for servers too; but i’m foolish enough to use the x server as my daily driver. lol

    • cyberwolfie@lemmy.mlOP
      0·
      2 months ago

      I tried to resync now, and had to pass the -c flag to make sure it checked the cheksums to see if they should be updated. Then it worked. Looks like that does not affect the after-transfer checksum check though, so that’s good (from documentation):

      Note that rsync always verifies that each transferred file was correctly reconstructed on the receiving side by checking a whole-file checksum that is generated as the file is transferred, but that automatic after-the-transfer verification has nothing to do with this option's before-the-transfer lqDoes this file need to be updated?rq check.