Some of the recent changes in lua library had changed contents of dryos variables and the dryos.dcim_dir.path (used in get_sidecar_filename() @ xmp.lib) does not work anymore.
Being on linux and using daktable+gimp i have to use IMG_1234.[CR2|JPG].xmp name to have it recognized and used by DT, so i've modified the get_sidecar to:
function xmp.get_sidecar_filename() -- {{{
return dryos.shooting_card:image_path(1) .. ".xmp"
end -- }}}
This refactor is what is causing the issue. Adapting this branch to the new API should do the trick,
Was considering to fix in the
PR after a1ex had a look again to the memory management backend.
Maybe try with "dryos.shooting_card:dcim_dir"
I made some changes in the XMP file format (to use the same as exiftool) and tried to save the xmp file line by line to lower the memory consumption..
Unfortunately now it crashes immediately after taking a picture (for a split of a second i can see an error with wiritng to the xmp file (which was working for me for a while, but apparently i broke something a bit later)) and all i end up with is a picture and an assert log
Right, I need to look into that. Maybe backing out b0a2f95 (i.e. re-applying 065ceae) could help.
Should be related to what a1ex said, I noticed the assert for first time in this new build, when switching lens selection; I can't remember if happened also to me under same circumstance now, but probably yes.
Btw: is there a way i could test these scripts in qemu on my own? restarting the camera, mounting the sdcard, copying scripts, unmounting sdcard, starting camera is pretty exhausting and annoying especially when all i find is yet another bug in my own code 
I really wanted this was possible at current stage, will make much less stressful and time consuming, but we need to wait a little more

btw: even during those bright moments when i had the xmp file written correctly, the exif data in cr2 and jpg (when i've switched to shooting to both formats) were showing the original unaltered data.
It's minded to work like this: Write metadata to .xml sidecart file (and/or in .mlv if full-res picture or raw video) instead of playing with .cr2 as is considered to be dangerous from what I've read in old discussion in this thread.
Maybe a safe way to inject into .cr2 can be found?
I've also split the lens name to brand+model, so the lens name is shorter (MOG would eat 20 bytes off the name
)
lenses = -- {{{
{
{ make = "Carl Zeiss Jena DDR", name = "Tessar 50mm f/2.8", focal_length = 50, manual_aperture = 2.8, serial = "8333263" },
{ make = "E. Ludwig", name = "Meritar 50mm f/2.9", focal_length = 50, manual_aperture = 2.9, serial = "1610554" },
{ make = "Meyer-Optik Gorlitz", name = "Telemegor 180mm f/5.5", focal_length = 180, manual_aperture = 5.5, serial = "1728275" },
{ make = "Samyang", name = "85mm f/1.4 AS IF UMC", focal_length = 85, manual_aperture = 1.4} -- serial = "A217D0264" }
-- { make = "", name = "", focal_length = , manual_aperture = , serial = "" },
} -- }}}
Shouldn't make really a difference in space usage... as Photoshop and similar, need to read the whole name to find correct lens correction profile.
Instead could be useful when you got really long lens name, as I can see from your pictures when selecting a lens from menu;
This could be implemented in the PR to have it in next build if you and others find useful; just need to concatenate "make" and "name" when writing ELNS block and XMP metadata.
I also had an issue where the lens.lua had crashed when i've selected the last lens in the list - 85mm Samyang. With something like "invalid parameter #3 for __nextval(", i can't remember now and since i'm procrastinating at work, i don't have my camera with me now to replicate it at the moment 
and one more thing - the serial number was written as "0" even when it was set cirrectly in xmp.properties.. no idea why..
Can you tried to reproduce this? I'm also interested to know if this is happening just in the latest build or not.
Note: the script iterate through attribute in lens table, It may be possible that is not finding the correct values after introducing "make" attribute.
Regarding serial number: save a .mlv and watch for metadata with the modified mlv_dump (compile from manual_leins_info branch). Just to understand if it's only related to XMP or if ML is't saving datas in memory.
Note: mlv_dump was modified in the pending PR to match metadata format, so I don't remember if was working good in old version (current build on ML site).
If you'd need any help with testing, let me know - i have 650D+6D and couple of non-chipped and chipped adapters to play with.
Yes, absolutely! I have just a couple of cheap adapter on which I based when writing the lens recognition of the script.
They show as "1-65535mm" for name and focal length.
Already refactored to a separate function just in case to make it easy to read and adapt.
function is_manual_lens()
-- Adapter with no AF Chip -> ID = 0
-- Adapter with AF confirm Chip -> name and focal length "1-65535mm"
if (lens.id == 0 or lens.name == "1-65535mm" or lens.name == "(no lens)") then
return true
else
return false
end
end
Can you check if also your adapter works like this? I imagine should be the same even if different makers, except for Dandelion adapters.
Also need more feedbacks about Raw video recording stability if you are daily video user.