I’ve started to transfer my music on Plex and I face the same problem I had in the past with the Movies & Series agents. The Music agent creates symlinks that can’t be copied for a backup on an external USB HD via Windows.
But in the previous discussion in March 2021, @drzoidberg33 said…
All music agents still use symlinks, that should be changing at some point soon though as there is work to modernize the Plex Music agent.
Currently, my Music library is using the “Plex music” agent.
So…
Do you confirm it’s the old agent that creates symlinks?
Should I now use another agent?
Is the new Music agent that does not create symlinks available now?
At last, IF the new Music agent has not been released yet, when can we expect it? Is it available in Beta?
We have not switched over to stopping the use of symlinks.
You should be able to copy these for backup purposes as long as the drive you are using also supports symlinks. Check how the drive is formatted and reformat to one that does support symlinks, such as NTFS.
Or instead of doing a straight copy, zip the folder and save that for backup. This will also be quicker.
Are you still working on the new Music agent? And if yes, roughly, when do you target to have a first version released?
What’s the consequences of a backup without those symlinks for the Music library? Imagine everything crash, I use this backup, what will be missing exactly?
The new music agent is already being used by PMS, but it still uses symlinks.
The symlinks are used to identify posters. Without them, your posters will appear blank. It should not cause any catastrophic issues. I’m not positive as I haven’t tested it, but you should be ok to just refresh the metadata after restoring and it will re-generate the needed symlinks.
Have you tried either of the suggestions given? They do work well today. I want to double down on @anon18523487’s original recommendation.
The location of the original files isn’t FAT, so FAT makes a poor filesystem for backups. FAT can’t preserve links or file ownership or permissions.
Copying from a network filesystem is a poor method of performing backups, for similar reasons - it doesn’t preserve the original filesystem details. It’s also slow, easy to interrupt, difficult to restart, doesn’t include verification, and doesn’t support incremental updates.
Consider updating the USB HDD to an appropriate filesystem.
Consider creating archives instead of copies.
Consider using a backup tool instead of performing copies.
But note that those may all still have issues if the backup is performed from a network share.
So another suggestion - consider using Synology’s tools for backup:
Ok, I understand.
Any plan to keep on improving this agent, among other by removing the symlinks as it was originally planed?
Ok, thanks for the info.
It’s not too bad, not a huge issue indeed.
The external USB drive I was talking about is already NTFS and it doesn’t work.
Copying Linux symlinks to NTFS does not look that obvious, even if Windows/NTFS support symlinks…
If you have a solution, I would be happy to test it.
But I’ll not ZIP the Plex directories.
In fact, I have 2 backups, of all my data (not only Plex):
one daily, online, compressed/encrypted using a Hyper Backup incremental backup on a remote dedicated NAS, where I keep 10 years of backups
and one weekly, voluntarily offline (can’t be encrypted by a ransomware), not compressed (easy to access), not encrypted (the backup can’t be corrupted as a whole), using the excellent Mirror Synchronization mode of FreeFileSync which lift most of your concerns (it’s fast, only a differential sync, so never interrupted as it copies a minimal number of files and reliable).
The problem is that those few symlinks, around 70 files, are the only ones out of 800K files / 3TB of data that can’t be copied/synced this way. It’s a bit annoying
Sorry to come back on my last question, but you did not answer and it seems, “maybe”, there are some changes with one of the recent server version.
In my last answer I asked you:
Ok, I understand.
Any plan to keep on improving this agent, among other by removing the symlinks as it was originally planed?
I come back on the question as this afternoon I ran a backup and was surprised to see 3 times less symlinks than usual. I used to have around 90 and this time I had only around 30. And “I think” (I may be wrong), that I used to have a diversity of paths that I don’t have any more. Like if symlinks were used for covers, artists, posters, etc. and now there’s only 1 category left… “posters”.
Am I wrong or are you still working on the agent and are currently progressively removing the symlinks? And if I’m wrong, do you still have plans to remove then in the future?
When running a Clean Bundles on server versions 1.28.0 or higher should remove all symlinks the music agent used to use. Only legacy agents now rely on symlinks.
That’s why, as I indeed upgraded to the 1.28.0.5999-7000.
But even after cleaning the Bundles, I still have 33 symlinks from 1 of the former categories of symlinks (“posters”)
They look like that (on Synology DSM7): \PlexMediaServer\AppData\Plex Media Server\Metadata\Albums\0\4bb76de0c2ade76cc989b9809336de2a5b41b5e.bundle\Contents\_combined\posters\tv.plex.agents.music_247fe3b2e37ab16abf3513b185e00d297c53ed1e
It “maybe” corresponds to 33 out of the 34 albums I have in the Library
Symlinks are the cyan on black… (LINK 01;36 # symbolic link.)
/volume1/PlexMediaServer/AppData/Plex Media Server/Metadata$ dircolors -p
# Configuration file for dircolors, a utility to help you set the
# LS_COLORS environment variable used by GNU ls with the --color option.
# Copyright (C) 1996-2018 Free Software Foundation, Inc.
# Copying and distribution of this file, with or without modification,
# are permitted provided the copyright notice and this notice are preserved.
# The keywords COLOR, OPTIONS, and EIGHTBIT (honored by the
# slackware version of dircolors) are recognized but ignored.
# Below are TERM entries, which can be a glob patterns, to match
# against the TERM environment variable to determine if it is colorizable.
TERM Eterm
TERM ansi
TERM *color*
TERM con[0-9]*x[0-9]*
TERM cons25
TERM console
TERM cygwin
TERM dtterm
TERM gnome
TERM hurd
TERM jfbterm
TERM konsole
TERM kterm
TERM linux
TERM linux-c
TERM mlterm
TERM putty
TERM rxvt*
TERM screen*
TERM st
TERM terminator
TERM tmux*
TERM vt100
TERM xterm*
# Below are the color init strings for the basic file types. A color init
# string consists of one or more of the following numeric codes:
# Attribute codes:
# 00=none 01=bold 04=underscore 05=blink 07=reverse 08=concealed
# Text color codes:
# 30=black 31=red 32=green 33=yellow 34=blue 35=magenta 36=cyan 37=white
# Background color codes:
# 40=black 41=red 42=green 43=yellow 44=blue 45=magenta 46=cyan 47=white
#NORMAL 00 # no color code at all
#FILE 00 # regular file: use no color at all
RESET 0 # reset to "normal" color
DIR 01;34 # directory
LINK 01;36 # symbolic link. (If you set this to 'target' instead of a
# numerical value, the color is as for the file pointed to.)
MULTIHARDLINK 00 # regular file with more than one link
FIFO 40;33 # pipe
SOCK 01;35 # socket
DOOR 01;35 # door
BLK 40;33;01 # block device driver
CHR 40;33;01 # character device driver
ORPHAN 40;31;01 # symlink to nonexistent file, or non-stat'able file ...
MISSING 00 # ... and the files they point to
SETUID 37;41 # file that is setuid (u+s)
SETGID 30;43 # file that is setgid (g+s)
CAPABILITY 30;41 # file with capability
STICKY_OTHER_WRITABLE 30;42 # dir that is sticky and other-writable (+t,o+w)
OTHER_WRITABLE 34;42 # dir that is other-writable (o+w) and not sticky
STICKY 37;44 # dir with the sticky bit set (+t) and not other-writable
# This is for files with execute permission:
EXEC 01;32
# List any file extensions like '.gz' or '.tar' that you would like ls
# to colorize below. Put the extension, a space, and the color init string.
# (and any comments you want to add after a '#')
# If you use DOS-style suffixes, you may want to uncomment the following:
#.cmd 01;32 # executables (bright green)
#.exe 01;32
#.com 01;32
#.btm 01;32
#.bat 01;32
# Or if you want to colorize scripts even if they do not have the
# executable bit actually set.
#.sh 01;32
#.csh 01;32
# archives or compressed (bright red)
.tar 01;31
.tgz 01;31
.arc 01;31
.arj 01;31
.taz 01;31
.lha 01;31
.lz4 01;31
.lzh 01;31
.lzma 01;31
.tlz 01;31
.txz 01;31
.tzo 01;31
.t7z 01;31
.zip 01;31
.z 01;31
.dz 01;31
.gz 01;31
.lrz 01;31
.lz 01;31
.lzo 01;31
.xz 01;31
.zst 01;31
.tzst 01;31
.bz2 01;31
.bz 01;31
.tbz 01;31
.tbz2 01;31
.tz 01;31
.deb 01;31
.rpm 01;31
.jar 01;31
.war 01;31
.ear 01;31
.sar 01;31
.rar 01;31
.alz 01;31
.ace 01;31
.zoo 01;31
.cpio 01;31
.7z 01;31
.rz 01;31
.cab 01;31
.wim 01;31
.swm 01;31
.dwm 01;31
.esd 01;31
# image formats
.jpg 01;35
.jpeg 01;35
.mjpg 01;35
.mjpeg 01;35
.gif 01;35
.bmp 01;35
.pbm 01;35
.pgm 01;35
.ppm 01;35
.tga 01;35
.xbm 01;35
.xpm 01;35
.tif 01;35
.tiff 01;35
.png 01;35
.svg 01;35
.svgz 01;35
.mng 01;35
.pcx 01;35
.mov 01;35
.mpg 01;35
.mpeg 01;35
.m2v 01;35
.mkv 01;35
.webm 01;35
.ogm 01;35
.mp4 01;35
.m4v 01;35
.mp4v 01;35
.vob 01;35
.qt 01;35
.nuv 01;35
.wmv 01;35
.asf 01;35
.rm 01;35
.rmvb 01;35
.flc 01;35
.avi 01;35
.fli 01;35
.flv 01;35
.gl 01;35
.dl 01;35
.xcf 01;35
.xwd 01;35
.yuv 01;35
.cgm 01;35
.emf 01;35
# https://wiki.xiph.org/MIME_Types_and_File_Extensions
.ogv 01;35
.ogx 01;35
# audio formats
.aac 00;36
.au 00;36
.flac 00;36
.m4a 00;36
.mid 00;36
.midi 00;36
.mka 00;36
.mp3 00;36
.mpc 00;36
.ogg 00;36
.ra 00;36
.wav 00;36
# https://wiki.xiph.org/MIME_Types_and_File_Extensions
.oga 00;36
.opus 00;36
.spx 00;36
.xspf 00;36
I really don’t know how it works but the number of symlinks is slowly decreasing with each new updates
Like I said on Aug. 13 (version 1.28.0), I used to have 33 symlinks left.
With the version 1.28.2 I had only 30 left.
And now with the version 1.29.0 I have only 23 left.
(FYI, every time I install a new update, I clean the bundles as asked)
So I don’t if you are slowly removing all the remaining cases that creates symlinks or if the remaining ones are kind of expiring
@drzoidberg33 any info/explanation on the issue/progress?
