PDA

View Full Version : Stream episode links block download?



sdp0et
04-26-2013, 12:26 PM
I am very happy that CDS is happening. I have a question that I can't figure out. It seems similar to
http://www.beyondpod.com/forum/showthread.php?1186-Episodesync-auto-downloads-episodes-from-synced-device but kind of the opposite.

Until a few days ago I used my tablet for listening. With CDS I can now use my phone on my motorcycle and without the hassle of manual syncing. I set up my phone with a backup of my tablet's installation (configuration only, not downloads) then changed most of the feeds to download 0 episodes, and increased the number for short and feeds that don't need as much focus when listening. This occurred on 3.10.15beta for the tablet and 3.10.10 or 15 for the phone (I just updated the phone to the new beta and didn't check first). Both devices are on their appropriate 3.10.20beta builds.

The issue I have is that stream links are not being replaced with actual downloads.


"If you download episode on a device, and your other devices don't have it already, it will be added to them as a new "streamable" episode. (If your feed is set to download episodes, this "streamable" episode will be automatically downloaded during the next scheduled update). "

Both devices are set to 6 episodes of Feed A. Tablet already has them, and Phone says "I don't, let me add some stream links." Two auto-update cycles for that feed have gone by there are still 6 "streamable" episodes and 0 downloaded ones. I have multiple feeds with this same problem, just different numbers.

I am worried that deleting the streaming ones and allowing the phone to download them will just create the same issue on the tablet. It looks like I can tell the streamable episode to download, but I can't do that on my work's wifi and don't think about it at home (which is why I had to find a podplayer that let's me schedule these things.)

I think what I need to do is tell these episodes to download manually and see if the problem continues. I just manually downloaded 2 of the 6 and told the phone to manually update the feeds and it was satisfied that the feed had 6 episodes. Both devices are now set to only add manually sent episodes. I wanted to ask if what I am experiencing is intended bevaviour or does the Help File state that these streamable episodes should be getting replaced.

edit:
All feeds on both devices are set to "Download episodes in order." I am unable (tablet is wifi only) or unwilling (phone data plan concerns) to stream episodes.

juwlz
04-26-2013, 02:03 PM
Both devices are set to 6 episodes of Feed A. Tablet already has them, and Phone says "I don't, let me add some stream links." Two auto-update cycles for that feed have gone by there are still 6 "streamable" episodes and 0 downloaded ones. I have multiple feeds with this same problem, just different numbers.Is that 2 scheduled updates on the phone? And is the phone definitely set to download the latest <n> episodes for those feeds?

Is the scheduled update time on the phone before or after the scheduled update time on the tablet? There were some issues in earlier versions where the update order could cause a problem, but I thought those had been resolved in 3.1.20 (phone) and 3.10.20 (tablet).


I wanted to ask if what I am experiencing is intended bevaviour or does the Help File state that these streamable episodes should be getting replaced.
The fundamental principal with BP's Episode Sync is that each device is in control of its own settings, download rules, etc., and that what happens on other synced devices merely influences its decisions. (e.g. it won't play an episode you've already played on another device, because it knows you've already played it.) This means that if the phone is set to download < p > episodes, and the tablet is set to download < t > episodes, they should both do so.



All feeds on both devices are set to "Download episodes in order." I am unable (tablet is wifi only) or unwilling (phone data plan concerns) to stream episodes.
Ah - that may be the issue. Depending on your feed settings, auto cleanup rules, etc., it may be that the phone knows that the tablet has 6 episodes. However, because you didn't copy the download history from the tablet, the download rules on the phone are telling it to get the 6 OLDEST episodes from the feed that the phone hasn't downloaded, but because it's already got 6 more recent ones marked for streaming, it thinks it shouldn't download any.

"Download in order" is intended for things like audio books or courses where it's important to start right at the beginning with Chapter / Lesson 1, and follow that with Chapter / Lesson 2, etc. For normal "newsy" podcasts, you'd normally want the most recent 6. (You can still PLAY them in chronological order - you just don't need to start right back at the first episode ever published.)

If that doesn't help shed any light on what's going on, it may be helpful to check the sync logs and download logs on both devices to see what they say about these feeds.

Julie

sdp0et
04-26-2013, 04:12 PM
Is that 2 scheduled updates on the phone? And is the phone definitely set to download the latest <n> episodes for those feeds?


Yes to both. That feed is set for a certain time nightly, and it has been 2 nights. The manual update overwrote the log, but I am pretty sure it was mentioned as checked. The new update log shows "Processed Feed is Empty!" I don't know if that means empty of items that need to be downloaded or if it thinks there are no new episodes period. The feed has episodes when I check it on both devices. The 6 episodes are from about 6 moths ago, so there are already downloaded episodes before these 6 and a couple dozen un-downloaded ones after.



Is the scheduled update time on the phone before or after the scheduled update time on the tablet? There were some issues in earlier versions where the update order could cause a problem, but I thought those had been resolved in 3.1.20 (phone) and 3.10.20 (tablet).


The times are the same. The phone's settings are a copy of the tablet's. With both devices on 3.1.20. I'll see what happens tonight.



The fundamental principal with BP's Episode Sync is that each device is in control of its own settings, download rules, etc., and that what happens on other synced devices merely influences its decisions. (e.g. it won't play an episode you've already played on another device, because it knows you've already played it.) This means that if the phone is set to download < p > episodes, and the tablet is set to download < t > episodes, they should both do so.


This seems to be working. For the first few days, the tablet would not let sync delete episodes, but they were still set to 100% listened and ignored by Smartplay. That of course prevented the tablet from downloading new episodes, but that was expected. But at the moment, it appears that the injected stream episodes are counting as episodes and not being downloaded.



Ah - that may be the issue. Depending on your feed settings, auto cleanup rules, etc., it may be that the phone knows that the tablet has 6 episodes. However, because you didn't copy the download history from the tablet, the download rules on the phone are telling it to get the 6 OLDEST episodes from the feed that the phone hasn't downloaded, but because it's already got 6 more recent ones marked for streaming, it thinks it shouldn't download any.


There may be something to this. At first look, it appeared that the download history had been transferred to the phone, but looking at the history of the example feed on the phone, the very old episodes (about 4 years, 3 weeks old) have "Re-Download" but the old ones after that are "Download". Maybe only part of the history came with the backup? Another feed has all episodes except the current one marked as not downloaded.

When you say "download history" are you talking about an internal list of what state known episodes are in(read/downloaded)? There are no options in the Backup action to include or exclude history. One either backs up or doesn't. My tablet has a file "BeyondPodItemHistory.bin.autobak" or "TrackState.xml.autobak" that are a different sizes on each device (though some of the phone's autobak files are larger than the tablet's). Are these what you mean? Is there a way to manually sync the download history (maybe copy one or more files)?

I don't know if it's related, but I had issues with "read" vs "downloaded" on the tablet when I got 3.1.11:
http://www.beyondpod.com/forum/showthread.php?1092-Download-management
Maybe some of these episodes ended up with some weird combination of read and downloaded flag?



"Download in order" is intended for things like audio books or courses where it's important to start right at the beginning with Chapter / Lesson 1, and follow that with Chapter / Lesson 2, etc. For normal "newsy" podcasts, you'd normally want the most recent 6. (You can still PLAY them in chronological order - you just don't need to start right back at the first episode ever published.)


I only started getting into podcasts about a year and a half ago. When I start listening to a new one, I usually want to start at the beginning. "In Order" lets me have my local-qeue that BP will add the oldest, non-downloaded episode to, adding another one only when I delete one. My understanding of "Download Latest" is that in starts from newest to oldest, and newer episodes will replace older ones, rather than waiting until I am done with them. If I misunderstand this, I can try it as you suggest.



If that doesn't help shed any light on what's going on, it may be helpful to check the sync logs and download logs on both devices to see what they say about these feeds.

Julie

By "download log" do you mean the "FeedupdateLog"? I've never been able to see more that the most recent update attempt. Since autoupdate has run twice and I did a manual one since these files appeared, I can't check what happened during update two days ago.

The feed I am using as the example has no mention that I can find in the synclog of either device. I checked some episodes that were in the log as pushed from the tablet to the phone, the all seem to be partially downloaded (with a yellow error icon). I listened to these, or parts of them. Even though BP is set to never stream, maybe I was streaming them without knowing. I was on bluetooth while driving, so wasn't looking. The partial ones that I only listened to part of are smaller than the ones I completed (while testing, the phone was not set to delete after completion).

sdp0et
04-26-2013, 04:24 PM
I just discovered something.

I have 7 feed categories, most based an listening priority, and a few for specific reasons. On the phone, Smartplay doesn't include 4 of these categories. Those categories have no episodes (real or streaming). These are set to only update every few days, so

The categories that smartplay uses all have streaming episodes. Is it possible that when I tell Smartplay to build the playlist, it knows which episodes I "should have" based on it knowing the tablet's history (since it is a clone of the tablet) so it tries to insert the episodes it thinks should be there, and creates streaming placeholders instead?

That doesn't explain why auto-update wouldn't replace them later, unless SmartPlay is using the "read" status and update is using the download status. Should both of these been stored in the backup?


_______

That manual update I mentioned earlier didn't finish, so one of the two episodes only downloaded about 10%. I just said to updated the feed manually and watched. It checked, and didn't care that of the 6 it can download, 4 are stream-links and one is incomplete. I don't know that I've ever run into a partial download, so only assume that BP would attempt to resume/finish if it could.

sdp0et
04-26-2013, 05:10 PM
One last piece of info, because I think it might piece things together. I didn't think to look before, but my tablet now has episodes it listened to (downloaded, played, then deleted) months and years ago.

My guess is that because the phone does not have the download history, it started at some earlier point (whatever that feed's "Get xxx episodes") and downloaded them, then synced. Then the tablet synced, saw these episodes and realized it didn't have them, so it (assumption, I didn't see this step) added the stream placeholder, which were replaced by actual downloads during one of its updates.

This shifts my thinking to the following (arbitrary numbers): The phone wants to download episodes 21-26, but because it has streaming links for 41-46 it won't because that feed's episode allowance is filled. But it won't download 41-46 because they are not the oldest, non-downloaded episodes. Some feeds that were not filled (I raised some limits on the phone to focus it more on certain feeds than the tablet) and the phone started with the oldest valid it found then updated those to the tablet. These episodes were already in the tablet's history as read and downloaded, but it may not check that and just assumes that sync won't lead it astray. This might be desirable behaviour if the devices have synced history, but is troublesome when they don't.

This still leaves me with the question of why in some of the phone's feeds the downloaded and not downloaded episodes are a) not what the tablet (should have?) put in the backup and b) why they are inconsistent. One feed has them mixed in (not split by an arbitrary date, but a few downloaded, one not, three downloaded, ten not, etc).
___
On the tablet, I Sent a Feed to Other Devices. The phone's log says



--- DOWN sync =>St:+, Sync:DP : Fri Apr 26 16:11:05 CDT 2013 => FEED_PUSH (V) Grammar Girl Quick and Dirty Tips for Better Writing (1. Favorites, Uncategorized)
--- Last remote change timestamp moved to: Fri Apr 26 16:11:05 CDT 2013
--- Applying 6 remote changes...
--- APPLY remote change for invalid episode: http://www.qdnow.com/grammar.xml. Change ignored!
--- APPLY remote EPISODE DELETED. Local episode is currently 'LOCKED'! Ingoring deletion of
<snip a few episode updates>
--- APPLY sync FEED MODIFIED. Feed:Grammar Girl Quick and Dirty Tips for Better Writing (1. Favorites, Uncategorized)
--- Changes applied!

but the feed still has random episodes that say "Download" instead of "Re-download". Judging by how quick it was, my guess is that it syncs the name, url and categories but not history. Is this correct?

sdp0et
04-27-2013, 05:31 PM
I listened to some of the episodes on the tablet that are streamable episodes on the phone.

1) Despite finishing (and auto-deleting) the tablet episode, the phone episodes only updated to about 80% complete and were not deleted. The phone is set to accept deletes.

2) I manually deleted them on the phone, and did an update. As before, the BP downloaded old episodes.

3) Sync added streamable versions of these old episodes to the tablet's copy of the feed. Initiating an update on the tablet feed downloaded the streamable episodes. I deleted them manually. Under current circumstances this is a bit tedious, but seems like it would be useful if things were working as expected.

4) I updated both devices to 3.1.21. (Phone downloaded episodes now seem to be actually deleting when deleted on the tablet).

5) I created a new backup of the tablet and restored it on the phone. The warning clearly stated that my local download history would be replaced.

6) The local download history on the phone was not replaced. Updating feeds with room still downloads old episodes (episodes that the tablet won't download because it knows it already has).

Question: Could this possibly be a bug (or misuse) of Backup & Restore? The devices are on the same version (3.1.21) but one is phone and one is tablet.

Question: in 3.1.21 the phone no longer has an Episode Sync option in the menu for viewing the log or initiating a manual sync. I can view the log through the menu in Settings, but can't initiate a manual sync or view "pending changes". It is still in the tablet menu as in 3.1.20. Was this moved or excluded?

StefanK
04-29-2013, 05:53 PM
I think there are may be several different issues that are probably getting overlapped. Hopefully we can split them and see if can resolve them one by one.
Let's start with backup and restore - when you back up on one device and restore on another, BP should transfer all settings and read/downloaded history. Backup/Restore does not transfer the media files themselves, so each downloaded episode on the tablet, it will be transferred as a "streamable" episode on the phone (but if you manually move the media file itself to the appropriate folder on the phone it will turn it back to "downloaded" episode). Backup/Restore is totally independent from the cross device syncing and one should not affect the other. Seems like that the first problem you are having is that the download history for some reason does not get transferred correctly. You can also see if that indeed is the case by opening a feed on the phone (so you can see the feed content wit Download/Re-Download buttons) and deleting one of the streamed episodes. If the episodes is in the history the download action should be "Re-Download" (instead of Download). If the download history did not get transferred correctly, this may be caused by the episode download path differs between the tablet and the phone. You can see the download folder on both devices in BeyondPod Settings > General Settings > Podcast Download Folder. When restoring the backup, BeyondPod has logic to detect the different path and adjust the restored data to accommodate it. It is possible that something is not working right with this logic.

Assuming that we sort out the issue with backup/restore, the logic for syncing and downloading should work like this: If you download an episode on the tablet and sync, the episode should appear as a streamable episode on the phone. If the episode feed on the PHONE is set to download episodes automatically ("Feed Podcast Episodes" in the phone's feed setting is set to "Download Latest Episodes") and you do a feed update (long press on the feed and select "Update Feed") it should download the remote episode regardless of any episode cleanup settings. You should see that in the update log. Can you try a "controlled" experiment on a feed and see if the above logic works for you.

As far as the missing "Episode Sync" menu option - it is has been removed from the public options (as it was designed only for debug purposes), but you can get it back if you need it. To get it back go to the advanced settings in BeyondPod and enter the "#" (without quotes) in the "Debug EpisodeSync" setting.

Stefan

sdp0et
04-30-2013, 02:38 PM
Thanks for the answers, Stefan.

I believe that it is the download history that is causing this. I did some manual adjustments of the priority feeds. For the ones I was close to current on, I just marked "all downloaded" then reversed the handful needed. For ones close to the start, I did manually marked the ones at the beginning. For the ones with a large number before and after, I shortened the "get last X episodes" to exclude the beginning and set what was left as downloaded. I'd rather not rely on this last one, as it will start skipping episodes if I get too far behind. But, when PhoneBP is "caught up" the syncing and downloading seems to work as I expect, which is what you described. I did this before your post, but I think it satisfies your request for a controlled experiment. Now hopefully we can figure out how to get the download history to transfer so I don't have to manually mark hundreds of episodes as downloaded every time I change or add a device.



You can also see if that indeed is the case by opening a feed on the phone (so you can see the feed content wit Download/Re-Download buttons) and deleting one of the streamed episodes. If the episodes is in the history the download action should be "Re-Download" (instead of Download).


This seems to confirm it. I went to a few of the feeds I have ignored and the episode kept the Download button after deleting the stream episode. Also, (nearly all of) the episodes that are older than it are all "Download" instead of "Re-Download." There are some feeds that have a mix of the two, so maybe some of the history



If the download history did not get transferred correctly, this may be caused by the episode download path differs between the tablet and the phone. You can see the download folder on both devices in BeyondPod Settings > General Settings > Podcast Download Folder. When restoring the backup, BeyondPod has logic to detect the different path and adjust the restored data to accommodate it. It is possible that something is not working right with this logic.


The phone is set to the external SDcard (/mnt/sdcard-ext/BeyondPod/Podcasts) while the tablet is internal (/storage/sdcard0/BeyondPod/Podcasts). I am not positive, but I think I restored the backup before I moved the folder to the sdcard.

What is weird is that the phone doesn't seem to know it is on the sdcard. When I installed, the storage location was internal (sdcard0) and the popup told me to exit BP and move the folder, which I did. PhoneBP says the current location is as above, but still lists (/mnt/sdcard-ext) as the alternate. The "how-to" popup tells me to close BP and move the folder from /storage/sdcard0 to /storage-ext/. Further, the phone creates backups in /sdcard0/BeyondPod/Backups/.

I exited BP and restarted, now it shows /sdcard0/BeyondPod/ (Maybe it detected the BeyondPod folder that was created for the backup?). History wast still wrong. But, now both devices have the exact same string for the download folder.

[The next part may be hard to parse, but I am trying to be specific]
With that variable removed, I created and restored a new tablet backup to the phone. No dice on download history. So, I on the tablet, I opened (single click, brings up page that seems to be from or copy of podcast site's episode page) two downloaded episodes in a feed (one currently on device and one already downloaded and deleted). The tablet has both as "unread" but both "downloaded". Toggling the "read" flag (blue radio button in lower right) and backup/transfer/restore made the episodes "read" on the phone, but still not "downloaded". I had to enable "ignore reader read status" in advanced options for all of this but it doesn't seem to make a difference for this issue as the downloaded flag is still wrong when transferred to device. I tried every combination of that setting on tablet(before backup) and phone(after restore) and downloaded flag was always false.

Q) Does read status in any way factor into the decision to download or not?

Q) Can we rule out that the read/downloaded flag confusion from http://www.beyondpod.com/forum/showthread.php?1092-Download-management is not related?

Q) Can I manually copy just the history without a full backup/restore?

dom2114
05-07-2013, 01:10 PM
Just wanted to say I found this thread extremely useful.
Decided to try out CDS today: backed up and restored BP from my phone to tablet, and didn't understand why feeds that were set to download the newest 5 episodes weren't downloading episodes on the tablet.
Thanks for Stefan, its because the download/read history is moved with the backup and so the tablet considered all the recent podcasts already downloaded.
First new episode that was published in the feed downloaded perfectly on both the phone and tablet and CDS seems to be working flawlessly for me.

BP has evolved quite a bit since the early days and there is now an incredible amount of functionality, but I think the team has done a great job in catering to all user levels.

Thanks as always.

StefanK
05-07-2013, 04:48 PM
sdp0et,

I am not sure why the download history does not get moved over. I did several experiments with backing up on one device and restoring on another and in all cases the download history moved correctly so there is may be something specific to your environment that I am missing. So let's try this experiment - hopefully it will narrow down what may be going wrong.
1. On the phone, Uninstall BeyondPod.
2. Rename the existing BeyondPod folder on the phone to BeyondPod_OLD (so now you should not have a folder named BeyondPod folder on any of your phone's SD cards).
3. Install the latest beta. It should now start with the default settings and use /sdcard0/BeyondPod by default (you can download a short episode to confirm that it goes indeed to /sdcard0/BeyondPod/Podcasts<Feed Name>
4. On the tablet, pick a feed and open it (so you see the list of episodes with push pins). Pick a couple of episodes that are not downloaded (gray pushpin) long press on one and select "Mark read. This will mark the episode as both "read" (the episode album art will be dim) and "downloaded" (the pushpin will get "..." symbol in it). You can mark this way several episodes for test.
5. Close the main BeyondPod window (just tap on back button) This will ensure that all changes are saved.
6. Do a fresh backup from the tablet and restore it on the phone (you don't need to copy the downloaded files from the tablet - just restore the backup). Phone should still use /sdcard0/BeyondPod as before.
7. Open the same feed on the phone (so you see the list of episodes with download/re-download buttons). Are the same episodes that have "..." in the pushpin on the tablet have "re-download" on teh phone. Also all episodes that are read on the tablet should be also "read" on the phone.

Now to the 3 questions you had.

Q) Does read status in any way factor into the decision to download or not? - no Read and Downloaded are totally independent. There are some actions that set both, but downloaded just means that the episode is in the download history. Episodes that are downloaded get added to the download history and once it is in the automatic download logic excludes it from the download (it never looks if it is read or not).

Q) Can we rule out that the read/downloaded flag confusion from http://www.beyondpod.com/forum/showt...oad-management is not related?. I don't think it is related

Q) Can I manually copy just the history without a full backup/restore? There is no easy way to do that as the download history is kept in the phone memory where you can't directly write (unless you have a root access). Backup/Roster actually does that (it just zips all relevant files from one device and restores them in the correct places on the other).

Stefan

StefanK
05-07-2013, 04:50 PM
dom2114,

I am glad you find CDS functionality useful and thank you for your support. It is still evolving so any feedback is appreciated.

Stefan

sdp0et
05-10-2013, 08:15 PM
sdp0et,

I am not sure why the download history does not get moved over. I did several experiments with backing up on one device and restoring on another and in all cases the download history moved correctly so there is may be something specific to your environment that I am missing. So let's try this experiment - hopefully it will narrow down what may be going wrong.
1. On the phone, Uninstall BeyondPod.
<snip>
7. Open the same feed on the phone (so you see the list of episodes with download/re-download buttons). Are the same episodes that have "..." in the pushpin on the tablet have "re-download" on teh phone. Also all episodes that are read on the tablet should be also "read" on the phone.


The episodes that I manually marked read (and therefore downloaded) transfer as downloaded (they offer the option to re-download on the phone, while the ones right before and after offer the "download", as expected. But, the "old" episodes in these feeds that were downloaded, listened to and deleted days, months or years ago are not correct. Some show the last X days or months as properly read/downloaded but ones before that are a mix of read/unread and downloaded/not downloaded (by far, most seem to have the correct "read" status, but not the correct "downloaded" status). Many of the feeds seem to be consistent going back a certain time, but then before that randomly distributed among the combinations of those flags. By consistent I meant that some number (arbitrary and different for each feed) of episodes going back from the current ones (the ones that were inserted as streaming) will be the same (read&downloaded, read&undownloaded, etc) but then that streak ends and episodes before that (again arbitrary and different for each feed) is "random".

Step #4 of your instructions seems to indicate that the backup/restore is doing history correctly, but that somehow my tablet's history is messed up. The installation folder on my tablet is old, so maybe there was a time that beyondpod was not marking episodes as expected, or maybe something got corrupted.

Almost all of my feeds are synched through Reader, so maybe Reader's heavy handed treatment of read flags based on time confused something along the way. When I start a new feed (new for me), I usually go back to episode 1 and listen through (sometimes this has resulted in my being 4-5 years behind). Since they come in as "read" by reader, I have had to reset the history on those feeds, and sometimes when BP couldn't detect duplicate episodes, I've had to manually toggle numbers of episodes manually.

I think that the issue is not related to Sync, and probably not even Backup/Restore. Likely, I've just had a long-term misunderstanding of how the read flag and downloaded flag interacted, and have been using BP "wrong".

I think my solution is going to be to use the multi-select on the tablet to "fix" it's history, and try another backup/restore once it's in the state I want. Unless you have another idea.

Edit: Are there plans to bring back manual download status on the tablet? Unless I use advanced option to ignore Reader's read flag, I can't do this on the table, and I really miss being able to setup an episode to re-download (say if accidentally skipped/erased or I just want to listen again) without manually redownloading it at that moment. I usually want it to happen during a scheduled automatic download. Conversely, Sometimes when I start a new feed (as explained above) I sometimes want to make episodes I know I will want to skip as already downloaded. Since Reader has these already read, I can't set these as already downloaded without either ignoring google's read flag or manually downloading and deleting the episode.

I do my feed management at work, where I don't have the internet access to manually download. Do I just need to ignore Reader's flag?

sdp0et
05-12-2013, 09:54 AM
Stefan,

I really am not sure why I am having so much trouble after using BP for so long without any problems.
This may need a separate thread because I am not sure if it is sync related.

I had updated to the .23 beta before doing your experiment. When it failed, I wiped BP from the phone again, go the tablet's state where I wanted it. I hit every feed, set all of them with any download history to retrieve only X episodes, where X was would include the currently downlaoded episode plus about 8-10 episodes already downloaded as a buffer. The feeds I had not yet started, or was very close to the beginning I left alone. I did a backup and restored on the phone.

On the phone, I went through each feed, and based on what would require the fewest number of long presses, marked all episodes in each feed as downloaded or not, then manually toggled the few at the beginning or end to get the devices in sync. As before, there were scattered episodes that had to be toggled as well, but eventallu I got the phone to be the same as the tablet. I then told the phone to update all feeds.

It worked fine for most feeds, but for some it just marked the epiodes that should have been downloaded as downloaded but did not actually retrieve the files. It did this for the number of episodes it was set to download for that feed. using "update" again just marked the next group of episodes without actually downloading the files. because this was on the phone, I was able to manually set them all as not downloaded and try again with the same results. I am able to manually download individual episodes just fine. The update log just says that there was nothing to download in those feeds. I can't see anything in the other logs.

The larger issue is that the same feeds did the same thing on the tablet overnight. I don't notice any feeds that did this one one device and not the other. The problem is that on the tablet, I can't manually set epsidoes to "not downloaded", so have to manually download the episodes.

The last month and a half has been pretty frustrating, as BP has been great for years. I have no idea how much of this might be growing pains, and how much is me, but I usually get along better with technology.

StefanK
05-14-2013, 05:46 PM
I looked over the code once again and the only thing that I can think of is that what you see is actually related to Google Reader. There is a logic that was left from some time ago (and I have forgotten) that will mark episodes as downloaded if the feed is synchronized with Google reader and the item was marked as "Read" in Reader. This logic was used at some point to do a "poor-man" synchronization - if the episode was played and marked as read, then other device would just mark it as "downloaded" and won't download it again. If this is the case, then all new episodes should work correctly.

sdp0et
05-14-2013, 05:54 PM
I looked over the code once again and the only thing that I can think of is that what you see is actually related to Google Reader. There is a logic that was left from some time ago (and I have forgotten) that will mark episodes as downloaded if the feed is synchronized with Google reader and the item was marked as "Read" in Reader. This logic was used at some point to do a "poor-man" synchronization - if the episode was played and marked as read, then other device would just mark it as "downloaded" and won't download it again. If this is the case, then all new episodes should work correctly.

That is sort of how it worked for years. But it doesn't (didn't) check if it's currently marked as read, otherwise I'd never have been able to download anything over 30 days old. Nearly all my feeds are synched through google and this is only happening on a subset. A week ago, these episodes (some a year or more old and marked read by google) were still downloading. The only obvious (to me) thing that has changed was beta 22-> 23, since it started the right after that update and manually mass toggling feeds.

thanks for looking into in. I'll keep experimenting.

StefanK
05-15-2013, 10:15 AM
I can't think of anything that has changed between 22 to 23 to affect this (but with software everything is possible). As far as marking "read" as downloaded I was talking in my previous post - this affects only feeds posts that are marked as "read" by the user (not because they are >30 days old). When Google marks a post as "read" after 30 days, it uses a special flag to indicate that and BeyondPod has logic to exclude those from "marking as downloaded".

With Google reader going away at the end of next month this all interaction will become irrelevant (at least until we find a good replacement).

Stefan

sdp0et
05-15-2013, 10:55 AM
Yeah, in theory that shouldn't change the flags on episodes that BP already know about, right?

StefanK
05-16-2013, 08:14 AM
It will change it to "Downloaded" (but not back to not-downloaded). The general logic is: (assuming a feed is set to download the last 3 episodes) Once the feed is updated, BP checks to see if any of the last 3 episodes is already downloaded, exist as "stream-able" or is in the download history (it was downloaded in the past and deleted). Any of the 3 episodes that passes the checks above is queued for download. If the feed is not synced with Reader, those episodes are downloaded. If the feed is synced, BP does one additional check to see if the Reader "read" flag for the feed is set to "read" and just marks the episode as "downloaded" and skips the download. It then downloads whatever is left for download.

With the logic above episodes will NOT be automatically downloaded only if any of the following conditions is true:

1. Episode is "below" the number of episodes to download. If the feed is set to download the last 3 episodes, episodes after (older than) the 3rd will not be downloaded regardless if they were ever downloaded before.
2. Episode already exists (as downloaded or stream-able)
3. Episode is in the download history.
4. Feed is set to sync with Reader and the reader item is marked as "read" (this applies only to items that are manually marked as "read" by the user, not by Reader itself).

Stefan