Tvheadend

Probably the easiest way to do what you want is to Config->Recording->Profile and clone the default in to new profiles such as "movie" and "shows", and update the path spec there. Then on your recording rules just manually select the appropriate profile. There's no mechanism to change profile automatically based on the programme type.

So, if recording "Tom Cruise Movie", you select your movie profile, if recording "Simpsons" then select shows profile.

The reason movies are all placed in one directory is because when browsing a directory on Kodi it would just show the directory name with no art/description. So, if you had ten movies, you had to go in to each one individually to see the description, which is tedious.

If scraping (in Kodi) you can just untick the option "files are in separate directories" and it will scrape the movies fine even if they are all in just one directory since artwork is stored internally on Kodi (not on the filesystem), and it will scrape them to your library.

Thanks.

Unfortunately manually selecting profiles only works with the web front end; Kodi and Emby only support one.

I was hoping to put everything in my existing movies/tv show directories, which do have files in separate subdirectories. From what you describe I'd need to have a separate set of folders for recorded shows, and scrape them that way. If that is the only option I'll see if I can make it work but was hoping there was a simpler solution.

I hadn't considered that Kodi/Emby only supports one profile. You might be able to request a change?

You can have multiple (movie) sources in Kodi, so you could have one directory of movies and a separate directory of tvheadend recorded movies, and both will scrape to the same library so you won't notice on the frontend that they are separate. Personally, I wouldn't want tvheadend and non-tvheadend movies in the same hierarchy in case tvheadend accidentally deleted my non-recorded media. (Even though I know it's unlikely).

The way I do it is to add the tvheadend under Kodi video/files as a "pvr source"; then you browse that hierarchy and alter the scraper for "tvmovies" directory to be universal scraper. That way your "watched" status is also synched back to tvheadend and is also in sync with the LiveTV section of Kodi. So, if tvheadend (beta) is setup to delete videos after watching then it all "just works". (The alternative is to browse the directory directly on the disk, but then watching videos is separate to tvheadend and not in sync).

That's probably what I'll do; it's more important that TV shows have subdirectories than movies and I agree keeping them separate isn't much of an issue since Kodi, Emby, and (I assume) Plex can all present from multiple sources anyway and I won't mix the two up. Was just confused as to why $q creates a subdirectory for the tv show inside the specified folder but not for movies, i.e.

$q.$x produces \tv\How I Met Your Mother\How I Met Your Mother - S07E13 - s07e13 Tailgate.ts for shows - (no idea why "SO7E13" appears twice in the file title but it does that for all series)

but $q.$x produces

\movies\Dumb & Dumber (1994).ts for movies.

These days it's more common to have sub-directories for movies (i.e. \movies\Dumb & Dumber (1994)\Dumb & Dumber (1994).ts

and sub-directories by season for tv series (i.e. \tv\How I Met Your Mother\Season 07\How I Met Your Mother - S07E13 - Tailgate.ts) for shows

However I can probably make how it works appear normally in my media center (Emby in my case).

I would guess "s07e13 Tailgate" is probably the sub-title your EPG has for the show; whereas my EPG would just be "Tailgate".

The reason tvshows creates sub-directories is because it is mandatory hierarchy for Kodi scraping (it can't handle all in one directory), whereas movies allowed either sub-directories or all in one directory. I agree sub-directories are more common for movies (and that's how I originally implemented it), but it was tedious to use in practice compared to no sub-directories due to Kodi not showing movie details unless you entered each sub-directory in turn.

Storing tvshow episodes without season sub-directory is the recommended way (according to the Kodi wiki), even though most third-party renamers don't do that. The one advantage of having episodes in one directory (for tvheadend) is that you are unlikely to have many episodes recorded, and they are likely to all be the same season, so it just avoids some extra clicks to get to the files if browsing via LiveTV.

Fair enough.

I don't scrape with Kodi, though, I use Emby. Which will handle the way it works now, at least in my limited testing, but technically recommends sub folders for movies/season directories for shows (a number of newer third party scrapers, like for example the one Sonarr/Radarr uses, look for this as well). It would be cool to add as an option (another $ variable, for example) the ability to add sub-directories for movies&seasons for shows, because that way you could integrate directly in to the same directory structure if you were using it elsewhere. Then users could choose whichever fit best.

I'm ok with keeping the folders separate because Emby will allow me to add the folder to my "TV Show" category and should scrape it correctly, so in the clients it should all show up consolidated, but as previously mentioned there may be use cases where that is undesirable for one reason or another.

I have been thinking about it (ever since you originally mentioned the problem). We already have a (rather ugly) $1Q and $2Q variant to force the recording as movie or tvshow. So, it's possible to add variants for using additional subdirectories, but the question is how to make it not even more confusing/ugly, though I'm guessing it will end up being just a "$3Q" and hide our heads in shame...

I'm slightly against adding a new top-level tag "$Z" (or whatever) just because I don't want to use up all the remaining letters for someone else's new features.

So $3q would be "tvmovies/Title (YYYY)/Title (YYYY).ext" and "tvshows/Title/Season XX/Title - SXXEYY - Subtitle.ext".

But, what if the show doesn't have a season? Or no season and no episode? (Currently we just ignore that bit in the filename IIRC). My OTA also has some that have a season but no episode.

I've no time to do it this weekend, but if we can think of a good think for no season, episode, or season&episode then I'll try next week.

What's the fallback currently if no episode is detected?

How about, if you are using $3Q (or whatever it ends up being) and no season is detected it just reverts to the default $Q behavior? I haven't gone through that part of the code but would that mess with the current logic?

That way, worst case the user just gets what they already have with the current modifiers. From a fallback perspective that seems elegant enough, and consistent behavior.

Currently we add season (if available) then episode (if available) then subtitle (if available). So it would be "Title - SXX - Subtitle" or "Title - EYY - Subtitle", etc.

But, we have some EPG where (for example) Christmas Special of a programme doesn't have season even though the regular episodes do. So, you'd have "tvshows/Title/Season 12/Title - S12E03 - Subtitle" but then "tvshows/Title/Title - Christmas Special 2018", so you'd have a bit of a mixed-hierarchy with some programmes in subdirectories and some in the "root" directory.

I don't know Emby well enough to know what it's preferred layout is for these scenarios.

Emby can handle both, as can Plex; they will put shows without a season identifier in to a "specials" category if they can't otherwise place it - their scrapers are fairly advanced, so if for example a season id is missing but the title is included they can usually do a regex match from it for the correct season. Also, these days they (and other newer scrapers) can also use file hashes, though of course that won't do anything for DVR recordings of your own stuff.

At the end of the day GIGO applies - if the EPG doesn't supply the needed information users can't reasonably expect the titles to be matched without manual intervention, that of course is true whether this change in use or not. In that case the existing fallback behavior should work fine. If it results in some directories with season subs and some without, that's not on tvh in my mind, and the user will still be able to access their recordings easily (especially considering Emby, Plex and Kodi can highlight new episodes on their own regardless of how they are scraped).