Autorec directory using format/escape codes?

flort

I don't see this in the doco.

In Edit Autorec -> Directory, can we use the usual format/escape codes as per "Format string/Pathname specification"?

davep

flort I've taken a quick look at the code, but it's not at all clear whether formatting applies to the Autorec Directory override. Can I suggest that you try it and see? Post the results back here so the docs can be updated (or better still submit a PR yourself).

flort

davep Thanks for your answer. I've just spun up a test recording, and whilst it hasn't finished yet, it seems to have been completely ignored. This is the snippet of autorec config I did:

flort

I've also just dug through the code a bit too... my C/C++ is very rusty, but it would seem that dae_directory is really only referenced with respect to HTSP.

For fun, I asked Copilot to give me it's thoughts:

There is no evidence from the semantic code search that the field dae_directory (set by the "directory" property in autorec rules) is actually referenced anywhere in Tvheadend's codebase when generating the storage path for recordings.

What the code does:

The field is present in the dvr_autorec_entry_t struct.
It is defined as a property in the autorec class (so it can be set in the UI and config).
It is managed correctly for loading, saving, and freeing memory.

What is missing:

Nowhere in the code (including the path generation logic for DVR entries) is there a reference to checking if the dae_directory field is set and using it to override the subdirectory for recordings.

Conclusion:
This suggests that, as of the referenced commit, the "directory" property for autorec rules is not actually functional—the field is exposed but not honored by the code that generates where recordings are stored. This matches your observation that the feature "doesn't seem to work."

flort

Alrighty, so here's the somewhat confusing results.

Yep, the escape/formatting codes don't work
It appears to have double recorded

So with the above config, this is what I ended up with (don't "judge" me on Judy, it was just the next thing up 😆 )

Judge Judy
└── Season 18
    └── Judge Judy - S18E150.mkv
zzz
└── $t$n.mkv
    └── Judge Judy - S18E150.mkv

Not sure, but the double recording was perhaps because I created the autorec as the episode was about to start or had already started.

My motivation here was to fudge a series I'm recording, because the metadata for it (the series name) is slightly wrong. Turns out there is no escape/format code for just the season number anyway, so it won't work.

Still, would be good if this worked.

davep

flort I've created a PR to get the online help changed.

Instead of specifying the directory in the Autorec, you could create a new DVR Profile for this series with your changed directory structure.

DeltaMikeCharlie

I have been working on a change to the DVR Profile format string that will allow individual Season and Episode numbers to be included in the file name.

The new formatting strings are '$A' for season and '$B' for episode (both upper case).

These can also be modified with a numeral to specify if zero padding is desirable. For example, if the season is '7', then '$A' will provide '7', whereas '$3A' will provide '007'.

If the EPG source contains the relevant fields, the following format string: '$t/Season $2A/$2B-$u$n.$x' would produce a file name like 'MASH/Season 03/18-House Arrest.ts'.

Currently, if no Season or Episode is provided in the EPG, then 0 will be used in the file name 'MASH/Season 00/00-House Arrest.ts'. Although I could change this to 'Unknown' or '' or something more meaningful if desired.

Thoughts and comments welcome.

flort My motivation here was to fudge a series I'm recording, because the metadata for it (the series name) is slightly wrong. Turns out there is no escape/format code for just the season number anyway, so it won't work.

@flort - In your specific instance, you would still need to hard-code the directory (MASH) from the AutoRec to compensate for the EPG having an incorrect title, but you could then use 'Season $2A/$2B-$u$n.$x' to produce 'Season 03/18-House Arrest.ts'.

flort

davep I've created a PR to get the online help changed.

Thanks. I was wondering if a dev (apologies if you're one and I haven't realised!) would chime in and actually confirm before doing that.

Instead of specifying the directory in the Autorec, you could create a new DVR Profile for this series with your changed directory structure.

How would I do that though? My issue is that my EPG is supplying and name, say "Alone", when it is in fact "Alone UK". So I would like the great formatting of $3Q$n.$x, but I need the series name hard-coded, but still do a subdir of "Season X"/"The file"

That was my point about no escape/format for season number.

DeltaMikeCharlie

flort I would like the great formatting of $3Q$n.$x, but I need the series name hard-coded, but still do a subdir of "Season X"/"The file"

One way of achieving your desired outcome would be to use a 'post-processing command' combined with a DVR Profile.

This would take the form of a shell script or maybe a Python script. That script would be passed the file name and whatever other details you like. Then, you can move/rename the recording file as you wish.

Once the file has been renamed/moved, you would then need to tell TVH the new location of the file via the API call dvr/entry/filemoved.

https://docs.tvheadend.org/documentation/development/json-api/api-description/dvr#dvr-entry-filemoved

DeltaMikeCharlie

Attached is a crude, proof-of-concept, Python script that can be used as the basis for a post-processing command script. It takes a number of parameters from TVH and then moves the recording file into the desired directory based on the Season number.

rename-recording.zip

1kB

There is also very little error checking, it is just a sketch of how this operation could be performed.

On the first few lines of the script, there are directions on what to do in your DVR Configuration to pass the required parameters.

During testing, I discovered that text data could be returned to TVH. Although there may be security implications that need to be considered, it should be possible to modify TVH so that the returned text contains information about what the script has just done so that TVH can take some action, like updating the new file location, for example.