Back to Top

After Factory Reset Buzz Out Loud SD Video will not update

27 posts / 0 new
Last post
mattsdoggcatcher
Offline
Last seen: 11 years 3 months ago
Joined: 12/13/2009 - 20:53
After Factory Reset Buzz Out Loud SD Video will not update

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!

mattsdoggcatcher
Offline
Last seen: 11 years 3 months ago
Joined: 12/13/2009 - 20:53
After Factory Reset Buzz Out Loud SD Video will not update

Forgot to mention that this is a Moto Droid with all updates / 2.2.1.

eric
Offline
Last seen: 2 years 3 months ago
Joined: 11/06/2008 - 22:02
Error msg?

What's the error message that you see for the failed downloads?

mattsdoggcatcher
Offline
Last seen: 11 years 3 months ago
Joined: 12/13/2009 - 20:53
no error message...

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.

eric
Offline
Last seen: 2 years 3 months ago
Joined: 11/06/2008 - 22:02
ISP proxy

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

sbono13
Offline
Last seen: 11 years 3 months ago
Joined: 03/23/2011 - 21:21
First of all, I recently

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).

eric
Offline
Last seen: 2 years 3 months ago
Joined: 11/06/2008 - 22:02
BOL url

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.

sbono13
Offline
Last seen: 11 years 3 months ago
Joined: 03/23/2011 - 21:21
It's video podcasts that I

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?

eric
Offline
Last seen: 2 years 3 months ago
Joined: 11/06/2008 - 22:02
HTTP caching

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.

sbono13
Offline
Last seen: 11 years 3 months ago
Joined: 03/23/2011 - 21:21
More observations

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?

eric
Offline
Last seen: 2 years 3 months ago
Joined: 11/06/2008 - 22:02
bol

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?

sbono13
Offline
Last seen: 11 years 3 months ago
Joined: 03/23/2011 - 21:21
Which feed are you looking at

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?

sbono13
Offline
Last seen: 11 years 3 months ago
Joined: 03/23/2011 - 21:21
Finally got the new BOL episode

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.

eric
Offline
Last seen: 2 years 3 months ago
Joined: 11/06/2008 - 22:02
am/pm

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?

sbono13
Offline
Last seen: 11 years 3 months ago
Joined: 03/23/2011 - 21:21
Re full fetch: I do think I

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.

mattsdoggcatcher
Offline
Last seen: 11 years 3 months ago
Joined: 12/13/2009 - 20:53
My prob mirrored #2 "video feeds will not renew" (in above link)

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

eric
Offline
Last seen: 2 years 3 months ago
Joined: 11/06/2008 - 22:02
Feed updating

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

mattsdoggcatcher
Offline
Last seen: 11 years 3 months ago
Joined: 12/13/2009 - 20:53
I opened feed option window for the feed, then I clicked OK

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.

mattsdoggcatcher
Offline
Last seen: 11 years 3 months ago
Joined: 12/13/2009 - 20:53
Buzz Out Loud HD is updating / and downloading

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

mattsdoggcatcher
Offline
Last seen: 11 years 3 months ago
Joined: 12/13/2009 - 20:53
That was Buzz Out Loud HQ

not "HD"

eric
Offline
Last seen: 2 years 3 months ago
Joined: 11/06/2008 - 22:02
You're welcome

You're welcome, no apologies needed.

sbono13
Offline
Last seen: 11 years 3 months ago
Joined: 03/23/2011 - 21:21
Email sent to CNET

"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).

eric
Offline
Last seen: 2 years 3 months ago
Joined: 11/06/2008 - 22:02
Pub date/time

That makes sense and it's both an easy mistake to make and hard to notice.

Thanks for researching this and contacting cnet.

sbono13
Offline
Last seen: 11 years 3 months ago
Joined: 03/23/2011 - 21:21
Eric, Cnet has not and may

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.

eric
Offline
Last seen: 2 years 3 months ago
Joined: 11/06/2008 - 22:02
Cnet

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.

sbono13
Offline
Last seen: 11 years 3 months ago
Joined: 03/23/2011 - 21:21
Thanks Eric, re: Disabling

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.

eric
Offline
Last seen: 2 years 3 months ago
Joined: 11/06/2008 - 22:02
Validation disabling

Sounds good, I created an issue for this - http://mantis.snoggdoggler.com/view.php?id=855