Transcoding and the Channels DVR database

I run a script that transcodes new shows every night that I developed for Plex DVR and EyeTV. It works well, doesn’t slow down my server, and gives me great archival quality mp4/m4v h.264 files (using HandBrakeCLI) that stream well across the internet. Given that Plex seems to be compatible with the Channels DVR file structure, I was thinking it would be useful to just keep the new recordings in the same structure. However, I’m uncertain as to how that might affect the database, especially if the show is deleted. I tried it out on a show I was going to delete, placed an identically-named show in the same folder albeit with a different suffix (mp4), and then deleted the show from within the Channels DVR interface to see what would happen. To my surprise, nothing did, i.e. it was removed from the Apple TV interface, but nothing was removed from the file structure. In short, I don’t know how Channels DVR handles deletion of files and whether using the Channels DVR file structure for transcoded data is even viable.

  1. Is there any way to replace the recorded show with an Apple TV compatible mp4/m4v file with the same name (different suffix) and still be able to view it in Channels DVR? If so, would that also preserve the very effective commercial skipping data?

  2. Could you explain why, when I delete a show, it doesn’t remove files from the drive? Is it perhaps queued? How is deletion implemented server-side?

  3. Do you have plans in the near-future to integrate transcoding? I notice the .ffsplit files, which will prove useful if your comskip method is as successful as it has been so far. If so, do you already have guidelines as to how to manage the transcoded copy?

Thanks.

  1. The DVR and clients only work with mpegts formats, so a mkv or m4v will not work.

  2. Deletes are queued and should happen shortly after requested.

  3. We certainly have the pieces necessary to transcode, but we haven’t thought much about it yet. It could be an optional feature, but it’s also easy to set up with third party tools. Seems like a number of users have mcebuddy setup to transcode and export into an existing plex library.

Is the main use case for you reducing the storage space taken up by recordings?

Thanks for the reply.

In response to your question:

To some extent it’s about storage space. It’s actually more about remote streaming access. It’s best to have streamed files in h.264 format to avoid heavy transcoding, and also overnight encoding can produce very efficient (small) files with no visual loss of quality, reducing bandwidth and impacting data allowances (broadband or cellular) less. For instance, the following command produces a file that is often 10x smaller than a recorded 720p .mpg file and about 2x smaller than an on-the-fly transcoded stream from Plex:

HandBrakeCLI -i input.mpg -o output.m4v --preset=“AppleTV 3” --encoder-preset=“veryfast”

This is particularly important if your uplink broadband connection is small, or over cellular data.

Finally, for archiving long-term in Plex it’s convenient for me to include chapter markers within a file of a different format (mp4 or mkv), and that at the very least requires changing the container format. (Note that having your .ts embedded within an .mkv file is an option in Plex DVR now, partly for that sort of convenience).

1 Like

The file wasn’t deleted because you renamed it with an ‘mp4’ extension. So when DVR tried to delete the file with an ‘mpg’ extension, it wasn’t there.

1 Like

I didn’t rename it. I added an extra file in the same directory. The .mpg is still there, along with the .mp4, a couple of hours later. But if it’s queued that may explain it.

1 Like

Oh, and I should add that other reasons to transcode over night, rather than on-the-fly, are that it doesn’t slow the system down when watching remotely, the processor requirements are less and the responsiveness of the remote client is improved.

I use MCEBuddy to strip out commercials for movie recordings, but no transcoding due to server/time intensive (for my purposes) & storage is cheap :grinning:. Apple concentric so I let the ATVs or iOS devices perform on the fly heavy lifting.

In the MCE routine, I replace the original Channels file with the newly created comm free mpeg version (and archive the original file on a different NAS). Channels plays the new files perfectly and Plex utilizes also.

The family watches series recordings and deletes, hence I don’t run those files through a commskip routine, just use Channels ff/skip.

You might be interested in Feature Request- File Name, as we are trying to create viable comm free series recordings which are Plex compliant…folder structure/requirements are a bit of a problem currently…would like to utilize MCE solely and not resort to cli, etc.

For me, it’s not so much about storage as streaming to outside of the house. I travel a lot.

I agree that the directory/file naming convention is not ideal. I think this is one area where copying the Plex DVR naming convention would make sense. Something like:

// - SxxExx - .

would be far easier to handle. SxxExx could be replaced by date if not available.

1 Like

Gotcha…

Hopefully, as indicated in the detail of ref thread above, Channels will play transcoded h.264/ac3 files (as if original).

you can stream away from home now through the web admin. The streams are automatically transcoded in real time when streamed. This means you can tune the quality down to go easier on mobile data.

Once iOS has DVR support this will also all work directly in the app.

The streaming is erratic for me, with pauses and stutters. I think my computer’s not quite powerful enough for it, although it has never had problems with Plex. In any case, I still prefer to transcode in advance, for reasons stated above.

Very cool. Attempted remote streaming thru web interface yesterday for the first time. I wasn’t too surprised when it didn’t work. One day later and there it is. I’ll try again. What fun.

If you’re remote you probably want to reduce the resolution on the Settings tab under Web Player