anarcat

@rbott > I think I remember that while looking at the code of `move-instance` we found out that it actually _does_ make some assumptions on the instance configuration which might...

so i have two more PRs here, #1698 and #1697 which fix the problems i've encountered so far. i'm at this error now: ``` 2023-03-13 20:56:10,146: Move1 INFO [Mon Mar...

On 2023-03-14 04:36:44, Rudolph Bott wrote: >> > because of the change in the instance network configuration (see above) we alter the network parameters (e.g. `link=br604` turns into `link=gnt-bridge,vlan=604`) and...

okay, so i think this ticket can remain for documentation, i filed #1697 for the python 3 stuff, #1698 for the NIC stuff (which could also be improved) and #1699...

In my case, the workaround was relatively simple: I added a *lot* (350+) of covers all at once, in a short timeframe, so I could rewrite the `update_at` fields on...

Hmm... well that setting doesn't do what I thought it did though: I thought that would set the `created_at` field on import, but from what you seem to be saying...

> That's correct. It is used for controlling how to display the Recent Added Albums view. okay, so couldn't this be made in reverse, like at import time, if that...

i see. so what are my options here? i guess i could remap the `created_at` timestamp to `updated_at` if the latter is lower? would that work?

> That should be the behaviour if you remove `ND_RECENTLYADDEDBYMODTIME: "true"`. The default behaviour (`false`) is to use import date (or birth date as per #1350) okay well maybe that's...

Ookay... I completely misread this! thanks for the clarification... is there a way to *rescan* files so that their creation date is retrofitted back into the `created_at` field?