Added options to preserve modification times when tagging files.

[m-reiter]

See #7

[coveralls]

Coverage decreased (-2.1%) to 75.381% when pulling 89d3bfeec983a6666071dd3b23b99ee32e783564 on m-reiter:master into 2864814c6d9881b04a04cc794f54939d3a93b762 on desbma:master.

[desbma]

Thanks.

I don't understand the need to restore the original mtime, but add an offset to it. Could you explain a use case for this?

I left a review in the code for other (minor) stuff.

[m-reiter]

I don't understand the need to restore the original mtime, but add an offset to it. Could you explain a use case for this?

That's an idea I didn't come up with myself but stumbled across online while researching tools to add gain information. I see two potential use cases:

• If you keep your music collection in more than one place and sync it from the master copy, some syncing tools might not pick up the file changes if the timestamp is preserved exactly.
• Adding some seconds makes e.g. Logitech Media Server pick up the changes in a "changed or new" scan.

Unfortunately, I can no longer find where I saw the first one. The second one was mentioned in the Squeezebox community forum

[desbma]

• If you keep your music collection in more than one place and sync it from the master copy, some syncing tools might not pick up the file changes if the timestamp is preserved exactly.

• Adding some seconds makes e.g. Logitech Media Server pick up the changes in a "changed or new" scan.

Both can be solved simply by doing nothing, and letting the modified time be updated (the current behavior). Or am I missing something?

[m-reiter]

• If you keep your music collection in more than one place and sync it from the master copy, some syncing tools might not pick up the file changes if the timestamp is preserved exactly.
• Adding some seconds makes e.g. Logitech Media Server pick up the changes in a "changed or new" scan.

Both can be solved simply by doing nothing, and letting the modified time be updated (the current behavior). Or am I missing something?

Yes: Logitech Media Server (that's what I'm using, other software might behave similarly) treats the file's modification time as the time the music was added to the library. So if I just update all mtimes to the time of tagging, that information gets lost. As a result, when I'm browsing newly added music in my library, old stuff will show up instead. That's why I wanted the option in the first place. I admit that adding some seconds is a clutch, and probably one I can live without, but seeing that others see the need to do just that, I thought I'd add it in as well since it's basically no effort and I don't see it doing any harm. Whoever doesn't need it will just not use it.

[desbma]

OK, I see the use now, and I agree with you there is not real drawback to implement that.

However I think the option should simply have two possible choices "preverse file mtime" or "preserve file mtime + add 1 second". There is no real need to let the user add a custom number of seconds.

The best way to do that is probably to use choices=(0,1), nargs="?", default=None, const=0, for the argparse setup.

That way, the argument value is interpreted as such:

• None => default behavior, let the OS change file mtime
• 0 => restore original timestamp
• 1 => restore original timestamp + 1 second

[m-reiter]

I like your original suggestion without fixed choices better for several reasons:

• a numeric parameter with just one valid option (besides the default) just feels odd to me ;)
• I don't see a reason to use anything other than 1 second either but people come up with the oddest ideas
• most importantly: I couldn't come up with a help text for the fixed options version that didn't make the -h output look weird.

I've pushed a version with choices commented out now. If you don't agree that the help output looks odd, feel free to comment it back in. I'm happy with both versions even if I'm slightly leaning towards the free form one.

[desbma]

a numeric parameter with just one valid option (besides the default) just feels odd to me ;)

Ideally we should just add the smallest amount of time so that the file is detected as changed by the tools you mentioned, but that is not portable across filesystems and OSs, adding a full second is safer.

Another alternative for the option is to have something a bit more verbose like -p original (equivalent to -p) and -p offset which adds 1, but I'm not sure this is better (subjective I guess).

[desbma]

I have merged this with a few other minor cosmetic changes.

Thanks for the contribution.

[m-reiter]

Thank you for the interesting discussion!