mythtv scripts (was Re: [mythtv-users] mythtranscode results in 15GB files)

[Shawn]

Guess I forgot my own safeguards... It doesn't delete any nuvs,
only .tmps, and only if the nuv's DB entry exists, and after killing the
mythtranscode.



On Mon, 2004-10-25 at 08:40 -0500, Shawn wrote:
> For every problem with myth I've had, I write a perl script which allows
> me to sidestep the issue. I'm just not successful getting backtraces
> much of the timefor whatever reason...
> 
> I've had crashes, partial recordings, and transcoder glitches which I've
> worked around. If you have need for any of these, let me know and I'll
> try and get them release ready.
> 
> Crashes
>         mythbackend is simply monitored by a script
>         that /etc/init.d/mythbacked restarts, if needed and the frontend
>         runs in a loop. I have another script I can call upon shutting
>         those things down without the monitor script restarting them.
> Partial, or lost recordings:
>         I have swatch monitor mythtv upon the mythbackend.log saying a
>         recording started checks to see the recording has an entry in
>         the DB and that the file is growing. I think sometimes mysqld
>         gets mucked and doesn't commit rows. I then kickstart the
>         recording by restarting mysql and myth. I really don't know what
>         happens next as I've never been watching when it happens. All I
>         know is that I no longer have this problem.
> Transcoder glitches
>         I wrote a perl script that checks the sanity of all nuv files
>         and recordings table entries by making sure the size of the .tmp
>         file isn't bigger than it's .nuv, checking that all nuvs have DB
>         entries and vice versa. Oh shit! It deletes recordings it
>         doesn't see in the DB... I have to comment that out in case
>         login fails! Glad I thought of that before it happened...