[stuartk]

Ok... time for me to get really needy and annoying. Feel free to tell me to quit bugging you if I am asking too much.

I have damn near filled my 5TB hard drive with recordings (made oh so easy by this project!) and now I am going to need to get some transcoding action underway or I am going to have to start deleting things. I am playing with handbrake and it seems to do a better job of compressing my recordings than mythtranscode. My question is how to go about using handbrake to shrink my recordings and not screw up the simlinks and mythtv database you have preserved with your project.

To your exact request, the short answer is that this is not something I ever figured out for myself, but then as I only watch recordings via Kodi I went a slightly different way.

Currently I use handbrake, because, as you say, it does a better job than mythtranscode, and also I was already familiar with Handbrake before I started using MythTV.
The approach I take is that, for recordings I know have been correctly comflagged and moved, I first "disconnect" the recording from MythTV, then I run Handbrake and, once I've checked I'm happy with the transcoded version, I manually remove (rm) the pre-transcoding recording file. This is actually the reason I added the --disconnect flag in the first place. As long as you set the Framerate to same-as-source in Handbrake the comflagging should still be aligned with the transcoded recording. But this approach does not work if you really want to keep the recording connected to MythTV, for example, if you want to also be able to use the MythTV-frontend to view recordings.


If you decide you are ok disconnecting recordings from MythTV and are considering following the approach that I do, then if possible you should ideally wait until the next release of myth2kodi.
The reason being that I am currently in the process of refining the --disconnect and the deletion of MythTV-DB entries in general. The current minor issue that I am resolving is that the --disconnect flag currently does a hard delete of the MythTV-DB entry, this is because it uses the direct MySQL delete method. What this means is that, after disconnect, MythTV has no knowledge that the recording ever existed. Which has the minor inconvenience that MythTV now lacks the knowledge necessary to prevent rerecording the same episode again. This is not a major issue for me because my guide data is so bad I already get a lot of duplicate recordings. But your guide data seems quite good and so you will be weakening MythTV's duplicate recording protection. What I am in the process of doing is making sure that, if DATABASE_ACCESS is set as PythonBindings (which is the default/preferred setting) then the Python-bindings delete method is used for disconnect as well. The Python-bindings delete is the same as deleting via mythweb or the MythTV-frontend in that it doesn't actually completely delete the MythTV-DB entry but rather moves the entry to an "oldrecorded" table, so MythTV views it as deleted but also remembers that in the past it recorded that episode and so should not record it again in the future.


EDIT: Disregard the previous paragraph, turns out I'd misunderstood a detail in how the MythTV-DB is set-up. Luckily it was a good sort of misunderstanding as it just led me to be overly conservative. Even the MySQL-based database-entry deletion, used for --disconnect in the current release of myth2kodi (v1.3.1), does not damage MythTV's ability to remember all old recordings and use that info to prevent duplicates. So it can be used without the caveat of the previous paragraph. That being said, I've already made the changes that mean all MythTV-DB accesses will respect the DATABASE_ACCESS setting, and I'm currently at the point of testing before making the next release -- which will include these changes as well as quite a few other minor fixes and improvements and should be available in the next few days.