Update removes initial_key and bpm tags


Hi. I’m new at beets and in the process of setting up my config file etc etc. I’m also doing testing to make sure that the behavior is what I expect. When I’m done, I’ll let beet loos on my full collection.

I noticed a funny thing today. I have a sample file that I use to test my new tags. It has no tags embedded in the file. I know this because I did a ffprobe of the file and see no tag info.

I run a import:
beet import -s ~/Downloads/myfile_something_snow_something.mp3

All works fine. I look at the tag info:
beet edit --all snow
Including the lyrics that I now have, there is 283 lines of tags…
I double check this again with ffprobe and I can see all the tag info is there.
This is all wonderful, great and as expected.
I can re-import the same file, the same process runs, and I get told that I have a duplicate, and I remove the old file.

Then, I did a:
beet update -p

Beet tells me:
initial_key: C ->
bpm: 155.558242798 ->

I do not understand why? I go from no tag info, to all, then immediately doing a update, 2 fields gets blanked out.

Can someone explain to me the behavior?

I run beet 1.4.5
Python 2.7.13



I don’t see an obvious reason why his would be. If this seems like a reliably reproducible problem, could you please file a bug with complete details (and sample files) that can let other people observe the same behavior?


Sure. Let me try the same on my home PC tonight and see if I have the same there.



Sorry I took so long to reply.

So I did the same test at home, same results:
initial_key: C ->
bpm: 155.558242798 -> 0
The interesting thing is that my other test music is different. With them I get about 50% that will round the bpm:
bpm: 126.024734497 -> 126
bpm: 81.6080551147 -> 81
bpm: 148.046066284 -> 148
bpm: 132.799667358 -> 132
bpm: 139.991195679 -> 139
bpm: 106.260391235 -> 106

That I believe is not an issue. This is just interesting.