-
Notifications
You must be signed in to change notification settings - Fork 22
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Every album re-copied on each update #74
Comments
Hi @loafofpiecrust, thanks for reporting this. The config looks good to me and the second update should not try to copy the files again. You’re probably right that one of the plugins (or maybe some custom configuration) is causing the problem. Could you try to isolate the issue by disabling plugins and removing custom configuration? Then I can try to identify the problem with a simpler configuration. |
Thanks for the quick follow-up! I removed most of my plugins, reduced the config a little. I tested on my local BTRFS filesystem and things worked as expected. Then I tested again with my iPod which has a FAT32 filesystem and the issue recurred, but only with certain files. At first I added some FLACs and it worked fine. Then I added a few more albums and the issue happened with those files (MP3 and FLAC). Must be related to FAT32 filesystem. |
Okay sorry I forgot something. It seems like I made a mistake. The issue is that when I set my EDIT: I've since tested with my whole library again after letting it write |
Thanks for the update. I think I’ve found the problem and it has to do with modification times on FAT32 only having second resolution. I’ve pushed a patch and you can try it out to see if that fixes your issue:
|
…olutions Fixes #74 Signed-off-by: Thomas Scholtes <geigerzaehler@axiom.fm>
@loafofpiecrust, did you have a chance to try out my branch and see if it fixes the problem? |
I figured out how to build your branch to include it in my beets build, and tested it out. It does not appear to fix my issue, and it looks like your code change would avoid unnecessary |
@geigerzaehler There doesn't seem to be a pattern to which files are getting copied every time. Some are whole albums, some individual tracks. Perhaps more non-alphanumeric characters? I'm not sure. I do have several extra
|
I had to make a few more changes to use existing untracked destination files imported by my rsync script on this branch (EDIT: I also did remove art embedding since I use cover files). It seems to work fine now with yours and my changes together, updating metadata on my destination when necessary. Much more robust to manual renames/moves. As an aside, it does seem quite slow to finish when there are zero updates needed (4 minutes on my library!). |
Yes, you’re right! I didn’t realize that the problem was that files were added.
I took a look at your branch and I couldn’t quite figure out what the code you changed does. But to me it looks like it breaks things because we’re effectively doing I think it works for you at the moment because your basically skipping adding a file when the path is not found which seems to suggest that the paths don’t actually exist or One thing you could do is debug the code in |
I haven't been following this issue up to now; and I'm not sure that I understand correctly which steps are required to trigger the extraneous
Some questions to ponder:
|
I just started using this plugin, and the first time I ran
beets alt update ipod
after setting things up worked just fine. It took all night, as expected. However, after I added a new album to my library and then ranbeets alt update ipod
again, it first printed+
lines with the new tracks. Then it appeared to print all of my tracks and it looks like it's also going to take hours. I'm guessing it's re-copying over some files each time, which defeats the purpose of this for me coming from using a simplersync
script.Maybe I made a mistake at some point? Or maybe this is an interaction with the
extrafiles
plugin? Here's my config...config.yaml
The text was updated successfully, but these errors were encountered: