etua / sagger Goto Github PK

When libcurl cannot connect to the AcoustID it creates empty JSON file which is then interpreted by JSON parser as incomplete and as a result all files are moved to the [unknown] directory.

Currently there are only two categories of "soft" errors which can be discovered in processing individual files that do not affect processing other files. One of them is expected during standard usage (skipping of fpcalc for unsupported files) whereas the other may be a result of no Internet connection which for now will result in skipping every step after downloading JSON leaving target directory empty.

Right now their only indicators are printed messages for CLI mode. I think that some type for listing errors should be defined with typedef so even success messages would contain complete information like "X files moved. Y files skipped because of unsuitable type. Z files skipped because of network errors." That way it would be easier to add other error types in the future.

Fact 1: For now the only individual properties of a file changeable by Sagger are it's position (parent directory) and filename. In order to be a true tagger we need to support adding file metadata. Currently the only limitation of processed file formats is what can fit into fpcalc that is everything ffmpeg does support which is a lot and ideally the chosen solution should have the same capabilities.

Fact 2: It turns out that ffmpeg supports changing metadata.

To check:

• whether there are many naming conventions for tags and do we need to choose one

• whether changing metadata is possible for every processed audio file

• if ffpmeg is going to be used: whether we should use it as a library or once again call the ready binary to do the heavy lifting just as it's done with fpcalc

cmake --build fails to link GTK+ 3 libraries, resulting in a build error.

UI should be translatable. The obvious solution to that need is gettext as currently the only strings problematic in terms of translation are those including numbers and AFAIK gettext supports that so newer solutions like Fluent might not be necessary.

To do:

• choose the localization system and integrate it into the codebase

• integrate repository with one of the online platforms for user-friendly localization