dragonq/music-directory-syncer

Sync an entire directory of music to another based on codec and tag rules.

Music Directory Syncer

Music Directory Syncer is a Windows application that allows a directory of music files to be synced to any number of others, according to certain rulesets:

• Tags being present
• Tags having certain values
• File type

Audio files can be converted to a chosen lossy format using ffmpeg if desired to save space, e.g. on a mobile device. This can be done to all files or just losslessly compressed ones. You can also choose to apply ReplayGain volume adjustment if the device you're using doesn't support ReplayGain tags. Once you've made your synced directory, you can use any directory syncing application to copy it to a mobile device, for example.

Music Directory Syncer will run quietly in the background watching your chosen source directory for changes, and it will update all of your sync directories on-the-fly.

music-directory-syncer's Issues

Cancelling a sync doesn't reset the name of the "Start New Sync" button.

Renamed temporary files cause issues

Consider the following edge case:

• SrcFileA has been renamed to SrcFileB.
• SrcFileB matches configured tags so should be synced.
• SyncFileA doesn't exist.

The current behaviour is to attempt to transcode SrcFileB to SyncFileB. This works fine, unless the following is also true:

• SyncFileB already exists.

In this case, the application hangs (if transcoding) or fails to transcode (if copying).

This can happen if the "rename" event is actually an "overwrite" event. Since there's no distinction in the FileSystemWatcher between these two types of events, we need to deal with it ourselves. This has been seen to happen when Foobar changes a file's tags: it creates a new temporary file (SrcFileA in this case) and then renames that temporary file to the original file's name (SrcFileB), overwriting it.

The fix is to delete SyncFileB before attempting to copy/transcode SrcFileB, if it exists.

New directories are created with incorrect permissions

New directories are created with incorrect permissions, which prevents normal user interaction with them.

Directory.CreateDirectory() sometimes fails because directory already exists

Despite Microsoft's documentation stating that Directory.CreateDirectory() is thread-safe and will not throw if the directory specified already exists, it does seem to occasionally.

This has been seen to happen in FileParser.TranscodeFile(). Example error message:

05/06/2020 17:56:57 [Warning] : [07148] ...transcode failed [1]. Exception: Cannot create "\\fractal\Scratch\SyncThing\Audio\Best Music\The White Stripes\De Stijl" because a file or directory with the same name already exists.
05/06/2020 17:56:57 [Warning] : [07148] Sync file processing failed: "\The White Stripes\De Stijl\The White Stripes - You're Pretty Good Looking (For a Girl).wma". Exception: Transcode failed [1]. Exception: Cannot create "\\fractal\Scratch\SyncThing\Audio\Best Music\The White Stripes\De Stijl" because a file or directory with the same name already exists.
05/06/2020 17:56:57 [Warning] : [07148] File could not be processed. Error: Transcode failed [1]. Exception: Cannot create "\\fractal\Scratch\SyncThing\Audio\Best Music\The White Stripes\De Stijl" because a file or directory with the same name already exists.

This has also been seen to happen in FileParser.TransferToSyncDirectory(). Example error message:

05/06/2020 17:57:04 [Warning] : [07240] Sync file processing failed: "\The White Stripes\Walking With a Ghost\The White Stripes - The Denial Twist (Live).wma". Exception: Cannot create "\\fractal\Scratch\SyncThing\Audio\Home Music\The White Stripes\Walking With a Ghost" because a file or directory with the same name already exists.

This could be resolved with an If Not Directory.Exists() ..., even though that isn't meant to be necessary. If it's a more serious threading problem, more investigation will be required.

Parent directory deletion when empty isn't recursive

The application deletes a directory if it's empty after a synced file is deleted. However, this is not recursive so that directory's parent directory will still remain, although it is empty.

Crash when choosing to not enable background sync after creating a sync

Doh!

Sync folders created by the application have incorrect permissions

If the user chooses a sync directory that doesn't exist, it will be created. However, it appears to be created with strange permissions: the owner is the current user, and the only permission entry is "full control" for "authenticated users". This means the user might not actually be able to access synced files inside the directory.

Question - Would you ever think of adding foobars DPS chain to this (If possible)

I have DPS chain setup in fb and currently using the converter to export to a USB for the car.

Would this program be able to access the DPS chain foobar uses and apply that during conversion?

Source directories ending in backslash cause many erroneous sync directories to be created

Path parsing is done in a dumb way but Path.Combine doesn't behave well with paths that start with backslashes. The most robust solution to this is probably to enforce that source and sync directories never end in backslashes.

Cancelling a sync doesn't actually cancel it

The file processing queue doesn't actually get cancelled when the user closes the Create New Sync window.

ffmpeg hangs due to destination file already existing

The application can stall due to ffmpeg waiting indefinitely for the user to confirm a file overwrite (in a hidden window). This should never happen as a file shouldn't be processed more than once.

Files that are marked for copy without transcoding fail to sync

Files that are marked for copy without transcoding fail to sync.

Application version isn't printed to the log file upon launch

OGG files are not synced

OGG Vorbis and Opus files are not synced because the tag parser fails for all OGG files. This bug was introduced in v1.0.1.

Deleted/renamed directories don't get parsed properly

Deleted and renamed files work fine but deleted or renamed directories do not get parsed correctly.

Previously transcoded files are used even when sync settings are different

If a multiple syncs are defined and a transcode has already been done, the already transcoded file is copied to save processing time. However, this shouldn't happen if the additional sync setting uses a different destination file format.

MaxThreads parameter can be exceeded

A race condition means that the MaxThreads parameter can be exceeded, i.e. more threads than the user has specified can run at once.

File IDs in log file can be incorrect with heavy file system changes

When there is a lot of file system changes picked up by the file system watcher, file IDs can become incorrect in the log file. This is caused by an oversight in the locking mechanism for assigning file IDs.

This doesn't affect the application's mission but makes debugging more difficult.

Deleted files take ages to be recognised due to failed file lock

If you delete a file from the source directory, the program tries to get a file lock on a file that doesn't exist, which takes 60 (?) seconds to time out, slowing down progress a lot.

File IDs should start at 1 rather than 0 to avoid confusion

Right now each file has an ID, which is printed to the log file where appropriate. When the application first starts, this ID is 0. This causes confusion since some non-file-specific logging also uses this ID. Changing the starting file ID to 1 will solve this.

First codec profile is always used

The first codec profile is always used regardless of user setting.

Newly created files get parsed 2+ times

This is due to the way the FileSystemWatcher works. A work-around will be needed to sort this out.

MaxThreads option isn't editable outside of manually editing the settings file.

Files are unnecessarily transcoded multiple times when more than one sync directory exists

This is due to an oversight when the code was re-designed to allow more than one sync directory to be set up. A partial re-write of the FileParser class is needed to solve this.

Files stop being processed under certain circumstances

1.2.1: Cancelled tasks don't decrement the thread running counter, causing other threads to pause forever. The only way to fix this is to restart the application.

Allow each codec profile to have its own output file extension

Currently the first extension listed in a codec's extensions list is used, which doesn't really make sense if you're outputting to OGG Opus because you'll end with files that have a .ogg extension instead of a .opus one.

Directory/file/tag names with weird characters cause fatal crash

Seen with directory including dots, but also had Japanese characters in the mp3 tags. Not sure which causes the crash yet.

Add album art copying

Add the ability to parse images based on priority, like Foobar does.

Failure to create new sync locks "source directory" option

The "source directory" option should only be locked once at least one successful sync has been set up.

Deleted files matching tag/file rules are added to sync directories

If a file is deleted, it should be deleted from the sync directories.