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

[Paul Stillwell]

> On Sep 15, 2015, at 9:36 AM, Michael T. Dean <mtdean at thirdcontact.com> wrote:
> 
> On 09/15/2015 11:21 AM, Paul Stillwell wrote:
>> On Sep 15, 2015, at 6:30 AM, Michael T. Dean wrote:
>>> On 09/15/2015 09:26 AM, Michael T. Dean wrote:
>>>> On 09/14/2015 10:44 PM, Mike Holden wrote:
>>>>> But deletepending appears to be 1 for the records posted earlier? Not sure I understand the comments about corrupted databases?
>>>> Ah, you're right. I misread it because of the bad wrapping and thought the filesize values were the deletepending values.
>>>> 
>>>> So, a 1 means that the backend was in the process of deleting them. Because they're not actually deleting, that means that something very bad happened to the backend when it was in the process and they got stuck in a limbo state, where they're not deleted, but they're not available.
>>> BTW, something very bad like a very ugly shutdown (power outage/kill -KILL/...) at a very bad time (the tiny amount of time when deletion is in a dangerous state) right after the recordings were deleted.
>> OK, looks like this is resolved for me. It looks like the recordings were stuck somehow and I was able to recover them by cleaning up the deletepending flag.
>> 
>> The very bad thing that happened to my database
> 
> Actually, I didn't explain it well, but the very bad thing has to happen to mythbackend--the database itself can't cause the problem. It could possibly even be cause by a very badly-timed backend crash, so maybe that happened and something automatically restarted it for you, so you didn't realize?
> 
>>  was find_orphans.py. I’m not sure what went wrong with it, but everything was fine until I ran that and then everything wasn’t fine.
> 
> find_orphans.py just asked mythbackend to delete all your recordings (metadata).  It did this because your recording files were not there--likely because you had misconfigured (or hadn't yet configured/updated) your Storage Groups or your file systems referenced by your Storage Group directory lists weren't mounted/accessible (i.e. permissions or whatever) by the backend(s) when find_orphans.py was run.
> 
>>  Now that I think about it, wasn’t there some scripts that we were not supposed to use anymore when we went to 0.27? I have some nagging thought in the back of my head about something changing and some scripts not working anymore, but I can’t remember.
>> 
>> Thanks to everyone for their help!!
> 
> find_orphans.py works just fine with 0.27 (and likely even development, though it's not guaranteed to work with development). The only reason it failed for you is because a) your backends were unable to find the recording files you had and b) you told it to delete the long list of recordings, which turned out to be all your recordings.
> 
> find_orphans.py simply talks to the backend, asking it for the list of all the recording metadata, the list of all the files in the Storage Group directory lists, and--if you tell it to do so--to delete the metadata and/or files that are lacking matching files/metadata.  It's primarily scripts that do things themselves--especially manipulating and changing data directly--that are dangerous.
> 
> Anyway, I'm glad you got things working again.
> 
> Mike

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’t 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’t care where the files were as long as they were on a drive that was mounted as part of the storage group.

Paul