| Mythimport v3 beta: mythimport |
| Mythexport daemon v3 beta: mythexport-daemon |
| Mythbuntu 16.04 mythexport v2 package with corrected
dependencies: mythexport_2.2.4-0ubuntu5-jsw2_amd64.deb |
| Mythbuntu 16.04 mythimport v2 package with corrected dependencies: mythimport_2.2.4-0ubuntu5-jsw2_amd64.deb |
To install the beta versions of mythimport and mythexport-daemon, you first need to install the current version of the mythexport package, however that is done in your Linux distro. If you are using Mythbuntu 16.04, and have switched from using MySQL to MariaDB as I have, the standard 16.04 packages have a bug in their dependencies which will cause MariaDB to be uninstalled and MySQL to be installed instead. To avoid this, you can download my corrected 16.04 package (above) and install it instead. I recommend doing this rather than using the old packages even if you are still using MySQL, as you may want to change to MariaDB in the future and may not remember this problem, which would result in MythTV being unintentionally uninstalled. If you already have the old mythimport package installed, either uninstall it or install my version to fix the dependencies.
How to install my package files:
sudo dpkg -i
mythexport_2.2.4-0ubuntu5-jsw2_amd64.deb
sudo dpkg -i mythimport_2.2.4-0ubuntu5-jsw2_amd64.deb
Once you have installed the original version of mythexport, download my new mythimport and mythexport-daemon files and install them manually. The new mythimport file can normally just be put in /usr/local/bin and it will then be used in preference to the original version if installed (usually in /usr/bin). The new mythexport-daemon needs to replace the original file as there are things that refer to it using its specific path. For Mythbuntu 16.04, do this from the directory where you downloaded the new files:
sudo mv -v mythimport /usr/local/bin
sudo chown root:root /usr/local/bin/mythimport
sudo chmod u=rwx,g=rx,o=rx /usr/local/bin/mythimport
sudo mv -v /usr/bin/mythexport-daemon
/usr/bin/mythexport-daemon.original
sudo mv -v mythexport-daemon /usr/bin/
sudo chown root:root /usr/bin/mythexport-daemon
sudo chmod u=rwx,g=rx,o=rx /usr/bin/mythexport-daemon
The mythexport-daemon will then need to be restarted. For Mythbuntu 16.04, do this:
sudo systemctl restart
mythexport
There can be problems with the installation of the Mythexport web pages. They have to be properly set up in Apache and referenced correctly under /var/www. Some time ago, when I was upgrading Ubuntu versions, I found that Mythweb stopped working for me - the web page was not available and I got a blank page or the Apache default "nothing is installed yet" page. I had to manually move where it was installed from /var/www/mythweb to /var/www/html/mythweb. I can not remember now what the version of Mythbuntu was where I first had this problem - either 14.04 or 16.04. I do not know if this problem happens when installing a clean 16.04+ system or not - I would hope not. Mythexport's web page setup suffers from the same problem. So do this:
ll /var/wwwll /var/www/htmland if you do not see mythweb or mythexport links in /var/www/html and do see them in /var/www, they will need to be moved to /var/www/html:
sudo rm /var/www/mythwebsudo ln -s -t /var/www/html /usr/share/mythtv/mythweb/
sudo rm /var/www/mythexportsudo ln -s -t /var/www/html /usr/share/mythtv/mythexport/
If
you had to move the mythweb link, then you may need to edit the file /etc/apache2/sites-available/mythweb
and change this line:
<Directory "/var/www/mythweb"
>
to this:
<Directory
"/var/www/html/mythweb" >
And similarly if you needed to move the mythexport link, you may need
to edit the file /etc/apache2/sites-available/mythexport and
change this line:
<Directory "/var/www/mythexport"
>
to this:
<Directory
"/var/www/html/mythexport" >]
If there are any other references in those files to /var/www instead of /var/www/html, they should be changed also.
If you have had to make any changes to the Apache configuration as above, then you will need to restart Apache to get it to read the new configuration. In Mythbuntu 16.04, do this:
sudo systemctl restart apache2
For support and discussion about this software, please use the MythTV mailing list:
or the MythTV forums:
usage: mythimport [-h] [-1] [-a] [-c {debug,info,warning,error,critical}]
[-i INPUT_DIR] [-l {none,debug,info,warning,error,critical}]
[--logdir LOGDIR] [-m] [--mythlog] [-n] [-o OUTPUT_DIR]
[-r MAXLOGFILES] [-s MAXLOGFILESIZE] [-v]
Import MythTV recordings exported by Mythexport (Version: 3.0.5 2017-06-09)
optional arguments:
-h, --help show this help message and exit
-1, --dontrotatelogs
do not rotate log files, just overwrite to the same (single)
log file each time mythimport is run (default: false)
-a, --append_to_log
append output to the end of the existing log file. Does not
work with --mythlog.
-c {debug,info,warning,error,critical}, --consolelevel {debug,info,warning,error,critical}
sets the console logging level (default: info)
-i INPUT_DIR, --input_dir INPUT_DIR
input directory (default: <current directory>)
-l {none,debug,info,warning,error,critical}, --loglevel {none,debug,info,warning,error,critical}
sets the logging level in the log file (default: debug)
--logdir LOGDIR
logging directory (default: <current directory>)
-m, --nomove
do not move the recording files that have been imported to the
output directory (default: false, do move the recording files)
--mythlog, --MythLog
use MythLog python binding for logging. Implies -1. For log
rotation when using --mythlog, try using logrotate (eg create a
/etc/logrotate.d/mythimport file)
-n, --nocleanup
do not delete the .sql files that have been imported (default:
false, do delete the .sql files)
-o OUTPUT_DIR, --output_dir OUTPUT_DIR
output directory (should be in a MythTV storage group). If not
specified, defaults to the first directory in the 'Default'
storage group that is on the same mountpoint as the input
directory.
-r MAXLOGFILES, --rotate_max MAXLOGFILES
maximum number of log files to keep when rotating (default: 9)
-s MAXLOGFILESIZE, --rotate_size MAXLOGFILESIZE
maximum size of a log file before it will be rotated (default:
10485760 bytes)
-v, -V, --version
Mythexport is a set of tools to allow you to export recordings from your MythTV system to use on other systems. It can export in a format for use on another MythTV system ("On the Go"), or it can transcode and stream recordings in formats used by various devices (eg phone, tablet). I have never used the transcoding and streaming options so I do not know much about them. Mythexport consists of two parts: a set of web pages that are installed in Apache alongside MythTV's mythweb pages, and a background daemon that does the actual exporting, transcoding and streaming.
Mythimport is a tool to allow the export of recordings from one MythTV system and their import into another MythTV system. The "On the Go" option of the mythexport web page produces a page listing all the recordings on a MythTV system and allowing the selection of recordings that are to be exported, and where they are to be exported to. The export operation is queued for the background mythexport daemon to execute, and when the daemon has finished, the directory selected for exporting to contains the SQL data for the recordings, along with copies of the recording files. Those files can then be moved to another MythTV system and there they can be imported using mythimport, a standalone program.
I regularly use mythexport/mythimport to export recordings to my laptop for viewing when I am away from home, and also to give my mother copies of recordings I make for her on my MythTV box. She has her own MythTV box that is on the same network as mine and I can export the required files over Ethernet to a directory on her box. For my laptop, I have two external hard drives for it that I can attach on external eSATA or USB 3 drive mounts. Those hard drives can also be temporarily attached to my MythTV box or my mother's for recordings to be exported to them.
As of MythTV 0.28, a new field 'recordedid' was added to the mythconverg database 'recorded' table and it is now the primary key. It is an autoincrementing field that has a unique value for each recording. However, those values are only unique within one MythTV system. If mythexport/mythimport is used to import a recording from one MythTV system into another MythTV system, the recordedid value for the imported recording may already be in use on the system it is being imported into, and importing that recording's database entries exactly as they are in the original MythTV system will not work. A new recordedid value compatible with the new MythTV system needs to be used instead of the old value, and that same recordedid value needs to be used in all places where recordedid is found in the SQL data for the recording. The way that the old mythimport program worked was to just use the standard MySQL command line tool to execute the SQL statements created by mythexport on the system where mythimport was run. That produced an exact copy of the data as it was exported from the old system on the new system, and was very easy to do as it just used a standard MySQL tool. To fix this to work with MythTV 0.28 was not practical, as it would have required accurately parsing all the exported SQL data for the recordedid fields and replacing the values in there with correct values for the new system. However, as the new system could be starting a new recording at any time, and that new recording would use a new recordedid value, there was no way to guarantee that the recordedid value that had been replaced into the exported SQL would still be valid by the time the SQL data was imported. And accurately parsing SQL data is a very difficult thing to do properly. So I decided I would have to use a different approach to fix this problem, which was to get the system the SQL data was being imported into to create a new recordedid value for the recording being imported, as the import was being done. That approach would allow the use of the standard MySQL mechanism for creating a new 'recorded' table row with a unique recordedid value, which, if done properly, is always guaranteed to produce a unique recordedid value regardless of any recordings being started at the same time. This approach required a complete re-write of the mythimport program, and I chose to do that in Python as MythTV has good Python bindings that allow easy access to its mythconverg database, and I know enough Python to write the code.
As well as the recordedid problem, I had found that mythimport also suffered from some usability issues, so I also set out to fix them too. The main issue I had encountered was error handling. When there was an error during the import of the SQL data, the MySQL tool mythimport was using for this simply stopped at the point the error occurred. So you would wind up with some recordings having been imported fully, one recording partially imported to the point where the error occurred, and any subsequent recordings not imported at all. What I found was that I often would mistakenly try to export a recording that had been previously exported, and that would cause such an error. Manually editing the SQL file and restarting the import was possible, but very time consuming and tedious, and required a high degree of expertise in SQL and MythTV. To fix this, I have changed mythexport and mythimport to put the SQL data for each recording in a separate SQL file named the same as the recording file with a .sql extension added at the end. That meant that the importing of each recording could be done separately and any recording that could not be imported could be skipped without affecting the import of the other recordings. As well, I have added a fair bit of error checking to see if it is safe to import a recording, before any attempt is made to do so. And I have added a full set of logging options so you can see exactly what happened during import. Testing so far shows that I seem to have succeeded in making mythimport much more usable as I have not had to do any manual fixups since I started using my new mythimport. That should make mythexport/mythimport usable by normal MythTV users, rather than just programmers like myself.