Files can only be copied during import. Automatic deletion after success and wait period

[Guido83]

At first I would like to give a big thanks to you for providing this very helpful tool.

I have started seeting it up an now testing. Most of it is now in a good state, but still some things to do.
Currently I am only testing chunks of my Library as it is in total >2TB and not yet tagged with beets as it is managed by lidarr only.

my config.yaml for beets is:

import:
    move: yes
    copy: no
    write: yes
    resume: yes
    incremental: no
    incremental_skip_later: no
    log: /config/beets/import.log
    quiet_fallback: skip
    detail: yes
    duplicate_action: ask # ask|skip|merge|keep|remove
    group_albums: no
    from_scratch: no
    none_rec_action: ask

but all imported files are not moved but copied. From within the beets-flask webui I can delete imported files, so it is not a permission isse. All my files are 99:100 (default in unraid) and the containers are also running with UID=99 GID=100. Am I missing something?

[pSpitzner]

Hi @Guido83,

thanks for raising this!
Your setup is correct, its our fault 😅

We currently have not enabled file moving.
(... and I only now added this info to the limitations in the docs.)

The reason is that we need a way to correct auto-imports that did not go well, and that is easiest to do if the original files are still available. So we initially made the design choise to only support copies, because otherwise, we would not just need to move files again, but also somehow keep track of their original meta data.

However, I think this is a good starting point for us to think about potential workarounds.
Two ideas:

• Have a watchdog to auto-delete from inboxes after a successfull import and a user-customizable period. E.g. give users one week to correct.
• Set a file attribute or create a dot-file in the inbox folder, so that user can script and automate it themselves.

What is the workflow you are after?

[Guido83]

Alright I see, thank you for explaining it to me. What I am aiming for is letting beets do all the library management instead of lidarr in the future.
What I did to setup and test my environment:

• created a beets-flask inbox folder with auto import.
• Copied chunks auf my lidarr library into that inbox.
• Manually deleted successfully imported folders

I did it this way for two reason:

1. Testing all my configurations before possibly destroying my music library somehow.
2. Setting my whole library as inbox folder with auto-import and setting it to copy on import is what I want in long-term, but I know this wouldn't work on such a big library. As I already make copies of my files, I would rather move that copy to the final directory.

Long story short: I want to push my lidarr created library through beets and let lidarr only handle downloads once it's done.

[pSpitzner]

Thanks for clarifying :)

I think this should work, once you have migrated most of the existing library - its very much how I am running beets-flask, too. New arrivals get automatically placed in an inbox, and I occasionally empty the inbox (manually, so far).

I know we have no good workflow yet for the initial import of a big library from another source see here but we will get to it for the next big version.

Ill rename the issue and keep it open, so we can add more ideas for automatic deletion after successful imports.

[Guido83]

So after importing a big amount of my existing library I would like to share some of my experiences, and ideas for a more convenient handling.

1. After spending hours clicking check marks, the feature I missed the most is the ability to select multiple items at once. For instance selecting first and then shift+last item would select all item in between.
2. The folder structure I imported was: /Artist/Album/song.flac. It would be much easier if I could selct the main Folder (Artist) and all subfolders (Albums) would be selected as well.
3. More batch functionality like: Retag all integrity marked. Retag/Retry all failed and remove/delete duplicates
4. Sorting feature. Not very important but nice to have if I could sort items by "state" and "match value"
5. Sometimes the imporatation process just stops even though there is items left in the queue but I guess this happens if the amount of data reaches its limits. I found like 10GB chunks worked most of the time
6. Probably a beets issue or bad configuration on my side: Some artist folders were created multiple times but diffrently capitalized: Like "Agents of Time" and "Agents Of Time" and in some cases also like another folder called "Agents of Ti" (But the files have been tagged correctly)
7. Tiny webUI flaw: The vertical scroll bar is covered by the top menu bar. If you have a longer queue and the scroll bar gets smaller, you cannot click the scrollbar and you need to scroll by mouse.

Please note all this as no complaint at all but as my personal feedback. Keep up the great work. I really love this project.

[semohr]

Great to hear it’s working! I can't imaging migrating to beets with 2tb of music, must have been tedious.

These points are all very reasonable. I’ll go ahead and split them into separate issues. We can discuss them further in the sub-issues 👍

[semohr]

Probably a beets issue or bad configuration on my side: Some artist folders were created multiple times but diffrently capitalized: Like "Agents of Time" and "Agents Of Time" and in some cases also like another folder called "Agents of Ti" (But the files have been tagged correctly)

The issue is more the tag providers here, e.g. musibrainz is community based and different member can submit different versions which may lead to this issue. While this is not supported from the ui directly (yet?), you should be able to do a beet modify to fix this.

[semohr]

Sorting feature. Not very important but nice to have if I could sort items by "state" and "match value"

We’re planning to introduce a session-based view, which won’t display the folder structure. Implementing sorting in this type of list should be significantly easier. Sorting in nested lists in general is quite difficult to implement.

[pSpitzner]

Thanks for this awesome report!

@semohr, @self, I suggest we add this issue this as one of the references to the docu, until we solve the whole "initial import" problem.