Older Recordings Deleted After Database Connection Fails

[jksjdevelop@…]

v0.28-pre-1463-g23813a5 I use mythTV as a timeshifter so do not normally keep recordings for very long - so I did not notice straight a way when some went missing. On Jun 6th I went into I am sure I recorded that mode and noticed that I did not have any recordings older than the 25th May. Checking the logs I noticed that at 13:15 on Jun 4th something had cleared out 25 items using DoHandleDelete3. The nasty seems to be that the backend lost the database connection for some reason. Defaulted to the storage group being /var/lib/mythtv/recordings which is on a different partition to the actual one and then flushed out the older stuff.

Jun  4 13:15:12 tv mythbackend: mythbackend[10065]: E ProcessRequest mythdbcon.cpp:217 (OpenDatabase) Driver error was [1/1040]:#012QMYSQL: Unable to connect#012Database error was:#012Too many connections
....
Jun  4 13:15:12 tv mythbackend: mythbackend[10065]: E ProcessRequest mythdb.cpp:183 (DBError) DB Error (StorageGroup::StorageGroup()):#012Query was:#012#012Bindings were:#012:GROUP="Default"#012No error type from QSqlError?  Strange...
Jun  4 13:15:12 tv mythbackend: mythbackend[10065]: E ProcessRequest storagegroup.cpp:187 (Init) SG(LiveTV): Unable to find any Storage Group Directories.  Using old 'RecordFilePrefix' value of '/var/lib/mythtv/recordings'
Jun  4 13:15:30 tv mythbackend: mythbackend[10065]: I Scheduler scheduler.cpp:2103 (HandleReschedule) Reschedule requested for CHECK 0 2542 0 DoHandleDelete3 | Orphan Black | 4/10 | Governed as It Were by Chance: Sci-fi drama series. With Cosima's help, Sarah digs into the origins of the clone experiment. The hunt takes her right into the belly of the beast. | fp.bbc.co.uk/4j63iy
Jun  4 13:15:30 tv mythbackend: mythbackend[10065]: I Scheduler scheduler.cpp:2103
# then deletes 13 more items

It might be a good idea to inhibit the housekeeper after database connection failure.

[Karl Egly]

This appears to be a configuration / packaging error that triggered a bug. If this is the case then fixing the configuration error would be the short term solution. Fixing the subsequent error would be for 0.28.

Database error was:
Too many connections

What is your MySQL connection limit? For the Debian / Ubuntu packaging we explicitly set it to 100. See ​https://github.com/MythTV/packaging/blob/master/deb/debian/mythtv.cnf From your other tickets it appears as if you may be using Mythbuntu packaging, but its not clear if the MySQL configuration is working as designed.

Can you identify why the auto expirer decided to delete these 25 recordings? Was is to make room for a running recording. Deleting one after another from the database, then seeing that there still was not enough free space and deleting the next recording?

Did the auto expire remove only the database entries or also the actual recording files? I'm wondering if testing for existence of the file before issuing the deletion request would prohibit this issue. Thinking that without knowledge of the Storage Groups it will not find the file and skip the recording.

Another idea is to remove the fallback to pre-StorageGroup? configurations for good.

[jksjdevelop@…]

As this issue has not re-occurred in the last 18 months I would be happy for it to be closed as a one off even though the consequences are a bit severe. I build from source currently on Ubuntu Wily. I checked mythtv.cnf and can confirm that it is not currently installed so I am running with the default configuration of mysql. Should the make install command after compilation install this file or is that thought to be too platform specific. I now set recordings to be none auto deletable in my default recording template, as a precaution against this re-occurring. However I know it has not, as I have a few recordings deliberately not protected so that I could tell if the problem re-occurred. The auto expire removed both the files and database entries but beyond that I cannot remember any more details. Many thanks.

[Karl Egly]

No, make install should not fiddle about with the mysql configuration. As the integration of custom configuration for the mysql service is distribution specific that is done in the packaging of each distribution. For Debian / Ubuntu it is in ​https://github.com/MythTV/packaging/blob/master/deb/debian/mythtv-database.install

[Karl Egly]

Reschedule all tickets planned for, but not solved in time for, 0.27.6 to 0.27.7.

[Peter Bennett]

Closing this as a one-time problem. Likely the system deleted the expired recordings to make space. One should only allow recordings to expire if they are not important.