Please Help Recover My Home Movie Audio Clips

Imagine that on a portable hard drive I have many recorded conversations of family and friends that function like audio-only versions of home movies. Each conversation has a detailed filename, involving specific topics covered, unique stories, inside jokes and so on. Sometimes, the file names become prohibitively long, so I resorted to using the file titles in Windows 10, specifically the Title file property attribute found in the details tab after you right-click on the MP3. This is what I mean: https://www.tenforums.com/tutorials/93210-add-change-remove-file-property-details-windows-10-a.html
Unfortunately, when I plugged my portable drive containing all the conversations into my new Windows 11 computer, the detailed file names were missing on the files with the longer names. Is there anything I can do to get them back?

I have a Duplicati background of these files at various points in time, but it doesn’t appear that this metadata is saved. Or if it is, I’m not seeing it.

The other thing is, I intentionally made sure the file names of these files ended with three dots, like This File Name Is Too Long to Fit inside Space Provided by Microsof….mp3. That way I could quickly find which files have the extended file names and then replace them with my manual alternate backup. However, when I search for …mp3 in the Duplicati program, it appears to highlight the correct selection of files but when I go to restore, the program attempts to recover all my audio files not just the ones with the really long filenames. Is there a way I could restore only the files that end with …mp3?

I have been able to recover many of the labels from a separate backup source. Then, instead of using Windows, I used the free program mp3tag to make sure the tags were properly saved. Could someone please verify for me that Duplicati is supposed to backup and notice changes in ID3 tags? I would hate to have to go through this process again in the future.

ID3 (Wikipedia)

There are two unrelated versions of ID3: ID3v1 and ID3v2. In ID3v1, the metadata is stored in a 128-byte segment at the end of the file. In ID3v2, an extensible set of “frames” located at the start of the file is used. Subvariants of both versions exist.

In both cases, the tag is in the file. Duplicati isn’t MP3-aware. It would copy an ID3 as file data. Question to me is: how did ID3 get damaged, if they actually did, as opposed to display issue? Generally, any data change would also cause a Date modified change. My own Title edit did.

How about trying that on what you think are the damaged files, or maybe a renamed file copy?

is the Windows 10 computer still around? Maybe Windows 11 can’t handle the scheme you use.
If you hover over a file, does it recognize it as an MP3 (with no odd dots)? Details tab MP3 too?

That’s not what you typed into the forum. You typed an ellipsis, which only looks like three dots.

https://www.charset.org/utf-8/9

E2 80 A6 … Horizontal Ellipsis

Here it is in an editor that doesn’t do Unicode. It’s from original text, as forum can reformat text:

image

Here it is in Notepad, with a fixed-width font (Courier New) to keep variable-width from hiding it:

image

Here it is in a hex viewer:

image

but I don’t know if this is relevant to the problem, as the ellipsis is before the actual dot and mp3.

What did you actually select (using checkboxes) to restore? Highlight just helps find files, I think.

Thank you for your elaborate and helpful reply. Also, I like your keen eye for details. Because of a disability, I use Dragon NaturallySpeaking to type. So, I am actually aware of the difference between pressing the period button three times and using the ellipses. I never use the ellipses when doing the filenames. Instead, I manually dictate each period. I don’t even think Dragon would put an ellipsis inside a file name without throwing some kind of hissy fit. It looks like I used an ellipses on the forum post, but that was just an incidental occurrence on my end. Yes, the Windows 10 computer is still around, however, When I connected the portable hard drive with the mp3s on it back up to the Windows 10 computer, a great many of the tags were strangely missing. So I have spent the day copying and pasting backups of the extended file names from another source that I have. I really hope the portable USB drive is not failing. It was purchased in 2022 but I don’t necessarily have the money to grab a new one right now seeing as I spent all my dough on the new computer, the one with Windows 11. I was able to restore from my Duplicati backup all of the mp3 files that contained three dots in the file name. It was a bit frustrating because in order to restore just the files with three dots in the file name, I had to click on each one manually and there were around 100 files. When I loaded the directory with the restored mp3 files into the mp3 tag tag editor, I was surprised to find that some of the tags were present and others were missing. The ones that remain are ID3v2.3, which must be what Windows 10 was using when I would go into the file properties details tab and put in the original extended title.

It’s too late now, the method is kind of crude, and I don’t know if there’s a better way, but see

The RESTORE command

If you want to restore all files, use “*”

and it turns out that if I use a path with \*...* in the end, it only restores files with three dots.

Are the file dates changing? If so, that might give a clue. I don’t know what would change files.

The restore command seems like it could be a game changer. I hope you don’t mind, but I really, really don’t want to mess things up. So to make sure I have the right idea, suppose I would like all of my files with the three dots to be restored here: D:\bigtest

The Duplicati archive where the audio files are stored is here: P:\Recording_backup (Duplicati)\

The Duplicati archive is named Personal Recordings.

How should the commandline command go? (Normally I would give it a go myself, but I am nervous because the files are important.)

Edit: Duplicati.CommandLine.exe find “P:\Recording_backup (Duplicati)\Personal Recordings” “” I decided to test this commandline instruction because it seemed less risky than actually restoring files, but it’s prompting me for an encryption password even though I never set up one.

Using the Command line tools from within the Graphical User Interface

is easier than (say) a Windows Command Prompt because info for backup is already filled.
You need to pick the command you want (restore here), and change as needed to match it.

The BACKUP command has source paths in Commandline arguments box.
The RESTORE command takes specifications of the files you want restored.
You would use the original path with the stars and dots however to restore to
D:\bigtest you would add the restore-path option from dropdown, and fill it.

This should not happen in GUI Commandline, as it will use job no-encryption.
GUI CommandLine knows what GUI backups use. Command Prompt doesn’t.


These are the fields I put into the command line GUI and it still wanted to restore all files instead of just the ones with the three dots.

image

image

image

image

image

What did you see that tells you that? Are you just going by count, then interrupting restore?
Granted I’m not trying to increase logging, and if the parentheses matter, I’m not using any.

EDIT:

Still fine in test of source folder of C:\backup source\Recordings 2 (Active) and Verbose log.

Restore started at 9/21/2024 11:04:16 AM
The operation Restore has started
Checking remote backup ...
Backend event: List - Started:  ()
  Listing remote folder ...
Backend event: List - Completed:  (4 bytes)
Searching backup 0 (9/21/2024 3:01:40 PM) ...
Needs to restore 2 files (0 bytes)
Mapping restore path prefix to "C:\backup source\Recordings 2 (Active)\" to "C:\backup restore\"
Restore list contains 2 blocks with a total size of 274 bytes
Checking existing target files ...
Scanning local files for needed data ...
1 remote files are required to restore
Backend event: Get - Started: duplicati-b0e7bb81cc7ba4374afd7180b5781eda9.dblock.zip (1.28 KB)
  Downloading file duplicati-b0e7bb81cc7ba4374afd7180b5781eda9.dblock.zip (1.28 KB) ...
  2 files need to be restored (0 bytes)
Backend event: Get - Completed: duplicati-b0e7bb81cc7ba4374afd7180b5781eda9.dblock.zip (1.28 KB)
Recording metadata from remote data: C:\backup restore\3dots...mp3
Recording metadata from remote data: C:\backup restore\4dots....mp3
Restoring empty file "C:\backup restore\3dots...mp3"
Restoring empty file "C:\backup restore\4dots....mp3"
Patching metadata with remote data: C:\backup restore\3dots...mp3
Patching metadata with remote data: C:\backup restore\4dots....mp3
  0 files need to be restored (0 bytes)
Verifying restored files ...
Testing restored file integrity: C:\backup restore\3dots...mp3
Testing restored file integrity: C:\backup restore\4dots....mp3
Restored 2 (0 bytes) files to C:\backup restore
Duration of restore: 00:00:00
Return code: 0

Thank you so much for your extra help. I really appreciate your valuable time. I feel like I’m taking crazy pills because you saw what I put in my screenshot. On my end, what happened was that it just restored every file in the backup-or rather it was going to. I stopped it partway through, but it was obviously restoring all files in the backup, not just the files with the three dots. (I checked the restore folder afterwards.) I’m not sure what exactly I’m doing wrong. I know this seems like overkill, but would it help if you saw an extremely short video of me starting the process? (I could link something via Dropbox.) Or is the screenshot I previously attached sufficient?

:Let’s call it good for now, and go try some other things.

The FIND command has similar syntax, but then describes what I’m trying to do in restore.

Usage format for the find command is:

Duplicati.CommandLine.exe find <storage-URL> ["<filename>"] [<options>]

If <filename> is specified, all occurrences of <filename> in the backup are listed. <filename> can contain * and ? as wildcards. File names in [brackets] are interpreted as regular expression. Latest backup is searched by default. If entire path is specified, all available versions of the file are listed. If no <filename> is specified, a list of all available backups is shown.

Even the builtin help for restore doesn’t say what a filename is, but it seems to do wildcards and regular expressions, just like find (also called list) documents. For example, it can do m?3 for mp3, and [C:\\backup source\\Recordings2 \(Active\)\\.*\.{3}.*] for triple-dot paths. Maybe you can adapt the regular expression to your use, testing it first in find. I get this output:

            
Listing contents 0 (9/21/2024 4:16:20 PM):
C:\backup source\Recordings2 (Active)\3dots...mp3 (0 bytes)
C:\backup source\Recordings2 (Active)\4dots....mp3 (0 bytes)
Return code: 0

Using the regular expression in Commandline arguments box also gets those two files restored.
Filters describes how * and ? work for wildcards, and syntax of putting regex in square brackets. What I wish is that the restore documentation said restore uses them, but it seems to in my tests. Possibly a developer who knows the area will stop by to clarify, or maybe your list test will help…

So, this is a weird one. Using the find command in the graphical command line section, it doesn’t matter what I put in. G:\Recordings2 (Active)*computer*.mp3

If I were to do the find command, and put this in the arguments field, I would expect it to show filenames that contain the word computer. Instead it just shows every file in the backup. Regardless of what I enter, all I get back with the find command is a list of every file in my backup.

I can get that if I have filters (--exclude or --include). Try deleting any.


Duplicati - Proper use of advanced GUI command line to restore files with three dots REMOVE CHECKBOXES FOR FILTERS.png

Thank you so much! It works now. I would have never figured out how to do this without your help. Next time I have to restore any files with the three dots or any other specific criteria, I will remember to go into the advanced options on my backup, pick the GUI command line, all right and disable any filters before doing a search of G:/Recordings2 (Active)/ in the command line arguments box. The formatting of this forum is messing up the correct file path, but I will refer to the image above so that it’s exactly right. Thanks again. (It really seems like this no filters search thing should be made more explicit within the program itself.)

Edit: If necessary, I will also remember to add the advanced option for a custom restore-path.

Some commands, such as The LIST-BROKEN-FILES command are clear about the use of filters:

The operation ListBrokenFiles has failed with error: Filters are not supported for this operation => Filters are not supported for this operation

ErrorID: FiltersAreNotSupportedForListBrokenFiles
Filters are not supported for this operation
Return code: 100

I can poke at this some more to see if I can find a case where one might actually want the filters. There is also the problem of not documenting the syntax of a filename in the restore command, however if you do that, then the question arises of how that specification interacts with the filters.

Developer comment on the design is of course welcome. I didn’t find any open Issue on first look.