[mythtv-users] Database issue? Recordings not showing up in frontend

Mike Holden mikeholden99+mythtv at gmail.com
Wed Sep 16 00:36:49 UTC 2015


On 16 September 2015 at 04:33, Hika van den Hoven <hikavdh at gmail.com> wrote:

> Hoi Paul,
>
> Tuesday, September 15, 2015, 7:54:29 PM, you wrote:
>
>
> >> On Sep 15, 2015, at 10:01 AM, Hika van den Hoven <hikavdh at gmail.com>
> wrote:
> >>
> >>
> >> Hoi Paul,
> >>
> >> Tuesday, September 15, 2015, 6:46:55 PM, you wrote:
> >>
> >>
> >>
> >>> Mike,
> >>
> >>> Thanks for the explanation! Maybe this is what caused the issue:
> >>
> >>> I had an internal hard drive fail that had some recordings on it. I
> >>> was able to rsync most of that drive to an external hard drive. I
> >>> have a second internal drive that also has some recordings on it.
> >>> When I would look at the front end there would be a bunch of
> >>> recordings that were greyed out and had Xs by them. I knew they were
> >>> on the failed drive (that wasn=E2=80=99t being mounted) and I knew at
> some
> >>> point I would get another hard drive and replace the failed one. I
> >>> finally replaced the failed drive last week and rsynced all the data
> >>> from the external drive to the internal drive (that was mounted with
> >>> the same name as the old failed drive). When the sync was done, all
> >>> my recordings that had Xs next to them were back with the exception
> >>> of a few (they were not recoverable from the failed drive). Could
> >>> that have caused the issue? I thought that Myth didn=E2=80=99t care
> where
> >>> the files were as long as they were on a drive that was mounted as
> part o=
> >> f the storage group.
> >>
> >>> Paul
> >>
> >> But that is exactly what find_orphans.py is supposed to do, "throw
> >> away DB records for files that at that moment do not exist!"  and/or
> >> the other way around. So you should never run it if such records
> >> exist that should get fixed when you come to replacing that drive!
> >>
> >> Tot mails,
> >>  Hika                            mailto:hikavdh at gmail.com
> >>
> >> "Zonder hoop kun je niet leven
> >> Zonder leven is er geen hoop
> >> Het eeuwige dilemma
> >> Zeker als je hoop moet vernietigen om te kunnen overleven!"
> >>
> >> De lerende Mens
> >>
> >>
>
> > Maybe I’m not understanding something. All of the recordings were
> > there, I had just finished copying them from an external drive back
> > to an internal drive. The recordings were playable from myth front
> > end so in my mind they existed and were visible to the front end.
> > Why would find_orphans.py think they don’t exist?
>
> > Paul
> > _______________________________________________
>
> Maybe, I'm not sure, but if had just finished rescuing my recordings,
> I would have checked everything at least five times including my
> backups, before running a potential destructive script like
> find-orphans! And I'm not even sure I would have done it.
>

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.

If this is the case for you, maybe it just saved your recordings collection
:-)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mythtv.org/pipermail/mythtv-users/attachments/20150916/cd5f872e/attachment.html>


More information about the mythtv-users mailing list