As I said here, I think recording this information would raise confidence in Beets and allow it to become more lossless. It keeps more options open for beets development in the future. (Imagine taking a second pass at autotagging your library after it received an upgrade that’s better able to understand filenames).
To me the only question is if this should be a plugin or if it should be base functionality. I do welcome feedback if this is a bad idea somehow. What kind of tradeoff must be considered instead of adding fields willy-nilly?
Would this be a good template to follow for native flex attributes? Are there any other flex attributes in base beets? Everything else I see in beet fields was added by me or a plugin. How does the process of doing it in a plugin vs. base compare?
Are you suggesting that “/home/moonwind/Downloads/not_processed/please_tell_the_FBI_that_I_own_the_cd/all_metallica/ride_the_lighning/forwhotehbeltools.mp3” be placed into the file tags? Most of the time these are temporary holding places.
Hi, @RollingStar , it would be very handy this of recording original path and filename.
Have you arrived to any possibility of this implementation?
Have you or anyone a plugin or any way for doing this?
Thanks for any clue.
I can’t directly help you. I have a small test function that might help if someone wanted to continue working on it.
I do want to implement this, but I won’t have time for months.
This is a test case I was adding to test_files.py within /src/beets/test. It’s not finished.
def test_albuminfo_move_keeps_most_fields(self):
# any field not defined here, or tracked/created by a plugin, should not change with a move
# this uses the Python concept of a "key" / "value" pair rather
# than the beets concept of a "field". in here, "key" <-> "field".
import pdb
fluid_item_keys = ['path', 'mtime']
fluid_album_keys = ['path', 'artpath']
old_item_keys = {}
old_album_keys = {}
static_item_keys = self.i.all_keys()
static_album_keys = self.ai.all_keys()
# todo get old_dict and compare to new_dict
for ikey in fluid_item_keys:
# old_item_keys[ikey] = self.i.get(ikey)
static_item_keys.remove(ikey)
for akey in fluid_album_keys:
# old_album_keys[akey] = self.ai.get(akey)
static_album_keys.remove(akey)
self.ai.move(operation=MoveOperation.MOVE)
self.ai.store()
self.i.load()
new_item_keys = self.i.all_keys()
new_album_keys = self.ai.all_keys()
for ikey in fluid_item_keys:
new_item_keys.remove(ikey)
for akey in fluid_album_keys:
new_album_keys.remove(akey)
# is there a way to compare them non-iteratively?
for ikey in new_item_keys:
print(ikey)
pdb.set_trace()
self.assertEqual(static_item_keys[ikey], new_item_keys[ikey])
for akey in new_album_keys:
print(akey)
self.assertEqual(static_album_keys[akey], new_album_keys[akey])
The point of this test function is to verify that individual fields (such as artist name) do not change when the file location changes. The file path is a special case - it should change when the file location changes.
Are you suggesting that “/home/moonwind/Downloads/not_processed/please_tell_the_FBI_that_I_own_the_cd/all_metallica/ride_the_lighning/forwhotehbeltools.mp3” be placed into the file tags? Most of the time these are temporary holding places.
More power to you if you would like to beet scrub or whatever. My point is that the inverse can’t be done - you can’t pull original paths out of thin air years later. I continue to believe that making beets more lossless is a good goal for user-friendliness.
coming to this thread late, but i don’t see a big upside to adding this meta data to every record. i use import scripts that bind particular directories and keep track of the sources that way, outside of beets.