KDE desktop using Easytag to edit album tags and Luckybackup to sync to NAS.
I recently revised the tags to change the image but when I ran Luckybackup to changes to the album art images were not detected so the NAS data was not changed.
Is there a way to add a flag to force the sync on a file or album?
Budge.
This is a general thought because I do not know how Luckybackup works (allthough I assume, but may have that wrong, it uses rsync under the hood).
Not knowing how Luckybackup can be configure what to backup and what not and you providing no information about such a config (if it exists), I can only guess that the file(s) with the metadata are not in the area that is saved. First thing then is to find out where this information is stored to be able to change the Luckybackup config to include that.
It is also not quite clear to me what “Album” means here. As rsync works on files (and directories), one must know how an “Album” (probably including it’s metadata) is represented in mundane files to get an idea of what is where and what to backup.
Hi Henk,
Thanks for the reply. I posted early just in case there was a flag I should have set but I do get some strange error messages at times so it is time to clean up my configuration. It is quite possible that what I have done in the past is not correct or ideal but here is my command for the present rsync process:-
rsync -h --progress --stats -r -tgo -p -D --update --delete-after --filter=protect .@__thumb --delete-excluded --exclude=**/*tmp*/ --exclude=**/*cache*/ --exclude=**/*Cache*/ --exclude=/mnt/*/** --exclude=/media/*/** --exclude=**/lost+found*/ --exclude=/var/run/** --exclude=/run/** --exclude=/proc/** --exclude=/dev/** --exclude=/sys/** --exclude=**/*Trash*/ --exclude=**/*trash*/ --exclude=.@__thumb --protect-args /home/alastair/Mastermedia/multimedia/Music/ admin@192.168.169.130:/share/Multimedia/Music/
I have used this as it is for many years but it has been a while since I have needed it once more and there may have been a few changes in the past 5 years! I suspect rsync is not the problem but the tagging using Easytag. There are settings that may be incorrect as I had to install on a new machine and do not have a record of my earlier preferences for Easytag. I shall post more info when I have assembled it.
Budge
That is a nice and complicated rsync command, but not knowing your situation, I can not give any comment on what you want to backup or not.
Also, it is nice to talk about Easytag (which I also do not know), but rsync does of course “know” nothing about Easytag. You should find out where those tags are and then alter your rsync command to let it copy those files.
I use
rsync -av --delete-after /directory /directory
to backup my mp3s and after changing the Tag with EasyTAG, the above command will save the new one and delete the old one…
I know nothing about **Luckybackup.
**However Easytag has two options
- Preserve modification time when writing the files
- Update parent directory modification time when writing files
so depending on how those options are set and how Luckybackup decides which files have changed and therefore need to be included in the backup some files may (or may not) be included in the backup.
Regards
susejunky
You have it in one. I pondered these options when working on this as, sadly, I cannot remember how I had them set but my thought was; what exactly what does point 1. mean? Why “preserve” I wondered. If it meant; set the modification time when writing files or; do not change the modification time… it would be clearer. Where exactly is this time set?
Parent directory is easier because if I ripped a disc I would wish to retain the date of the directory containing the album track and this would not have any significance to rsync because it is the file which is the subject not the directory.
What I have found however is that changing the Easytag option does not appear alter the contents of a subject album on rescanning. I may be wrong and will have to do further tests. My fault for not getting the image tagging right first time!!!
Thanks again for the message.
Budge.
A POSIX required feature of a Unix/Linux file system:
A file should have attached to it three timestamps:
- atime: the last time the data was a
ccessed (read); - mtime: the last time the file was m
odified (written into); - ctime: the last time the metadata of the files was c
hanged (created, permission changed, etc.)
mtime is important here, because when your file has a later mtime then the mtime of it’s backup, rsync knows is is chanhed and thus has to be resync-ed.
One can set the mtime of a file to some value (thus in fact cheating). Some programs change something, thus the mtime changes. The program registered the mtime before writing and set it to the old value after writing. Apparently Easytag is such a program where you configure it to do so.
In this case, you should not take “preserve” too litteral, because it is reset to it’s old value, but from outside it looks as preservation.
Henk,
Excellent. Just what is needed to understand. The Easytag language is not quite clear.
I have now changed the options in Easytag. There a command in the drop down file menu in Easytag to force saving so now I think I am moving forward.
That has sorted out my images. I shall post separately on the errors I have seen if I need help.
Many thanks,
Budge.
I guess it is clear enough when the addressee knows about timestamps. And I assume that the writer of the Easytag documentation assumes that such basic knowledge is available in every Unix/Linux user. If that assumption was correct…?
As I see it with the increased knowledge I now have about your case, that there are files which certain contents (like images, sound), which in themselves have the feature that metadata about that contents can be stored in those files. Mark that that is different from metadata about files, that have to be stored outside the files.
Thus when metadata about the contents is changed within a file, that file changes and thus it’s mtime is updated. There may be users who do not like the mtime being updated, they rule that the contents (image, sound) has not changed at all, thus why the mtime (they may depend on mtime for checking when an image was changed e.g.).
Thus, maybe as the result of strong whishes from it’s users community, the devepolers of Easytag may have introduced in their tool the feature of preserving the mtime, nullifying the updating of mtime by the kernel.
I know of another tool that does the same (even by default). jhead, a tool to change metadata in JPEG files, does the same.