Network time-outs cannot be caught because the exception occurs in the transaction layer. (ie. the scheduler throws the exception but the next time the very same URL will probably cause the very same network problem again.)

However, if a global variable (e.g. app.data.processing) is set to the ID of the feed that is currently being requested and reset to null not before the URL could be retrieved this variable can be checked against null at the beginning of the next schedule. If it contains a value the current feed as stored in app.data.feedcnt must be increased by 1 (just as the feed's error counter, btw.) and the problem at least should be circumvented.