Registration Date Repeat - unable to save repeat date value to registration type

I ran across this module and the thread relating to the date selection during registration and it seems to be exactly what I needed. Alas, after installation, I received these same errors. I was able to track down what I believe to be the issue on line 40 registration_date_repeat/registration_date_repeat.module. As the error mentions, there is a reference to an undefined property. I believe something may have changed in either Entity API or forms since the latest dev release of Registration Date which causes $registration = $form_state['registration']; from line 38 to store the entity itself in $registration, thus bypassing the need for the reference to $registration->entity.

I went through the file and replaced references to $registration->entity with $registration and this appears to have fixed the error. The lines in question are 40, 43, and 60. There are some other issues still hanging around that I'm trying to hunt down. If I can get it all squared away I'll try to roll a patch for this.

So, I've been looking into this a bit more and found some other issues.
To clarify, my setup is as follows:
Registration content type:

• Title: VIP Registration
• Date Field: name = field_vip_dates, repeating.
• Registration: defaults.

Registration Type:

• Title: VIP
• Machine name: real_life_vip
• Date field: name = field_selected_vip_date, no repeat, widget is Date Repeat for Registrations, the registration date repeat for the Registration content type is set to Dates.

As I mentioned in my first comment, references to $registration->entity all fail because there is no 'entity' id in the $registration array.
list( , , $host_bundle) = entity_extract_ids($registration->entity_type, $registration); pulls the same information as $registration->type.
$host_bundle now contains real_life_vip.
$host_entity_field_name = _registration_date_repeat_date_repeat_instance($instance['id'], $registration->entity_type, $host_bundle); pulls nothing because the stored variable is stored as 'vip_registration' => 'field_vip_dates' and not 'real_life_vip' => 'field_vip_dates'.
if (!$host_entity_field_name || !isset($registration->{$host_entity_field_name})) { always triggers because $registration->{$host_entity_field_name} does not exist.

at this point the function just returns and nothing happens...

I think something must have changed between when this module was written and Registration 7.x-1.3. I'm not entirely sure where Registration is keeping the information this module needs to function... I'll keep looking but any help would be greatly appreciated.

Ok, I got it hacked together! The main issues were 1: grabbing the correct host_bundle, and 2: getting the correct date field.

I was able to fix 1 using the following snippet

list(,$node_id) = explode('/', current_path());
$current_node = node_load($node_id);
$host_bundle = $current_node->type;

And to fix 2 I used the new $current_node to get the dates as follows
$registration->{$host_entity_field_name} = $current_node->{$host_entity_field_name};

There was another issue in registration_date_repeat_field_ui_submit that assumed the form wouldn't have any value and was preventing saving of the selection. Not entirely sure why this was there or if I fixed it correctly... Will someone please look over this?

These two fixes, along with the $registration->entity fix have yielded a somewhat working module!

There is still an issue with the dates being somewhat incorrect... Probably because the date field on the node has 1 date per occurrence and has already been pumped through date_repeat_build_dates().

Another major issue is that the selected date doesn't keep it's own count of registrations... It seems more useful to set a cap on registration per occurrence rather than per event in its entirety. Not entirely sure how to handle this, I may open a feature request.

I'm attaching a patch (needs cleanup) so others can catch up to where I'm at and look it over for issues.

Apologies, I accidentally left some sanity check calls in there uncommented.

there are still a few dpm statements there.