Back to Top

Auto-update is redownloading audio files, but not in-progress file

11 posts / 0 new
Last post
korey99
Offline
Last seen: 1 year 2 weeks ago
Joined: 05/10/2010 - 08:42
Auto-update is redownloading audio files, but not in-progress file

Hi-

I have an issue I've been trying to figure out, but I'm stuck at the moment.

I have an audio podcast I listen to, and the symptom I noticed is that overnight, the file I was in the middle of listening to would be deleted.

In the evening, here was the situation. I was listening to the "5/7/2010 hour 1" episode, and paused it. It's about 39 minutes long, and I was 36 minutes in. I also had four more latest episodes downloaded and marked as New.

When I did a manual feed update, everything stayed the same. Just for kicks, I rebooted the phone and did a manual update again. Again, no change.

I have

DC set to automatically update feeds every 6 hours, and at 4:00am this morning the automatic update ran. Looking in the logs I see that all of the new episodes were re-downloaded, but the file I had been listening to was NOT. No new episodes had been published. DC also didn't know at what point in the file I had been listening.

I _think_ this has been happening with every automatic update, but I can't say for sure at this point. Any thoughts as to what I can try? I have listed out all of my settings below, FYI.

Thanks,
Korey

Droid Incredible

Feed options:

auto downloads: 500
auto delete: as space is needed
number of items: 500
virtual feed: unchecked
retain expired: checked
item identifier: title
make filenames unique: unchecked
always sort: unchecked
username and password set

Preferences:

feed update interval: 6 hrs
update feeds on start: checked
number of items: 10
auto downloads: 500
auto delete policy: none
on wifi: checked
on power: unchecked
headset connect screen: none
share media: checked
bind to headset: unchecked
pause headset disconnect: checked
pause on power removal: never
skip seconds: 30
seekbar behavior: long press
video player: integrated
action after external play: prompt
download success: unchecked
download failure: checked
audio playing: unchecked
enable swiping: unchecked
start on boot: unchecked
keep alive: while in forground or busy in background
user agent: blank
flurry: unchecked
enable item compression: unchecked

eric
Offline
Last seen: 2 years 5 months ago
Joined: 11/06/2008 - 22:02
Deleting of item

It sounds like the publisher is removing the item "5/7/2010 hour 1". That's the only thing that would cause the item to get deleted when it's in progress. DC tracks the item based on the title, if is removed, and then replaced, it's considered a new item.

You might want to change the feed option - "item identifier" to one of the other options. Depending on how permanent the feed's urls and filenames are, it may help out.

korey99
Offline
Last seen: 1 year 2 weeks ago
Joined: 05/10/2010 - 08:42
Hi Eric- I think your hunch

Hi Eric-

I think your hunch is correct. I saved the feed XML for two consecutive days. The episode is still present, but there are some changes.

Here's yesterday's XML (reformatted):


[item]
[title]Wed, May 12th, 2010 Hour 1
[link]http://www.bobandtom.com/
[itunes:author]Bob and Tom
[itunes:subtitle]The BOB&TOM Show Wed, May 12th, 2010 Hour 1
[enclosure type="audio/mpeg" url="http://rss.premiereradio.net/download/bobandtom/korey/4becf4f0cXXXXXXXXXXXXX/bobandtom/2010/05/Bob%20and%20Tom%20-%20May%2012%202010%20-%20Hour%201.mp3" /]
[guid]17a43c84XXXXXXXXXXXXX
[itunes:explicit]no
[itunes:keywords]Bob and Tom, Comedy
[pubDate]Wed, 12 May 2010 10:00:00 GMT
[/item]

For today, the only difference is in the URL. Everything is the same except that guid-like piece (4becf4f...). The other fields, including the guid, are constant.

Can you recommend a setting that will work the best for this situation?

Thanks,
Korey

eric
Offline
Last seen: 2 years 5 months ago
Joined: 11/06/2008 - 22:02
Changing xml

The only option is to try a different value for the 'item identifier' feed option. If you can find one that remains constant over time, then you should be ok.

korey99
Offline
Last seen: 1 year 2 weeks ago
Joined: 05/10/2010 - 08:42
Eric, what I don't understand

Eric, what I don't understand is which fields in the XML map to the choices in the DoggCatcher preference...

I have the item value set as "title", which in the XML itself (in the "title" element) remains constant and unique. If I set it to "link" I think I'm in trouble, since in the XML it's the same for every episode. Tonight I'm trying "filename" as an experiment.

Korey

korey99
Offline
Last seen: 1 year 2 weeks ago
Joined: 05/10/2010 - 08:42
Update: I tried the

Update: I tried the "filename" setting, and when I updated this morning, still everything re-downloaded again. I've switched over to exclusively manual updates so I can monitor what is happening.

That just leaves me the "link" setting to try. Does DoggCatcher use the guid field at all? That's what the guid field in the spec was designed for.

Acast and iTunes aren't exhibiting this problem.

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

DC doesn't use guid. It would be great if all feeds had it but most of them don't. Maybe you should be able to pick guid as the item identifier in dc, that may solve your problem.

I created an issue for this.

korey99
Offline
Last seen: 1 year 2 weeks ago
Joined: 05/10/2010 - 08:42
Thanks Eric. I'll keep

Thanks Eric. I'll keep experimenting to see if I can nail anything specific down. I'm trying out other podcasts to see what happens there.

korey99
Offline
Last seen: 1 year 2 weeks ago
Joined: 05/10/2010 - 08:42
summary - title comparison

Eric-

I've done some analysis, and here's the summary of what I've found.

Every night at midnight, this podcast's feed XML changes, even on weekends when no new episodes are being published. The ONLY change to an episode in the XML is to the enclosure URL attribute (item/enclosure/@url). The
filename itself in that attribute remains constant, but one of the folders in the full path changes.

As a result, DoggCatcher is redownloading each episode for this podcast every day. When I set the item identifier as "filename" or "title", that behavior occurs. (For completeness, when I set the item indentifier to "link", I only get one episode in the list, since that value is the same for every episode). During the day, feed updates work fine, since the full paths don't change. Other podcasts are working fine, with no redownloading.

Here's what I think isn't working the way it should: When the item identifier is set to "title", I really don't think this redownloading should be happening. The titles are never changing in this podcast's feed XML. An example title is "Fri, May 14th, 2010 Hour 4", and it NEVER changes.

Any thoughts?

Thanks,
Korey

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

I would be very surprised if the title wasn't changing at some point, maybe even only for a brief period of time, or maybe the item is going away briefly and then coming back. I only say this because title is used as the default for everyone's installations. We would surely have widespread problems if this isn't functioning correctly. I'll take a look at the code to verify though.

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

Via email, Korey and I determined this to be caused by the enclosure url to the media file changing.