On May 5, 2012 1:19 PM, "Michael T. Dean" <firstname.lastname@example.org> wrote: >
> On 05/05/2012 12:58 PM, Jeremy Jones wrote:
>> On May 5, 2012 11:39 AM, "Brent Bolin" wrote:
>>> On Sat, May 5, 2012 at 10:06 AM, Michael T. Dean wrote:
>>>> On 05/05/2012 10:40 AM, Brent Bolin wrote:
>>>>> Or has that been replaced/included
>>>> http://www.mythtv.org/wiki/Find_orphans.py says it's compatible with
>>>>> I find myself running this at least once a week to clean up orphaned
>>>>> snapshots and occasional mpg files.
>>>> However, if you actually need to run it frequently (where once a week
is >>>> extremely frequently), there's a serious problem with your system. It
>>>> should only be required when you have a hard drive failure (or if
>>>> someone is
>>>> deleting files outside of MythTV, in which case, you should fix the
>>>> behavior, not the symptom).
>>> What should the permissions be on /var/lib/mythtv dirs
>>> ubuntu 10.04 .24 fixes
>> Like you I am running .24 in Ubuntu which I installed as mythbuntu and
it >> (I think) includes JAMU. I have a lot of my recordings set to transcode
>> and hence those recordings get a new extension.
> FWIW, mythtranscode will delete the previews from the original recording
if a) you applied a cutlist or b) if you did a non-lossless transcode,
resulting in the file being changed from a .mpg to a .nuv file. If you're
using a custom script or transcode application that doesn't use
mythtranscode, you should do the same. >
Thanks. I'll look at adding that. >
>> I have a lot of orphaned
>> snapshots everything I run mythlink. They all appear to be snapshots
>> retrieved before or during transcoding.
I should not send email from a small phone that autocorrects... especially
when low on sleep. That whole sentence was way off. I meant 'still
frames' or pictures, as you assumed above, and mythlink has nothing at all
to do with anything. I guess somehow in a sleep deprived state I
substituted find_orphans with mythlink. >
> snapshots = links?
> If so, running mythlink will delete the existing links in the destination
directory and subdirectories before it creates new links. (If you're using
the "single-file" mythlink approach as a user job or system event, as
described at http://www.mythtv.org/wiki/Mythlink.pl
, you'll need to do as
mentioned in the Note box: "*Note:* You will also need to run
mythlink.plseparately to remove old symlinks. See Usage < http://www.mythtv.org/wiki/Mythlink.pl#Usage
Mythlink was a red Herring based on my bad incoherent rambling above. >
>> I assumed that was just a timing
>> issue and nothing really fixable.
>> Is this what you are experiencing?
>> I'm not sure about the permissions. Mine has mythtv as the owner and
> You'll need to have read and write for files and read and write and
execute for directories (and at least read and execute for parent
directories) for the user running mythbackend. >
> Chances are that the problem is actually permissions. If, for example,
you kick off a transcode using the frontend (versus a queued transcode
using the backend), it will run as the user running the frontend. So, if
you have different users running mythbackend and mythfrontend (or, multiple
users running mythlink or ...), it can cause problems and prevent MythTV
from just "doing the right thing", as it was designed.. >
Thanks Mike. I am using a custom transcoding script based on the wrapper
stub on the wiki. It looks like I need to add something to delete or better
yet rename corresponding images to the new file extension. (which is in the
still images name but not it's actual extension).
That shouldn't be to hard to add.