[GH-ISSUE #33] Podcast Downloads Error on Notification #26

New issue

Closed

opened 2026-02-27 04:57:10 +03:00 by kerem · 4 comments

kerem commented

2026-02-27 04:57:10 +03:00

Owner

Originally created by @StephanX on GitHub (Jul 25, 2025).
Original GitHub issue: https://github.com/Googolplexed0/zotify/issues/33

Originally assigned to: @Googolplexed0 on GitHub.

Originally created by @StephanX on GitHub (Jul 25, 2025). Original GitHub issue: https://github.com/Googolplexed0/zotify/issues/33 Originally assigned to: @Googolplexed0 on GitHub. .

kerem closed this issue

2026-02-27 04:57:10 +03:00

kerem commented

2026-02-27 04:57:11 +03:00

Author

Owner

@Googolplexed0 commented on GitHub (Jul 25, 2025):

Instead of re-referencing the config, why not simply use the existing constructed filepath that actually wrote the file?

Good catch with the bug. We do actually use the constructed filepath, the .relative_to() just replaces all the path above the ROOT_PODCAST_PATH with "./" to reduce the length of the print statement.

@Googolplexed0 commented on GitHub (Jul 25, 2025): > Instead of re-referencing the config, why not simply use the existing constructed filepath that actually wrote the file? Good catch with the bug. We do actually use the constructed filepath, the .relative_to() just replaces all the path above the ROOT_PODCAST_PATH with `"./"` to reduce the length of the print statement.

kerem commented

2026-02-27 04:57:11 +03:00

Author

Owner

@Ragnaran commented on GitHub (Jul 28, 2025):

The bug has regressed. Looking more into it, there's also a filename extension mismatch; the initial filepath declaration doesn't consider the file format choice, and hard codes ogg for the container format then checks for an mp3 extension, and finally reverts to the previous filepath declaration bug that surfaced the other day. I've submitted a PR here that addresses these issues: https://github.com/Googolplexed0/zotify/pull/37

(Apologies for all the whitespace deletions, I'm loathe to toggle whitespace elimination on VSCode. Makes the file nicer to read anyway :) )

@Ragnaran commented on GitHub (Jul 28, 2025): The bug has regressed. Looking more into it, there's also a filename extension mismatch; the initial filepath declaration doesn't consider the file format choice, and _hard codes_ ogg for the container format then checks for an _mp3_ extension, and finally reverts to the previous filepath declaration bug that surfaced the other day. I've submitted a PR here that addresses these issues: https://github.com/Googolplexed0/zotify/pull/37 (Apologies for all the whitespace deletions, I'm loathe to toggle whitespace elimination on VSCode. Makes the file nicer to read anyway :) )

kerem commented

2026-02-27 04:57:11 +03:00

Author

Owner

@Googolplexed0 commented on GitHub (Jul 28, 2025):

Not sure how the bug could regress, all podcast paths are created as subpaths of ROOT_PODCAST_PATH. I see the issue with the file extensions, but AFAIK the current implementation of podcast downloading doesn't use FFMPEG to convert the file format at all. I can add that as a feature, though. I've barely touched the podcast code from the original repo since I don't really use the functionality.

@Googolplexed0 commented on GitHub (Jul 28, 2025): Not sure how the bug could regress, all podcast paths are created as subpaths of ROOT_PODCAST_PATH. I see the issue with the file extensions, but AFAIK the current implementation of podcast downloading doesn't use FFMPEG to convert the file format at all. I can add that as a feature, though. I've barely touched the podcast code from the original repo since I don't really use the functionality.

kerem commented

2026-02-27 04:57:11 +03:00

Author

Owner

@Ragnaran commented on GitHub (Jul 28, 2025):

It definitely looks like podcasts are downloaded without conversion. I was a little surprised to see the tracks being downloaded using their own bespoke functions instead of somehow shipping them to the common download_track() function, but that seems like more of a refactor than I wanted to take on today.

I also get a bit obsessive about using local variables (DRY); it irks me to pull the same config data request in multiple places, but that's more of a personal quirk than a technical requirement. In any case, the hard coded extensions would only make sense if they were identical!

(and, yes, I'm the one who opened this initial ticket, I simply prefer to keep, erm, anonymous when supporting this tool.)

@Ragnaran commented on GitHub (Jul 28, 2025): It definitely looks like podcasts are downloaded without conversion. I was a little surprised to see the tracks being downloaded using their own bespoke functions instead of somehow shipping them to the common `download_track()` function, but that seems like more of a refactor than I wanted to take on today. I also get a bit obsessive about using local variables (DRY); it irks me to pull the same config data request in multiple places, but that's more of a personal quirk than a technical requirement. In any case, the hard coded extensions would only make sense if they were identical! (and, yes, I'm the one who opened this initial ticket, I simply prefer to keep, erm, anonymous when supporting this tool.)