<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 16 September 2015 at 04:33, Hika van den Hoven <span dir="ltr"><<a href="mailto:hikavdh@gmail.com" target="_blank">hikavdh@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Hoi Paul,<br>
<div><div class="h5"><br>
Tuesday, September 15, 2015, 7:54:29 PM, you wrote:<br>
<br>
<br>
>> On Sep 15, 2015, at 10:01 AM, Hika van den Hoven <<a href="mailto:hikavdh@gmail.com">hikavdh@gmail.com</a>> wrote:<br>
>><br>
>><br>
>> Hoi Paul,<br>
>><br>
>> Tuesday, September 15, 2015, 6:46:55 PM, you wrote:<br>
>><br>
>><br>
>><br>
>>> Mike,<br>
>><br>
>>> Thanks for the explanation! Maybe this is what caused the issue:<br>
>><br>
>>> I had an internal hard drive fail that had some recordings on it. I<br>
>>> was able to rsync most of that drive to an external hard drive. I<br>
>>> have a second internal drive that also has some recordings on it.<br>
>>> When I would look at the front end there would be a bunch of<br>
>>> recordings that were greyed out and had Xs by them. I knew they were<br>
>>> on the failed drive (that wasn=E2=80=99t being mounted) and I knew at some<br>
>>> point I would get another hard drive and replace the failed one. I<br>
>>> finally replaced the failed drive last week and rsynced all the data<br>
>>> from the external drive to the internal drive (that was mounted with<br>
>>> the same name as the old failed drive). When the sync was done, all<br>
>>> my recordings that had Xs next to them were back with the exception<br>
>>> of a few (they were not recoverable from the failed drive). Could<br>
>>> that have caused the issue? I thought that Myth didn=E2=80=99t care where<br>
>>> the files were as long as they were on a drive that was mounted as part o=<br>
>> f the storage group.<br>
>><br>
>>> Paul<br>
>><br>
>> But that is exactly what find_orphans.py is supposed to do, "throw<br>
>> away DB records for files that at that moment do not exist!"  and/or<br>
>> the other way around. So you should never run it if such records<br>
>> exist that should get fixed when you come to replacing that drive!<br>
>><br>
>> Tot mails,<br>
>>  Hika                            mailto:<a href="mailto:hikavdh@gmail.com">hikavdh@gmail.com</a><br>
>><br>
>> "Zonder hoop kun je niet leven<br>
>> Zonder leven is er geen hoop<br>
>> Het eeuwige dilemma<br>
>> Zeker als je hoop moet vernietigen om te kunnen overleven!"<br>
>><br>
>> De lerende Mens<br>
>><br>
>><br>
<br>
> Maybe I’m not understanding something. All of the recordings were<br>
> there, I had just finished copying them from an external drive back<br>
> to an internal drive. The recordings were playable from myth front<br>
> end so in my mind they existed and were visible to the front end.<br>
> Why would find_orphans.py think they don’t exist?<br>
<br>
> Paul<br>
> _______________________________________________<br>
<br>
</div></div>Maybe, I'm not sure, but if had just finished rescuing my recordings,<br>
I would have checked everything at least five times including my<br>
backups, before running a potential destructive script like<br>
find-orphans! And I'm not even sure I would have done it.<br>
<span class="im"><span style="color:rgb(34,34,34)"></span></span></blockquote><div><br></div><div>I've seen deletions fail in a similar manner to this when the backend doesn't have permission to delete the file. This was probably a version or 2 of mythtv ago for me, so may not be an observation on current version, but I have had records stuck in this deletepending=1 state.</div></div></div><div class="gmail_extra"><div><br></div><div>If this is the case for you, maybe it just saved your recordings collection :-)</div><div class="gmail_extra"><br></div></div></div>