This plugin doesn't work if doing beet import in a compressed archive or a folder with multiple albums
msdos opened this issue · 16 comments
If I do beet import album1, the plugin works fine.
The plugin doesn't work:
- If I do
beet import albums, wherealbumsis:
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.
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?
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
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?
@Holzhaus if I remove the paths entry completely, it yells at me that paths doesn't exist.
configuration error: extrafiles.paths not found
@alex-phillips Try to add $albumpath/$filename in your paths configuration.
@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.
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.
@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.
Any update on this?
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?
Well that would explain it. My albums are on subdirectories of an artist folder i.e., Artist/Album Name.
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?
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.
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.
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.
Anyway, this issue is apparently resolved. Feel free to open a new issue if you encounter something like this again.