podgrab

podgrab copied to clipboard

Before creating a bug report please make sure you are using the latest docker image / code base.

Please complete the following information

• Installation Type: Docker
• Have you tried using the latest docker image / code base: yes

Describe the bug I don't see an option to set the base path for my podcast library nor any way to set the path for a podcast. The documentation doesn't touch on this, either. Just a vague reference to an /assets mount that doesn't work for me. I have an NFS mount in my Compose file that I mount on all containers at /media so I'm using the same paths everywhere. I can't mount a subdir of a Docker-controlled NFS mount without making a second mount as a subtree mount, and noooooo.

Expected behavior I expect to see a base path field in Settings like all other "grabber" style apps. I'd love to see a per-podcast path I can change from the default if needed.

I dunno if I quite understand your question. So you want to save your podcast somewhere other than media? Well that is easy, You set. your podcast library base path in docker-compose.yaml file.

...
    volumes:
      - /media/podgrab/config:/config
      - /mnt/NFSShare/podcasts:/assets

/config volume is where container data is stored (i.e Podgrab database). The /assets (volume??) is where downloaded podcasts are saved.

I expect to see a base path field in Settings like all other "grabber" style apps. I'd love to see a per-podcast path I can change from the default if needed.

Sorry, can you explain the use case for this?

In your example, the media is still stored inside the container at /assets. Every single container where I use my media share I'm able to mount it at /media inside the container and then choose within the application where the actual library that application is managing is located within the share. In this case, I would like to mount my NFS share at /media and then tell the application "your base directory is /media/Library/Podcasts" rather than having to mount my NFS share at /assets.

The reason is that I'm using Docker's NFS abilities, not an existing mount on the host OS. Thus, I have to create a new volume entry in my Docker configuration file for a new NFS subtree mount just for this app (and turn on subtree mounts on my NFS server in the first place).

An example volumes config from docker-compose.yaml:

volumes:
  media:
    driver_opts:
      type: "nfs"
      o: "addr=my-nas.lan"
      device: ":/srv/media"

  podcasts:
    driver_opts:
      type: "nfs"
      o: "addr=my-nas.lan"
      device: ":/srv/media/Library/Podcasts"

This is used in all of my images as:

    volumes:
      - type: volume
        source: media
        target: /media
        volume:
          nocopy: true

However, for this app I have to add another volume entry (which makes a second NFS mount, just for this application) and then attach it as:

    volumes:
      - type: volume
        source: podcasts
        target: /assets
        volume:
          nocopy: true

Basically, because there's no in-app configuration of the base directory for media, I have to do specialized handling outside of the app and create extra system-level complexity. Simply allowing me to set a base directory would resolve all of that and allow me to re-use the existing volume I've made and set the path to use inside it.

Further, allowing multiple base paths (to be chosen per-podcast) would let me go even further and create [base]/News and [base]/Tech or even [base]/OtherFamilyMember etc. Clearly, that's a bit more involved and a Nice To Have, so don't let that distract you but it might be worth considering that future if/as you implement the global base path in the first place (ie. that there could be multiples).

Sorry @ahknight. I have spent the last half hour to understand this. My lack of docker volumes made it worse.Could you please guide me in the right way so that I am maybe able to help you. or @akhilrex might give you a better answer.

In your example, the media is still stored inside the container at /assets. Every single container where I use my media share I'm able to mount it at /media inside the container and then choose within the application where the actual library that application is managing is located within the share. In this case, I would like to mount my NFS share at /media and then tell the application "your base directory is /media/Library/Podcasts" rather than having to mount my NFS share at /assets.

The reason is that I'm using Docker's NFS abilities, not an existing mount on the host OS. Thus, I have to create a new volume entry in my Docker configuration file for a new NFS subtree mount just for this app (and turn on subtree mounts on my NFS server in the first place).

An example volumes config from docker-compose.yaml:

volumes:
  media:
    driver_opts:
      type: "nfs"
      o: "addr=my-nas.lan"
      device: ":/srv/media"

  podcasts:
    driver_opts:
      type: "nfs"
      o: "addr=my-nas.lan"
      device: ":/srv/media/Library/Podcasts"

This is used in all of my images as:

    volumes:
      - type: volume
        source: media
        target: /media
        volume:
          nocopy: true

However, for this app I have to add another volume entry (which makes a second NFS mount, just for this application) and then attach it as:

    volumes:
      - type: volume
        source: podcasts
        target: /assets
        volume:
          nocopy: true

Basically, because there's no in-app configuration of the base directory for media, I have to do specialized handling outside of the app and create extra system-level complexity. Simply allowing me to set a base directory would resolve all of that and allow me to re-use the existing volume I've made and set the path to use inside it.

Further, allowing multiple base paths (to be chosen per-podcast) would let me go even further and create [base]/News and [base]/Tech or even [base]/OtherFamilyMember etc. Clearly, that's a bit more involved and a Nice To Have, so don't let that distract you but it might be worth considering that future if/as you implement the global base path in the first place (ie. that there could be multiples).

Can you give me an example of some application that handles storage this way?

This seems like a docker anti-pattern to me since the application then has to decide where in the container it needs to save data. Most of the *arr containers work this way only.

• Sonarr
• Radarr
• Lidarr
• Readarr
• Mylar
• Headphones
• Lazy Librarian
• etc.

They all let you set a library base path and then calculate paths for whatever they manage based on that.