Tvheadend

I think instead a "fallback" DVR profile should match all cases (the fallback dvr profile can have a fallback profile, too, and so on...)

C K wrote:

I think instead a "fallback" DVR profile should match all cases (the fallback dvr profile can have a fallback profile, too, and so on...)

Yes this makes more sense. +1

C K wrote:

I think instead a "fallback" DVR profile should match all cases (the fallback dvr profile can have a fallback profile, too, and so on...)

How would that work? If the recording failed with an error it would re-attempt with another profile?

John Doe wrote:

C K wrote:

I think instead a "fallback" DVR profile should match all cases (the fallback dvr profile can have a fallback profile, too, and so on...)

How would that work? If the recording failed with an error it would re-attempt with another profile?

Right, in the other profile you can define another recording path / stream profile etc -- and a second fallback profile as well

Just read https://tvheadend.org/projects/tvheadend/wiki/Tvheadend_recording_management

Tvheadend will only use one location for storing recordings.

Don't know, if this sentence is up to date :-)

C K wrote:

Just read https://tvheadend.org/projects/tvheadend/wiki/Tvheadend_recording_management

Tvheadend will only use one location for storing recordings.

Don't know, if this sentence is up to date :-)

I checked out the suggestion of using a bind mount or a symlink, but I don't think that's quite the same. If the network mounted HDD would be unavailable with a bind mount the same problem would occur. Having TVH switch over to another profile or backup storage location doesn't seem possible this way.

If the network mounted HDD would be unavailable, tvh will be freezing in D state waiting for disk resource to become available until timeout if system still sees it mounted. This can take several time and you can miss the beginning of recording.