After Factory Reset, Buzz Out Loud SD Video will not UPDATE. I have tried uninstalling and reinstalling Doggcatcher. All other feeds work fine. Buzz Out Loud MP3 updates normally (I update feeds manually).
In Particular, Will not download new "BOL SD" feeds on later date than the ones that initially download during feed install. (tried With wi-fi while plugged into charger and off of wi-fi as well). Thank you!
Forgot to mention that this is a Moto Droid with all updates / 2.2.1.
What's the error message that you see for the failed downloads?
When I press the update icon the update activity "thing" appears for about 8 or 10 seconds. No update. I am not seeing an error message.
I removed Buzz Out Loud SD. Tried installing Buzz Out Loud HQ. Same inability to update to new / latest podcast. Thank's for your help on this Eric.
P.S. I could remove and reinstall Buzz Out Loud. That would re-download with the most recent podcast available but not very convenient.
There was another post on this recently. It sounds like an ISP proxy is caching the feed, so to DC it looks like it didn't change.
Can you take a look at this post and see if your symptoms are the same?
http://www.doggcatcher.com/node/1482
First of all, I recently bought DG during the discounted period to support the efforts in Japan and very much appreciate your charity. Thank you.
But I'm having this same issue, that various CNET video podcasts do not update properly (daily programs like Buzz out loud and Loaded). Doing a manual update in DC typically does not show the recently added episode even when the feed itself (in a web browser) shows it.. I have not waited long enough to see when the new episodes eventually appear in DC, but I have been deleting and re-adding these 2 feeds daily. I don't think the issue is caching at the ISP level since there is no change even when switching to 3G from wifi. I'm running Sprint EVO Shift 4G (which is on Froyo).
Opening and closing the feed options has no effect-- updates still indicate no new episodes (even though there most certainly are).
Ok, I'll dig a little deeper into this and see if I can figure out what's happening.
Can you confirm the feed url for BOL that you are having the problem with. I want to be sure I'm working with the right one.
http://www.cnet.com/i/pod/cnet_buzz.xml
I created an issue for this - http://mantis.snoggdoggler.com/view.php?id=847
Thanks for posting.
It's video podcasts that I have trouble with:
BOL:
http://bolvideopodcast.cnettv.com
Loaded:
http://loadedhdpodcast.cnettv.com
Interestingly, both of these redirect to a feedburner link in a PC browser.
http://feeds2.feedburner.com/cnet/bolvideo (for BOL)
and
http://feeds2.feedburner.com/cnet/loadedhd (for Loaded).
Is that potentially the problem? Is Doggcatcher perhaps not following the redirect before comparing the updated feed with the local feed?
So I'm thinking there could be one of two problems here. There's either a bug in my code that handles http caching, or the feed you're getting back is not the latest one.
I checked the http caching and it look fine. I added some logging that will get into the next release, so we'll know for sure if the problem isn't resolved by then.
One thing you can do to sidestep the caching is to long press on a feed and press 'update'. This will avoid *any* caching of the feed. DC will fetch the feed and update the items. The result you see in DC after this will be 'updated'. This differs from the visible result when DC detects that the feed did not change, which is 'No change'. So, if you see updated, we fetched the feed.
Let me know what happens after you try this.
There is a *remote* possibility that updating the feed is failing (after we've fetched the feed). I can't really see how this wouldn't be a widespread problem though. Can you please send a log right after you do an update and you are seeing the problem. I'll see if there are any problems in there.
Thanks for posting.
Thanks Eric,
Long press of BOL video feed followed by "update" right now does not return the latest episode, which was posted 5 hours ago (It says "Published: 8 hours ago" and "Feed on phone is newer.") Log file was sent.
Here are the rest of today's observations. Loaded typically posts new episodes at 9 AM PDT (morning) and BOL posts them at 2 PM PDT (afternoon). Yesterday, I added the 2 feeds to DC at around 10 AM and got that morning's Loaded and the prior day's BOL as the latest, non-"done" episodes, as one would expect. After that, updates to DC throughout the day and evening did not result in any more episodes, even though I know BOL posted their new episode at 4:59 PM PDT. I tried this periodically over 2 different wifi networks and the Sprint cellular network. The messages in the Feeds list would either read "Feed on phone is newer," "No change," or "Updated." Wasn't sure if there was a specific pattern. I did not try to update again after midnight. I updated for the first time today this morning after I knew Loaded was posted, and got both the new Loaded and yesterdays' BOL. So it possible that DC is only actually looking at each feed once per day? Perhaps it only compares the date, not the time, when assessing whether the feed is newer/different?
I'm looking at the bol feed in a browser now and here's the latest episode
Buzz Out Loud: Ep. 1434: Fare thee well, Benito, the cake is not a lieFriday, March 25, 2011 4:27 AM
Note that this episode was publish at 4:27 in the AM pacific time.
The pubdate on this feed is
Fri, 25 Mar 2011 06:46:41 PDT
DC says the feed was published 12 hrs ago.
This all seems right.
The reason you will see a 'feed on phone is newer' is when DC gets a feed with a certain pub date, then later when it gets the feed again, the pubdate is older. We definitely don't want DC to update in this case because it will delete media that you are using (most recent items).
I've only seen this happen when I do an update on wifi, then move to a mobile network.
Where are you seeing an episode posted 5 hrs ago?
Which feed are you looking at that has that timestamp? If I follow the feed I gave above in Chrome:
http://bolvideopodcast.cnettv.com
I get redirected to http://feeds2.feedburner.com/cnet/bolvideo, and the latest episode has the entry you pointed out, with a different timestamp:
____________________
Buzz Out Loud: Ep. 1434: Fare thee well, Benito, the cake is not a lie
Posted: Fri, 25 Mar 2011 01:27:43 PDT
Play Now
On today's show, Benito announces that he's leaving us for his one true love, Gamespot--the good news is, he's still in the family, and more importantly, in the building, to help out the new guy, Steve Beacham. Be nice, everyone. Also, Google plays Honeycomb close to the vest, Groupon might be on a downward slide, and laser bongs and douche telecoms. Friday! --Molly
____________________
Is it possible that the 1:27 PDT timestamp for that episode (today's) is being interpreted as AM, since it doesn't specify? I know it was 1:27 in the afternoon that it was published (I was monitoring it's appearance in iTunes, and I'm in Pacific time). Moreover, they record the show live at 10:30 in the morning, so there's no way it was published at 1:27 AM.
EDITTED TO ADD:
I did add the BOL video feed to another RSS reader and it does indeed interpret the non-specific timestamps as AM instead of PM-- probably the cause of all the trouble.
But does that explain why that episode doesn't appear in the BOL feed in DC but I suspect it will when I check it tomorrow morning?
It's now 4:30 in the morning. I just updated DC and sure enough, I got the latest BOL episode (ep 1434 published yesterday afternoon). I hadn't noticed this before, but this is also happening with a third CNET video podcast I subscribe to (http://the404videopodcast.cnettv.com). It didn't have a new episode when I updated DC for the first time yesterday morning, and the new episode (published yesterday at 1:35 in the afternoon) didn't show up in my DC feed until just now, through repeated feed updates. As in the BOL feed, the timestamps for their episodes does not specfic AM or PM (but it's PM in the case of both BOL and 404).
Even more strange, at one point yesterday, I requested a full-fetch from my Loaded feed, after which, the feed lost all its episodes and the feed icon. Nothing was in the feed even when I toggled off the "hide done" option. When I updated DC just now, that feed got it's icon back, and 10 episodes flagged as new (not done). Note all 10 episodes were posted prior to noon yesterday.
All this suggests to me that DC is reading each feed only once per day. Subsequent updates seem to be ignored.
The timestamps are in 24hr format so that does indicate when it's pm (13-24 hr). If you are seeing the publishing of their media not matching reasonable times, then that could be part of the the problem.
Full-fetch - I don't think the full-fetch is going to get you anything that forcing an update (long press on feed, then update) will get you. Forcing an update will delete the thumbnail, clear the cache info for the feed, and then do any update. The rest of what you are describing is the expected behavior of toggling the full-fetch...deleting all the items, flagging all the newly added ones as new.
So is the summary here that you always get the items for the problem feeds about a day late?
You had mentioned that they posted items at 2pm. When that happens, we should see a pubdate in the feed of 14:xx, which it doesn't sound like there was. Could it be possible that the pubdate was 02:00 PDT in the feed but they actually published them at 14:00 PDT?
Re full fetch: I do think I understand the concept, but full fetch isn't doing what describe. What's happening with these feeds is that all exisitng data is erased, but even with an update, there's nothing to replace it. No new icon, no new items, nothing marked weither new or done. No items whatsoever. That remains the case until midnight, at which point, the next update regenerates the thumbnail, and shows some new items, all marked new.
Re CNET's timestamp: yes, items posted in the afternoon are marked in the 12 hr format without specifying PM.
I don't think it's as simple as getting the items a day late. It's that I only get 1 unique feed per day. I waited until 5 pm today to do my first update of doggcatcher, and I got the BOL episode that was posted in the afternoon. If I had done an update earlier in the day, I would not have gotten that episode until after midnight.
What I did was go into Feed Options and ticked "Full Fetch". This then made my feeds appear as if they were not present... (this again was for Buzz Out Loud Video feed only). Then I went back into Feed Options and unticked "Full Fetch", restarted my Droid. Now my feeds are updating so that I can download them. I Hope this is clear. I do appreciate your assistance very much Eric.
Matt
There are some feed options that cause the feed to get fetched from the publisher, even if the publisher says that it hasn't changed. I think toggling the full fetch does that.
What's going on here is that either the publisher or a proxy in front of the publisher is saying that the feed didn't change, so DC doesn't fetch the feed xml file.
I need to make a feed option to override this behavior so the feed is always fetched. It's not efficient but will resolve this problem.
Can you try open the feed option window for the feed, then just click ok. If that causes the feed to then update properly then that confirms that what I think is happening really is.
http://mantis.snoggdoggler.com/view.php?id=820
After performing the above my feed stopped updating Buzz Our Loud. I then tried ticking and unticking "Full Fetch" again (maybe should have not tried this again) with no positive results. To get today's Buzz Out Loud Video feed I removed feed entirely and "reinstated" it. Again this works but not uncomplicated. I appreciate all of your assistance.
Thanks for your assistance. Sorry I did not get back to you earlier. Real life gets in the way.
Your Application is the most used out of all my apps.
Thanks Eric.
Matt
not "HD"
You're welcome, no apologies needed.
"Could it be possible that the pubdate was 02:00 PDT in the feed but they actually published them at 14:00 PDT?"
The more I experiment, the more it seems like the faulty timestamps are the cause of the trouble. I have sent an email to CNET asking them to change their dating to the unambiguous 24 hour format.
------------------
I'd like to report a bug on the feedburner feeds for all of CNET's video podcasts (BOL, Loaded, 404, in particular). Both the publication date and the episode post dates report the post times in 12:00 hour format, rather than 24:00 format, without specifying AM or PM. Whenever my RSS reader updates feeds in the afternoon, it gets a feed with a pubdate that it thinks is from the morning. In the case of my particular feedreader, I get an error saying that the local feed (from the morning) is actually newer than the one it is getting from the server, and it won't update. What that means is for podcasts that post in the afternoon (like BOL), my feed-reader won't show me the new episode until very late in the evening (exactly 12 hours after the last time it checked the feed in the morning).
This would be easily rectified by requiring that feedburner specify the time in the unambiguous 24:00 hr format (e.g., post time would say 14:00 insteady of 2:00, for instance).
That makes sense and it's both an easy mistake to make and hard to notice.
Thanks for researching this and contacting cnet.
Eric, Cnet has not and may never respond. Can you relax the pub date comparison on a feed-by-feed basis to guarantee that the feed is updated with whatever is on the server? If I understand it correctly, is that what the "full-fetch" option should do? I still don't understand why full-fetch isn't resolving this issue.
For whatever reason, the AM/PM mixup doesn't prevent other podcatchers (such as iTunes) from showing the Cnet videos as they are posted.
The full-fetch is really not related to this. It is related to the feed "caching" which was what I originally suspected as a problem, but confirmed it wasn't. So I wouldn't focus on that.
What we would need to do is disable the validation that the feed is newer. I could do that but what would happen is this. Your feed would update and notice a new item, let's say item 10. It would get downloaded. Another update (with an older feed) would not contain item 10 and it would get deleted. Then later you would get a newer version of the feed and item 10 would come back. This is the situation that the pubdate validation prevents. I think the problem is unique to podcatchers running on devices that jump to different networks, mainly from wired to wireless...at least that's where I've seen the problem occur.
Thanks Eric,
re: Disabling validation that the feed is newer. I guess you know better than I how prevalent an issue it is that feeds presented by different ISPs are cached and therefore out-of-sync. But an option to override it on a per-podcast basis would be nice, given the reality of these particular podcast feeds. Alternatively, I would be satisfied with a manual *force update* option. Currently, my only alternative is to delete BOL and re-add it daily. Or just be very careful not to attempt updating that feed until 1 PM every day.
Sounds good, I created an issue for this - http://mantis.snoggdoggler.com/view.php?id=855