Encoded files in alt are encoded again during `alt update` about beets-alternatives

[wisp3rwind]

What versions of beets and beets-alternatives are you running?

Re-encoding only happens when the plugin can't find the previously encoded files (or, when you change the target file format (mobile in your case)). There's no other software moving these files around after you run alt update, right?

[seadowg]

What versions of beets and beets-alternatives are you running?

Looks like I'm using 1.4.9 of beets and 0.10.2.post1 of beets-alternatives.

There's no other software moving these files around after you run alt update, right?

No not as far as I know. I do sync the alt directory over Dropbox, but I tried running twice with Dropbox paused (just in case) and still see convert: Encoding lines.

[wisp3rwind]

I guess I'm out of real ideas on what's going on here... a few things to try might be

• run beets in verbose mode (-vv), although I doubt that the log will provide useful details
• What type of file system is this on?
• Manually inspect the destination folders: Do the destination files show up? Do they have the expected file names/extensions (mp3)?

[seadowg]

What type of file system is this on?

On a MacBook Pro running Big Sur, so it's APFS. I guess the one quirk I know off the top of my head if the case insensitivity and I definitely have capitalized dir names in my paths (Dropbox for instance).

On thing that's interesting running with verbose mode is that it looks like the mp3s are copying as well:

alternatives: copying /my/alt/library/dir/Jacques Greene/Phantom Vibrate EP/01 No Excuse.mp3

I don't know if you'd expect that log or not if the file is already there. Inspecting the directory, it does seem to be:

> ls /my/alt/library/dir/Jacques Greene/Phantom Vibrate EP/
01 No Excuse.mp3	02 Feel What.mp3	03 Night Tracking.mp3

Also inspecting the alt library for something that's been converted:

convert: Finished encoding /my/beets/library/dir/YOB/Atma (Deluxe Edition)/05 Adrift In The Ocean (2021 Mix).flac

> ls my/alt/library/dir/YOB/Atma\ \(Deluxe\ Edition\)
01 Prepare The Ground (2021 Mix).mp3
02 Atma (2021 Mix).mp3
03 Before We Dreamed Of Two (2021 Mix).mp3
04 Upon The Sight Of The Other Shore (2021 Mix).mp3
05 Adrift In The Ocean (2021 Mix).mp3

[wisp3rwind]

On a MacBook Pro running Big Sur, so it's APFS. I guess the one quirk I know off the top of my head if the case insensitivity and I definitely have capitalized dir names in my paths (Dropbox for instance).

Case-(in)sensitivity sounds like a plausible reason for this (although I don't yet see how exactly).

On thing that's interesting running with verbose mode is that it looks like the mp3s are copying as well:

alternatives: copying /my/alt/library/dir/Jacques Greene/Phantom Vibrate EP/01 No Excuse.mp3

I don't know if you'd expect that log or not if the file is already there. Inspecting the directory, it does seem to be:

That's similar to the unexpected conversions; shouldn't happen if the file is already there and in the correct format.

> ls /my/alt/library/dir/Jacques Greene/Phantom Vibrate EP/
01 No Excuse.mp3	02 Feel What.mp3	03 Night Tracking.mp3

Also inspecting the alt library for something that's been converted:

convert: Finished encoding /my/beets/library/dir/YOB/Atma (Deluxe Edition)/05 Adrift In The Ocean (2021 Mix).flac

> ls my/alt/library/dir/YOB/Atma\ \(Deluxe\ Edition\)
01 Prepare The Ground (2021 Mix).mp3
02 Atma (2021 Mix).mp3
03 Before We Dreamed Of Two (2021 Mix).mp3
04 Upon The Sight Of The Other Shore (2021 Mix).mp3
05 Adrift In The Ocean (2021 Mix).mp3

Nothing suspicious here.

---

You mentioned running 0.10.2.post1. Where is that coming from? The post1 suffix does not exist for an official release, is it a version that was modified by someone else?

[seadowg]

Case-(in)sensitivity sounds like a plausible reason for this (although I don't yet see how exactly).

Yeah, it feels like it could be a problem. Are you testing on Linux/Windows? If you point me in the right direction maybe there's some code we can try debugging on Mac to check out whether the "file already exists" logic has problems with the case.

That's similar to the unexpected conversions; shouldn't happen if the file is already there and in the correct format.

Ok that makes me feel better. At least it's consistent.

You mentioned running 0.10.2.post1. Where is that coming from? The post1 suffix does not exist for an official release, is it a version that was modified by someone else?

If I do python3 -m pip install --user beets-alternatives, I get:

Downloading beets-alternatives-0.10.2.post1.tar.gz (10 kB)
.
.
.
Building wheels for collected packages: beets-alternatives
  Building wheel for beets-alternatives (setup.py) ... done
  Created wheel for beets-alternatives: filename=beets_alternatives-0.10.2.post1-py3-none-any.whl size=11042 sha256=0780de20ee99c65ccade736f8cf3c5a7ccbaa68b7ccbb2f6963cc9a1d63150f2

I omitted all the extra dependency checking in the output. Does that not look right? Sorry I've not done much python dev in my life so very much inexperienced when it comes to pip. It does look post1 is the latest version on https://pypi.org though: https://pypi.org/project/beets-alternatives/#history. Is that not expected?

[wisp3rwind]

Case-(in)sensitivity sounds like a plausible reason for this (although I don't yet see how exactly).

Yeah, it feels like it could be a problem. Are you testing on Linux/Windows? If you point me in the right direction maybe there's some code we can try debugging on Mac to check out whether the "file already exists" logic has problems with the case.

Yes, and there seem to be more problems on case-insensitive filesystems anyway: #66
Gathering more detailed debug logs seems like the way to go, but I'd have to think about what to actually look for. Not sure whether I'll find the time to do so soon.

I omitted all the extra dependency checking in the output. Does that not look right? Sorry I've not done much python dev in my life so very much inexperienced when it comes to pip. It does look post1 is the latest version on https://pypi.org though: https://pypi.org/project/beets-alternatives/#history. Is that not expected?

Oh, that was probably due to #64; sorry for the fuss!