This plugin doesn't work if doing beet import in a compressed archive or a folder with multiple albums

[msdos]

If I do beet import album1, the plugin works fine.

The plugin doesn't work:

• If I do beet import albums, where albums is:

albums
├── album1
└── album2

• If I do beet import album.zip, a zip containing files and multiple files.

Don't know if this is really a bug or a limitation in beets Plugin architecture.

[Holzhaus]

The compressed archive use case is currently not covered by this plugin. However, the multi-album directory use case should work fine, as long as the files that you want to move/copy are inside the album1 or album2 directory. Could you post a directory tree including the file locations and your current plugin config so I can test this?

[alex-phillips]

The same thing happens to me. It's not that it doesn't 'work', but all of my extra files are put into the root directory of the artist as its destination and not the album.

my config:

extrafiles:
    patterns:
        all:
            - "*.log"
            - "*.cue"
    paths:
        all: $albumpath

[Holzhaus]

The paths section in your plugin config does not look right. The default path format is $albumpath/$filename, so it shouldn't be needed anyway. Can you remove the section and try again?

[alex-phillips]

@Holzhaus if I remove the paths entry completely, it yells at me that paths doesn't exist.

configuration error: extrafiles.paths not found

[msdos]

@alex-phillips Try to add $albumpath/$filename in your paths configuration.

[msdos]

@Holzhaus maybe the correct approach would be if no paths parameter is used, then use $albumpath/$filename as default.

The compressed archive use case is currently not covered by this plugin.

Is this a feature that needs to be added or can't be done? Anyways, I suggest adding this limitation to the README, right after A plugin for beets that copies additional files and directories during the import process.: This plugin doesn't support importing from archives.

Could you post a directory tree including the file locations and your current plugin config so I can test this?

I will try to do this to easy your testing. Thanks.

[msdos]

Strange... I can't reproduce the error anymore. I think I may have messed up the two problems, importing an archive and folders like I said above without realising.

But indeed, I just tested again and from archives is not working.

[alex-phillips]

@msdos It's still not working. It IS moving the files, but it's putting it directly inside the artist folder, not the album folder. Your change produces the same result.

[alex-phillips]

Any update on this?

[msdos]

It IS moving the files, but it's putting it directly inside the artist folder, not the album folder. Your change produces the same result.

That's unfortunate. My pattern is Artist Name - (Year) Album. I have everything in a music folder. Using this pattern I don't have this bug. Would you care to test so we can narrow the problem?

[alex-phillips]

Well that would explain it. My albums are on subdirectories of an artist folder i.e., Artist/Album Name.

[Holzhaus]

@alex-phillips

configuration error: extrafiles.paths not found

This should be fixed in the latest git master version.

Well that would explain it. My albums are on subdirectories of an artist folder i.e., Artist/Album Name.

Nope, that should not make a difference. For what it's worth I'm using that format as well. I guess something is wrong in your config. Could you please post the output of beet config and the output of beet -vv import /path/to/file when using the latest git master version?

[alex-phillips]

@Holzhaus

beet config output:

plugins: fetchart embedart scrub replaygain lastgenre web importadded ftintitle extrafiles
directory: /music
library: /config/musiclibrary.blb
art_filename: cover
threaded: yes
original_date: yes
per_disc_numbering: no

paths:
    singleton: Non-Album/$artist $title
    comp: Compilations/$album%aunique{}/$track - $title
    albumtype_soundtrack: Soundtracks/$album/$track $title

import:
    write: no
    copy: no
    move: yes
    resume: ask
    incremental: yes
    quiet_fallback: skip
    timid: no
    log: /config/beet.log

match:
    preferred:
        countries: [US, GB|UK]
        media: [CD, Digital Media|File]
        original_year: yes
importadded:
    preserve_mtimes: yes
    preserve_write_mtimes: yes
ftintitle:
    auto: yes
    drop: no
    format: feat. {0}
lastgenre:
    auto: yes
    source: album
    whitelist: yes
    min_weight: 10
    count: 1
    fallback:
    canonical: no
    force: yes
    separator: ', '
    prefer_specific: no
embedart:
    auto: no
    maxwidth: 0
    compare_threshold: 0
    ifempty: no
    remove_art_file: no
fetchart:
    auto: yes
    cautious: yes
    cover_names: cover front art album folder
    fanarttv_key: REDACTED
    google_search: no
    enforce_ratio: yes
    sources: filesystem coverart itunes albumart amazon google wikipedia
    minwidth: 0
    maxwidth: 0
    google_key: REDACTED
    google_engine: 001442825323518660753:hrh5ch1gjzm
    store_source: no
extrafiles:
    patterns:
        all: ['*.log', '*.cue']

    paths:
        all: $albumpath/$filename
replaygain:
    auto: no
    overwrite: no
    backend: command
    targetlevel: 89
    r128: [Opus]
    command: ''
    noclip: yes
scrub:
    auto: no

replace:
    ^\.: _
    '[\x00-\x1f]': _
    '[<>:"\?\*\|]': _
    '[\xE8-\xEB]': e
    '[\xEC-\xEF]': i
    '[\xE2-\xE6]': a
    '[\xF2-\xF6]': o
    '[\xF8]': o
    \.$: _
    \s+$: ''
web:
    host: 0.0.0.0
    port: 8337
    cors: ''
    cors_supports_credentials: no
    reverse_proxy: no
    include_paths: no

I'll have to provide output from latest git later.

[alex-phillips]

It looks like the latest git version fixes this issue. How often do you guys push to pip? I'd like to be able to install this via pip for easy upgrade path.

[Holzhaus]

Are you sure that you were using the latest pip version 0.0.5 before you switched to git master? I didn't change anything that might have fixed the issue since the last published version in 0.0.5.

[Holzhaus]

Anyway, this issue is apparently resolved. Feel free to open a new issue if you encounter something like this again.