Patch: Adds detail when mythfilldatabase cache isn't writable

[Bill Meek <keemllib@…>]

Comments on the -users list suggest that additional detail in the logs will lead users to fix the problem of unwritable /tmp/mythtv_ddp_data files (likely caused by incorrectly running MFDB as root.)

For example: ​http://www.gossamer-threads.com/lists/mythtv/users/530443#530443

[Bill Meek <keemllib@…>]

v0.27-pre-72-gda065e4-dirty

[Bill Meek <keemllib@…>]

Please close. There is a case where this patch doesn't work. I'll re-open if I find a better solution.

[Raymond Wagner]

Closed at submitter's request.

[Bill Meek <keemllib@…>]

I should have opened this as a bug, not a feature. Corrected patch attached.

For backends that don't (or rarely) boot, the /tmp/mythtv_ddp_data file may be found with permissions of 644 and an owner/group of the 1st user to run mythfilldatabase.

If the user running MFDB is always the same (most likely mythtv,) there is no problem.

If a user other than mythtv manually runs MFDB 1st, or if the backend is improperly started as root, mythtv user runs of MFDB by the BE fail.

This problem can be avoided by setting the permissioins on the file to allow anyone to write it (the 1st user to run the program does this and any other user silently fails to change them.)

Tested in the following cases:

If /tmp/mythtv_ddp_data doesn't exist,
  After creating it, change its mode to 666.

If a writable /tmp/mythtv_ddp_data exists,
  No change, normal run.

If /tmp/mythtv_ddp_data exists, and isn't writable,

  The following will appear in mythfilldatabase's log:

    E  DataDirect: Failed to get data: Aborting: /tmp/mythtv_ddp_data is not writable
    
  The run is aborted (no sense downloading data if the file can't be
  written.)

[Bill Meek <keemllib@…>]

Corrected patch file.

[Bill Meek <keemllib@…>]

Without color escape sequences.

[danielk]

It looks like DDPost is writing to a fixed file in "/tmp" rather than using the temporary file facility provided in the data direct class and this is causing all the grief.

[danielk]

Eliminates use of temporary file in DataDirectProcessor::DDPost().

[Bill Meek <keemllib@…>]

It seems to work A-OK. Tested both as a housekeeping job and from the command line.

It appears that the download is now done to RAM, as I can't see a file created for the download. However, there was one for the "suggested next time" response e.g.: /tmp/mythtv_ddp_F48l0F/mythtv_result_DtUYEM

Downloaded 1.31429 megabytes in 37.853 seconds, decompressed to 14.8522 megabytes

I also simulated someone starting MFDB on top of a running housekeeping job by running MFDB --dd-grab-all...& twice will no adverse affects (I dumped the entire program table before and after the above and ran sha1sum on each with the same result.)

There won't be another housekeeping run to test until 11/7.

[Bill Meek <keemllib@…>]

Apologies if this was waiting for more data from me. The fix is working fine. I have two logging suggestions:

The text in: libs/libmythtv/datadirect.cpp

+    LOG(VB_GENERAL, LOG_INFO, LOC + QString("Using Suggested Time Filename '%1'")
+        .arg(resultFilename));

needs a tuneup. "Using Filename '%1'" would make more sense in the log (remove Suggested Time.)

And in libs/libmythtv/datadirect.cpp, this LOG()

+    LOG(VB_GENERAL, LOG_INFO, LOC + QString("Using input '%1'")
+        .arg(inputfile));

always prints as:

... CoreContext datadirect.cpp:1182 (GrabData) - DataDirect: Using input ''

in my log files (there is never any text between the aphostrophies.)

[Bill Meek <keemllib@…>]

Retested 8/28/2013. I don't see the above patch being committed (there's still reference to /tmp/mythtv_ddp_data in the source.)

However, now when running MFDB, that file doesn't appear.

Appears OK to close.