Hi,

I opened a bug for an issue I have seen when using Airtime which seems to cause duplicate show instances to be created.  I've tried to find consistent repro steps for the bug so it can be done with a fresh install of Airtime.

Here is a link to the issue on dev.sourcefabric.org:  https://dev.sourcefabric.org/browse/CC-6147

It looks like what is happening is that when there is a show with a repeat type, say weekly, and the repeat type is changed there will be two entries created in cc_show_days.   When ShowService.php is run it will create show instances for both entries in cc_show_days leading to duplicate entries showing up in the Airtime calendar.  I've attached a screen shot to the bug entry showing both the calendar and the entries in cc_show_days.

I have also seen an issue in our production Airtime server where there can be multiple entries in cc_show_days, but where one of them will have a blank or out of date entry in next_pop_date.  This is causing duplicate instances to be created when the calendar is advanced and createWeeklyRepeatInstances (in ShowService.php) is run, however in this case the instances will be made from the date in first_show until the date in $populateUntil.  This can lead to having lots of duplicate show instances when users advance the calendar.  

I think that this might be due to an issue with setNextRepeatingShowDate (in ShowService.php) because the query which updates next_pop_date in cc_show_days selects 1 row which matches the show_id, the day and has a repeat_type which is not -1.  If there are multiple entries in cc_show_days this query may select the incorrect row and will not update the proper cc_show_days entry.  If the cc_show_days row's next_pop_date is not updated, then the next time ShowService.php is run it will create duplicate show instances again.

I haven't filed a bug for the second issue because I don't have clear repro steps from a fresh install of Airtime.  However, I've changed the code on my production Airtime server so that setNextRepeatingShowDate takes a parameter which is the Id of the cc_show_day row, and performs the query and update to next_pop_date using the Id.  This seems to have eliminated the issue on our production environment.

Thanks,
Chris Gual