Random bits of other podcasts cut into the intended one that should be playing

[otherrealm]

When I am playing a podcast, random bits of other podcasts cut into the intended one that should be playing. I am pretty sure it is a mixup in the download cue? The thing is I have it set for one parallel download at a time .

[keunes]

That’s really odd indeed. Have you checked if the media file that was downloaded contains the audio of different episodes, or if playback jumps between episode file A and episode file B?

You can check the media file by sharing > media file, if the episode is downloaded. And then open it in your browser, or sending the file via email.

[otherrealm]

It only happens every once and a while for random downloads and I haven’t gotten a chance to make a note of the ones it happened to, but I will try to make note when it happens in the future. I am pretty sure it is the in the actual file, but it could be something to do with the cache. I cleared this and will see if it continues. It has been going on for quite a while, I just haven’t gotten around to reporting it until now.

[Psych0somatic]

I’ve found this happens when two different podcast feeds have the same title. For example, both “Unresolved” podcasts merge episodes despite completely different RSS feeds. This used to be an intermittent bug, it went away after an update, but now it’s back and persistent.

The issue seems to sorting based on podcast title, but not checking whether or not feed addresses or IDs are the same as well.

There are approx 8 podcasts in my subs right now where this is extremely problematic. Sometimes I’ve had to mark up to 200 episodes as “played” so I don’t accidentally play from a different feed or podcast.

I really hope you guys can fix this in the next update.

[keunes]

Hi @Psych0somatic

Thanks for chipping in with your experience. Before it can be fixed, we need to know exactly what’s happening. Are files mixed at playback? Are pieces of audio mixed when downloading episodes? Is it because of the way AntennaPod names files, or is this an issue in Android’s download system (which AntennaPod leverages)?

To help us replicate the problem, could you please share the feeds with which you are experiencing this? And can you let us know your Android and AntennaPod versions?

Also, can you report on this question?

@keunes

Have you checked if the media file that was downloaded contains the audio of different episodes …?

You can check the media file by sharing > media file, if the episode is downloaded. And then open it in your browser, or sending the file via email.

[ByteHamster]

Looking at the code, if there are two feeds with the same name, containing episodes with the same name, the files conflict and might get broken on download. An easy solution would be to append the episode ID after the file name. That might make some people (who use AntennaPod as a downloader and play the episodes in some other app) unhappy, but I guess that’s not our main target group anyway.

Should be fixed in Fix downloads when feeds with same name have items with the same name by ByteHamster · Pull Request #6265 · AntennaPod/AntennaPod · GitHub

[Psych0somatic]

Android version: 10.3.3, OnePlus 6T
AntennaPod app version: 2.7.1 (F-Droid)

Key:
Since discussion of bug is a bit confusing by nature, I’m going to refer to the original feed where said episode(s) belong as the primary feed, and the outside feed where said episode(s) populate but don’t belong as the secondary feed. When needed, I’ll also refer to episodes that don’t belong in said feed as rogue episodes.

@keunes

Are files mixed at playback? Are pieces of audio mixed when downloading episodes? Is it because of the way AntennaPod names files, or is this an issue in Android’s download system (which AntennaPod leverages)?

Rogue episodes play normal in playback all the way thru, without any audio mixing. Episodes played outside their primary feed (i.e. in secondary feed) don’t count towards playtime stats. Episodes in secondary feed don’t sync with primary feed, meaning play progress, queue status, and favoriting on the exact same episode are completely separate for rogue episode & original episode. I’ve included episode links for an example rogue episode from both feeds, Episode 4: The Hope (Un(re)solved episode), that shows as a favorite in secondary feed (feed 2), but not in primary feed (feed 1) (see: screenshot attached).

Issue seems to AntennaPod’s sorting of podcasts with same name. Deleting one of the Podcasts used to at least remove rogue episodes from remaining podcast feed — but for at least past 2 updates, rogue episodes remain despite deletion, but no longer play. Can’t decipher for sure whether it’s AntennaPod or Android, but mp3 download ID3 tags contain correct podcast & cover art in file manager.

Example is of two podcasts with same name, but one title contains symbols that should differentiate it: Unresolved vs. Un(re)solved. Across the board, bug happens to podcasts with same title, however, rogue episodes only appear in ONE of the two feeds (see: screenshot below).

Note: rogue episodes always appear in secondary feed in chronological order. Again, only one out of the two feeds with same name, displays episodes from the other, while the other appears normal.

Feed Links:

1. Unresolved (by Unresolved Productions): Unresolved
   • https://www.spreaker.com/show/3266604/episodes/feed
2. Un(re)solved (by FRONTLINE PBS): Un(re)solved
   • https://feeds.wgbh.org/381/feed-rss.xml

Episode Links:

1. Episode 4: The Hope | Un(re)solved episode
   1a. Un(re)solved Feed:

   • https://dts.podtrac.com/redirect.mp3/dovetail.prxu.org/_/381/1a7fadb8-26aa-4b22-b564-9c728572193e/Un_re_solved_Episode_4_FINAL_Billboard.mp3

   1b. Unresolved Feed:

   • https://dts.podtrac.com/redirect.mp3/dovetail.prxu.org/381/1a7fadb8-26aa-4b22-b564-9c728572193e/Un_re_solved_Episode_4_FINAL_Billboard.mp3

2. The University of Idaho Murders (Update) | Unresolved episode

   • https://dts.podtrac.com/redirect.mp3/chrt.fm/track/84999D/api.spreaker.com/download/episode/52319657/the_university_of_idaho_murders_update.mp3

Un(re)solved podcast (all episodes). Note there are no rogue episodes on this feed (bug is always one-sided):

Unresolved podcast (collage to show rogue episodes near bottom of chronological feed + Episode 4: The Hope = favorite):

Un(re)solved podcast feed, Episode 4: The Hope ≠ favorite):

Unresolved podcast feed with rogue episodes in red. (Note: Real podcast episodes are not numbered — only eps from Un(re)solved feed are):

Unresolved podcast feed with episode link #2, (2nd from top in feed, marked as played). Note how no episodes are numbered, unlike rogue episodes:

[Psych0somatic]

In my detailed reply, you will see that episode names are not the same, and further, the podcast titles I used in this example actually have enough of a difference to differentiate them: Unresolved vs. Un(re)solved.

However, issue happens to all podcasts with same name, but “rogue episodes” (as I call them for the sake of clarity) only appear in one of the two feeds — while the other feed remains normal. Rogue episodes display chronologically when mixed-in outside feed.

This is bug was repaired for a quite a while, and only showed intermittently in older app versions over the past year — but current iteration of bug is now incredibly persistent & much more aggressive (rogue episodes remain in feed even after deleting source podcast — they just become unplayable) and has carried over for at least the last two app versions. I also demonstrated how rogue episodes behave differently on primary feed vs. “secondary” [bug] feed.

[keunes]

Hi @Psych0somatic

@Psych0somatic

I’m going to refer to the original feed where said episode(s) belong as the primary feed, and the outside feed where said episode(s) populate but don’t belong as the secondary feed. When needed, I’ll also refer to episodes that don’t belong in said feed as rogue episodes.

From this description I understand that certain episodes show up in the list of a different podcast (the ‘rogue episodes’). Is that correct?

This thread/bug report is about bits of audio from one episode behing heard in another episode, and is not related to the episodes listed for a given podcast.

So I think we should move your report to its own thread so it can be looked into separately, but I wanted to wait to hear from you if I understood correctly.