[Solved] 662GB of orphans!!

Have a MythTV related problem? Ask for help from other MythTV users here.

Moderator: Forum Moderators

Post Reply
PhilB
Senior
Posts: 279
Joined: Sun May 11, 2014 6:23 pm
Great Britain

[Solved] 662GB of orphans!!

Post by PhilB » Thu Jan 13, 2022 2:21 pm

Sorry to come back again with my incessant questions.

My frontend tells me that I have 642 recordings, a figure which is confirmed by the api getrecordedlist but find_orphans tells me that two of those are orphans.
../setup/find_orphans.py
Orphaned video files
myth2: /var/lib/mythtv/recordings/20009_20211228195600.ts 2.1GB
myth2: /var/lib/mythtv/recordings/20009_20211228205600.ts 4.5GB
...
I have been doing database restores to diagnose channel/mythweb issues so that may explain those two. If I add a spurious file junk.mpg to the folder then find_orphans faithfully lists it.

However, a scan of the recording folder shows a very different story with types:
1 .
1 ..
5 gz
20 jpg
1004 mpg
1029 png
63 ts
Total 2123
There are 2 .ts files and 423 .mpg files there which are not revealed in either the frontend or the getrecordedlist api. The 423 .mpg which are not reported by find_orphans are all imported from a Mythtv 0.27 setup and are taking up 660GB. I didn't need that new disk!!
find_orphans under 0.27 does not find them either.

Now under 0.27 the api lists all these recordings but the recording group is shown as 'Deleted'.
Quite how or why they were not deleted under 0.27 is unclear - possibly closedowns immediately after a recording deletion?

Under version 31 though the api does not list them.

It looks as if the recording are still in the database, have a recording group of 'Deleted' but are hidden from the api and the frontend.
find_orphans however sees them as valid recordings so does not list them as orphans.

Now I can easily list and delete these real orphans but it would be irresponsible not to at least flag the issues here:

1. What is the mechanism for deleting files? How do they get left behind? Does 31 still have this issue?
2. The 31 api no longer list Deleted recordings.
3. find_orphans.py does not find them.

My fe/be is version 31.20211108 and find_orphans is the latest 31+ from the wiki.

/usr/lib/python3/dist-packages/MythTV/utility/dt.py includes the lines:
utc_naive = self.replace(tzinfo=None) - self.utcoffset()
utc_naive = utc_naive.replace(tzinfo=None)
return ((utc_naive - utc_epoch).total_seconds())
so the bindings are as recommended in viewtopic.php?f=36&t=4071

Phil
Last edited by PhilB on Fri Jan 14, 2022 6:29 pm, edited 1 time in total.

User avatar
dnalorernst
Developer
Posts: 63
Joined: Mon Feb 17, 2020 8:03 pm
Austria

Re: 662GB of orphans!!

Post by dnalorernst » Thu Jan 13, 2022 5:33 pm

Please check, if the recordings have the 'deletepending' flag set.
See viewtopic.php?f=36&t=2888&p=14057&hilit=limbo#p14057
for further guidance.

Roland

PhilB
Senior
Posts: 279
Joined: Sun May 11, 2014 6:23 pm
Great Britain

SOLVED: 662GB of orphans!!

Post by PhilB » Fri Jan 14, 2022 6:27 pm

Thanks for your reply. Most helpful.
That sql has indeed fixed the problem. After clearing the deletepending flags the spurious recordings were gradually deleted by the backend.
I have a strong belief that, given the huge number of them, that the deletepending recordings were not caused by system crashes but by our habit of viewing a recording, deleting it then closing the system down. Doing that for 7 years built up the 600+ recordings.
This is a condition not tested by mythshutdown in a mythwelcome scenario.
I am marking this as solved but I think there is need for an enhancement request/documentation update which I'll tackle in the coming days.
Phil

Post Reply