Only last feed item is saved as node

It's fixed in the CVS.
Likely there will be a beta2 release today what will contain the fix.

I must say to get a bit frustrated with all the updates.

No offense, but beta1 is a beta version, needless to say.

every time something gets broken or needs to be fine tuned yet again

I hope you use stable and staging version of your sites so it really did not affect you. Have you had a really strong reason for updating? Generally speaking, in a live system, you should only apply security patches and that's all.

Not sure I can really re-open this issue but I am seeing this same behavior now FeedAPI 6.x.1.7-beta3.

The modules involved are:

FeedAPI Mapper 6.x-1.0
iCal Parser 6.x-1.1
FeedAPI 6.x-1.7-beta3
FeedAPI Node 6.x-1.7-beta3

In my case it seems that nearly ANY other combination of versions of these modules leaves me with a broken UI that won't give me a sample feed element to map from and only a couple fields to map, and no VEVENT fields whatsoever.

I will try rolling back to 6.x-1.7-beta2 to see if that behaves better.

UPDATE: Same behavior persists in 6.x-1.7-beta2. I built all new CCK types after changing versions, mapped and refreshed an instance of the new feed type and got this:

5 new item(s) were saved. 61 existing item(s) were updated.

The 5 items made it into my database as new nodes, the other 61 did not. There were 5 different kinds of events in this feed: Varsity Football, JV Football, Cross Country, Varsity Volleyball and JV Volleybal. In every case the LAST item of each type was saved, nothing else.

UPDATE 2: Tried the 6.x-1.x-dev version just for kicks. Same behavior. I got 5 nodes, 61 items without.

OK, I'm pretty sure I found the source of the problem in my case. I'm pulling an iCal feed from HighSchoolSports.net. HSS.net codes ALL events for a unique team with the same URL. That way when a user clicks on a particular team's event they are not presented with that individual event, but with the team's entire season schedule. Actually a nice feature in my opinion.

Unfortunately, there is logic in feedapi_node.module which tests for duplicate events based on matching URL or GUID. I don't know what the specification says about unique feed items but in the case of HSS.net this is simply too tight. Testing solely on the GUID is sufficient.

Therefore, I have modified my copy of feedapi_node.module to comment out the URL test block as shown here.

/*  Removing this block because HSS.net makes all URLs for any given sport duplicates!   MM 08/08/2009
  // Feed item is duplicate, if URL or GUID are duplicate or if they are both missing.
  if (isset($feed_item->options->original_url)) {
    $nid = db_result(db_query("SELECT fni.nid FROM {feedapi_node_item} fni JOIN {feedapi_node_item_feed} ff ON ff.feed_item_nid = fni.nid WHERE fni.url = '%s' AND ff.feed_nid = %d", $feed_item->options->original_url, $feed_nid));
    if ($nid !== FALSE) {
      return $nid;
    }
  } 
*/

Note that there is a block of code a few lines below this that tests again for matching URLs but does so if the option to check for duplicates across all feeds is checked. I think that test should be removed as well...at least for the feed I'm dealing with. I didn't implement that change yet since I don't need to check duplicates across feeds at this time.

I had the same problem and thank you Mark for working out the cause and a solution.

Seems like there should be an option: 'enforce url uniqueness', or something like that.

I agree with pdcarto, an option to enforce unique URL or not would be very handy.

Writing with another, loosely related, update as well...

In my original post above I mentioned that several combinations of the feedapi, feedapi_mapper and ical_mapper modules were leaving my system in a state where I was unable to see all the fiels and unable to map VEVENT parts entirely.

Did some more debugging and found that in those cases the structure of my feedapi table was corrupt. It appears that enabling some version(s) of feedapi (or prehaps feedapi_mapper) alters this table such that changing versions won't repair the damage. Specifically, my corrupt database had no VID or NEXT_REFRESH_TIME but did have a SKIP column.

Fortunately I had a working installation of these modules in another project so I exported the feedapi table from that one and imported the structure back into my target project. It "seems" to be behaving as expected now.

I have definitely good news for you who are struggling with this issue.
In the future you won't need to hack feedapi_node.module to change the logic of the decision whether an item is unique or not. FeedAPI Mapper 6.x-2.x branch has a feature to override the deduping logic in a user-configurable-way, this is exactly what is needed here. So I'd say, temporarily this quick hack is fine and once FeedAPI Mapper 6.x-2.x branch will have a release, this will be able to do that out of the box.

Thanks for the note Aron. Sounds good.
Since I reopened this issue I'll also attempt to set the status to closed at this time.

You are a god! Thank you for finding this.