Mount your podcasts rss-feed to your filesystem.
This service acts as proxy between a http/xml podcast and your filesystem, so you don't have to download them. Developed for usage with Audiobooshelf because they still don't support subscribing to an online podcast and I didn't want 1000 Episodes of a podcast on my harddrive.
It will also inject ID3-Tags into the mp3-files other software can read correct metadata if the station didn't provide it.
Before you start: This only works on linux/wsl because it uses FUSE to mount the virtual filesystem.
Simply use the make file to build the project:
make
For mounting a single podcast use:
./build/podcastfs --feed <http://podcasturl> --mount </mount/podcastfs/podcast>
If you want to mount multiple podcasts you can use a podcastlist file like this:
./build/podcastfs --file ./build/podcastlist --mount </mount/podcastfs/podcast>
Inside the file you can provide one podcast per line and use a bar symbol | to seperate name and url like so:
Podcast 1|https://podcast1.com/rss
Podcast 2|http://podcast.secondpodcast.com
Updates to the podcast will by be done every hour to include new episodes of a podcast. If you need to change this behaviour take a look at the MaybeRefresh function.
To mount a FUSE file from the host to the inside of a docker container you need to add the rshared flag. This option allows the container to see mount events and properly handle FUSE mounts. You can read more about this flag here.
volumes:
- ./podcastfs:/podcasts:ro,rsharedIt is also recomended to add the read-only ro flag, because you can't write to the podcast streams.
pv ./path/to/file > /dev/null
If you have any ideas to increase the speed/decrese waiting time for http events let me know! It's not that slow but it's certainly much slower than my internet connection.
I also added support for injecting ID3 tags into virtual mp3 files to populate them with info from the rss feed. This can fix some issues when the Provider of the feed didn't tag the files propperly.
There are several ways to display ID3 tags:
This is probably the most user friendly, but does not display everything and if it's out of spec it might break:
eyeD3 <file>
A hexdump of the first few bytes of a file is much more useful in such cases:
xxd -l 300 <file> |
The ID3 interpretation of the hex representation:
00000000: 4944 3303 0000 0256 0711 5441 4c42 0000
: aaaa aabb bbcc dddd dddd
a: ID3 (4944 33) - It's the beginning of an ID3 tag
b: v2.3.0 (03 00) - Version
c: no flags (00) - Some flags might be provided
d: tag-length (0256 0711) - A syncsafe integer (4*7 bit usable of 4 bytes) telling you where the audio starts
The start of the actual audio-data can be found after the ID3-Tag. Each audio frame starts with to bytes of ones (so "ff"). If its right after you Tag or at the start of the file, that's your first frame. Sometimes (when there is an image embeded in the original metadata) it may look like a lot of noise so you can use the tag-length and search for "ff" in that region. You might also use some info of the image-format like looking for IEND wich marks the end of a PNG file.
For further info on ID3-Tags I can recommend you read the docs from Mutagen. They made a fantastic job at writing up some info on this "standard".
This is the end, but not a png file.
Inspired by krumberg/podcastfs