[mythtv-users] /find_orphans.py crashes mythbackend

[Mark Perkins]

On 11 September 2016 3:53:28 PM ACST, Udo van den Heuvel <udovdh at xs4all.nl> wrote:
>On 04-09-16 14:43, Stuart Auchterlonie wrote:
>>> Does find_orphans manage the amount of files sent to the backend to
>>> be deleted?
>>> Does the backend manage the amount of files sent to mysql to be
>>> deleted? Assuming one can delete all files sent to 'it; in one go at any time
>>> is a weird assumption.
>> 
>> So we probably don't use a queue and try to delete all the recordings
>> at once. /me shrugs
>
>So we need a queue or similar.
>I cannot reproduce the issue anymore without deleting my recordings.
>Maybe we can have a simple SQL query to inject some fake recordings?
>(i.e. e.g. duplicate the available recordings with a changed year)
>That would mean that anyone can reproduce the issue without harming
>their recordings.
>


What about just:
1) backup database
2) edit / point all storage groups to a single empty folder
3) confirm mythfrontend now shows all records as orphaned
4) redo whatever steps you did with find_orphans.py to reproduce. Backtrace as necessary.
5) once finished testing / backtrace, restore database and everything (including storage groups) should be back to normal?

One thing though - not to prolong this thread but tbh something has 'confused' me. iirc the original thread was about orphaned recording files - so in my mind the database records were missing with the recording files (ts / mpg / mp4 / whatever) still present in the storage group folders.

But later it was noted that the cause of the problem was the recording files being deleted manually with the database records still present, so orphaned records not orphaned recordings. So if the recording files were already deleted then why would there be so many files open? I guess maybe the preview pictures? Just struck me as odd at the time.

I guess the answer will be in your backtrace once you reproduce your steps.