MacPorts and Myth 0.28

[gsulshski]

In /opt/local/etc/mariadb/my.cnf, you can specify where you want any log files. I don't know if there is a default (mine is always custom), if there was, I would expect it to be in /opt/local/var/log and possibly under mariadb there. Looking at the macports defailts, it might actually be /opt/local/var/db/mariadb/localhost.err? It sounds sort of like mariadb might be having issues and stopping now and then which would then give you the errors. The log file would show any issues. You sure you didn't also change mariadb versions (major ones), and if you did, you do need to run the upgrade on the database. Or, you may also have crashed tables or other odd issues. The log would tell you. Since you say it connects sometimes, it should not have anything to do with user or passwords.

Thanks for point out where the mariadb log file was.. .in my my.cnf it was at /opt/local/var/db/mariadb/localhost.err. I will update my my.cnf to be a log file to

Code: Select all

[log-error=/opt/local/var/log/mariadb/localhost.log

as you suggest in one of your responses..

i used for 0.28

Code: Select all

 sudo port install mythtv-core.28 +mariadb+mariadb55+python27+perl5_24

for 0.27 i am assuming I used

Code: Select all

sudo port install mythtv-core.27 
+mariadb+mariadb55+python27+perl5_16

so I don't think I moved to another mariadb version.

Here is the log file results from over 1 week ago when I rebooted. I haven't seen anything else in the log file since.
Also, I have sleep = never.


160923 7:32:17 [Note] /opt/local/lib/mariadb/bin/mysqld: Normal shutdown

160923 7:32:21 [Note] Event Scheduler: Purging the queue. 0 events
160923 7:32:23 InnoDB: Starting shutdown...
160923 7:32:24 InnoDB: Waiting for 1 pages to be flushed
160923 7:32:25 InnoDB: Shutdown completed; log sequence number 1001324168
160923 7:32:28 [Note] /opt/local/lib/mariadb/bin/mysqld: Shutdown complete

160923 7:38:30 InnoDB: The InnoDB memory heap is disabled
160923 7:38:30 InnoDB: Mutexes and rw_locks use GCC atomic builtins
160923 7:38:30 InnoDB: Compressed tables use zlib 1.2.8
160923 7:38:30 InnoDB: Initializing buffer pool, size = 128.0M
160923 7:38:30 InnoDB: Completed initialization of buffer pool
160923 7:38:30 InnoDB: highest supported file format is Barracuda.
160923 7:38:30 InnoDB: Waiting for the background threads to start
160923 7:38:31 Percona XtraDB (http://www.percona.com) 5.5.48-MariaDB-37.8 started; log sequence number 1001324168
160923 7:38:31 [Note] Server socket created on IP: '::'.
160923 7:38:31 [Note] Event Scheduler: Loaded 0 events
160923 7:38:31 [Note] /opt/local/lib/mariadb/bin/mysqld: ready for connections.
Version: '5.5.49-MariaDB' socket: '/opt/local/var/run/mariadb/mysqld.sock' port: 3306 Source distribution
160923 7:38:50 [Warning] IP address '192.168.1.8' could not be resolved: nodename nor servname provided, or not known
160923 7:42:01 [Warning] IP address '192.168.1.19' could not be resolved: nodename nor servname provided, or not known
160923 7:42:21 [Warning] IP address '192.168.1.9' could not be resolved: nodename nor servname provided, or not known

[gsulshski]

...
1) The recordings are named Channel_Starttime.ts vs Channel_Starttime.mpg : I had to modify the scripts with the new file extension but the content is still mpeg stream
2) For some reason, mythtranscode (what I use to remove the commercials) operates differently in 0.28 and I had to change the mythtv setup - general - job queue (general) - check save original files after transcoding (globally) or my job would fail (recording was removed after I transcoded to remove the commercials).
3) For some reason, when I was using tvdb.py to look up the season and episode, it was always returning a empty xml file. I debugged it and found that script was trying to access a api file in my directories that had root access and would fail. I updated the script with sudo $PATH/tvdb.py vs $PATH/tvdb.py it worked. Not sure what this has to do with 0.28 but I didn't have this issue with 0.27.

MythWeb 0.28
Operation wise: It isn't very stable from my perspective.
Most of the time I get
Fatal error: Call to a member function query_col() on a non-object in /opt/local/apache2/htdocs/MythWeb/modules/backend_log/init.php on line 15
...

1) Yes, the filename extension was changed in 0.28.

2) AIUI, you just need to change a setting. See:

http://www.gossamer-threads.com/lists/m ... 103#602103

3) This is new to me. I'll have a look when I get a chance.

MythWeb -- I haven't experienced this issue. I wonder if some caching is going on? Which browser are you using? Does it also occur with other browsers?

Craig

For MythWeb, I normally pin a tab with Safari for MythWeb. I see that same behavior on local or remote machines and with Chrome.
This morning I tried it and it worked the first 8 times and then it failed. It appears to be more of a "connection" problem.

For WebFrontend, I don't have any problems.

[pvr4me]

...Thanks for point out where the mariadb log file was.. .in my my.cnf it was at /opt/local/var/db/mariadb/localhost.err. I will update my my.cnf to be a log file to

Code: Select all

[log-error=/opt/local/var/log/mariadb/localhost.log

as you suggest in one of your responses..

...

Here is the log file results from over 1 week ago when I rebooted. I haven't seen anything else in the log file since.
Also, I have sleep = never.

The database only writes to the log when there is a pretty significant event/error. To make you new log setting take effect, you need to stop/start the database. Stop mythbackend, then

Code: Select all

sudo port unload mariadb-server
sudo port load mariadb-server

...
160923 7:38:50 [Warning] IP address '192.168.1.8' could not be resolved: nodename nor servname provided, or not known
160923 7:42:01 [Warning] IP address '192.168.1.19' could not be resolved: nodename nor servname provided, or not known
160923 7:42:21 [Warning] IP address '192.168.1.9' could not be resolved: nodename nor servname provided, or not known

Does your backend machine get/keep the same IP address all the time? I use my router to ensure the backend always gets a known address. There are other ways to achieve the same thing.

Craig

[sfatula]

160923 7:38:50 [Warning] IP address '192.168.1.8' could not be resolved: nodename nor servname provided, or not known
160923 7:42:01 [Warning] IP address '192.168.1.19' could not be resolved: nodename nor servname provided, or not known
160923 7:42:21 [Warning] IP address '192.168.1.9' could not be resolved: nodename nor servname provided, or not known

This can't be good. Never seen that message though. Strange that IP addresses could not be resolved. I presume your server IP is on the 192.168.1.* network with static IP? Have any idea what machine(s) those IPs refer to? Sounds like a networking issue.

For your mythweb connection, what URL are you using in the browser?

For your mythtv configuration, what IP are you using? (On the first mythtv-setup -> General configuration screen). Can you get a screen capture of that screen?

[jtravers]

I have a hackintosh OS X running Mavericks and am building a desktop hackintosh to run El Cap (and Sierra eventually). So 10.9 and above support would work fine with my setup.

Thanks for supporting the community so well!!

[gsulshski]

...Thanks for point out where the mariadb log file was.. .in my my.cnf it was at /opt/local/var/db/mariadb/localhost.err. I will update my my.cnf to be a log file to

Code: Select all

[log-error=/opt/local/var/log/mariadb/localhost.log

as you suggest in one of your responses..

...

Here is the log file results from over 1 week ago when I rebooted. I haven't seen anything else in the log file since.
Also, I have sleep = never.

The database only writes to the log when there is a pretty significant event/error. To make you new log setting take effect, you need to stop/start the database. Stop mythbackend, then

Code: Select all

sudo port unload mariadb-server
sudo port load mariadb-server

...
160923 7:38:50 [Warning] IP address '192.168.1.8' could not be resolved: nodename nor servname provided, or not known
160923 7:42:01 [Warning] IP address '192.168.1.19' could not be resolved: nodename nor servname provided, or not known
160923 7:42:21 [Warning] IP address '192.168.1.9' could not be resolved: nodename nor servname provided, or not known

Does your backend machine get/keep the same IP address all the time? I use my router to ensure the backend always gets a known address. There are other ways to achieve the same thing.

Craig

My Mac mini is static at 192.168.1.19. The other two .8 is my iMac and i think .9 is my fireTV.

[gsulshski]

160923 7:38:50 [Warning] IP address '192.168.1.8' could not be resolved: nodename nor servname provided, or not known
160923 7:42:01 [Warning] IP address '192.168.1.19' could not be resolved: nodename nor servname provided, or not known
160923 7:42:21 [Warnin

Code: Select all

g] IP address '192.168.1.9' could not be resolved: nodename nor servname provided, or not known

Code: Select all

This can't be good. Never seen that message though. Strange that IP addresses could not be resolved. I presume your server IP is on the 192.168.1.* network with static IP? Have any idea what machine(s) those IPs refer to? Sounds like a networking issue.

For your mythweb connection, what URL are you using in the browser?

For your mythtv configuration, what IP are you using? (On the first mythtv-setup -> General configuration screen). Can you get a screen capture of that screen?

I didn't have these messages in my mythtv 0.27.4 logs. I update to both mythv 0.28 (first) and then macOS Sierra.

Mac Mini with mythv is 192.168.1.19 and static.
iMac is .8
I think my fire TV is .9... I will have to check.


for url ... I have for example

Code: Select all

http://192.168.1.19/MythWeb/tv/listing

for Mythsetup screen.. the file was too big ..so

I will just type it in

IPv4 192.168.1.19
IPv6 ::1
Port 6543 status port 6544
Security Pin: 0000
Master backend
IP address 192.168.1.19 port 6543

[pvr4me]

I'm sorry but I'm afraid I'm out of ideas. I know there were some changes to firewall handling in recent OS versions but I would expect that to be all or nothing. Since it works sometimes, perhaps monitor this for a while and see if you can identify conditions that lead to the failure.

I still don't have a Sierra environment here. That's further down my to do list. Someday soon...

Craig

[sfatula]

I update to both mythv 0.28 (first) and then macOS Sierra.

I believe when you update to Sierra, you have to reinstall Macports, and, the ports. https://trac.macports.org/wiki/Migration

Did you really do what you said, i.e. updated on non Sierra, then, put on Sierra and did not rebuild?

[gsulshski]

I update to both mythv 0.28 (first) and then macOS Sierra.

I believe when you update to Sierra, you have to reinstall Macports, and, the ports. https://trac.macports.org/wiki/Migration

Did you really do what you said, i.e. updated on non Sierra, then, put on Sierra and did not rebuild?

Great question !

Interesting that I was thinking of this very thing this morning and did the macports migration on my iMac (myth front end only) to make sure that the rebuild of all of the ports would work.
I got numerous errors/warning for certain ports (for example mythtv 0.27 failed (but I don't want this version) and mythv 0.28 worked)

I did not reinstall Macports and then rebuild all of the ports as stated above but just updated to Sierra after I did the ports build under El Capitan.

So, the question, do I leave my mac mini (mythtv backend) "as is" and wait for macports to stabilize under MacOS Sierra, or do I migrate my ports now along with Mythtv 0.28 ?

[pvr4me]

Interesting that I was thinking of this very thing this morning and did the macports migration on my iMac (myth front end only) to make sure that the rebuild of all of the ports would work.
I got numerous errors/warning for certain ports (for example mythtv 0.27 failed (but I don't want this version) and mythv 0.28 worked)

I did not reinstall Macports and then rebuild all of the ports as stated above but just updated to Sierra after I did the ports build under El Capitan.

So, the question, do I leave my mac mini (mythtv backend) "as is" and wait for macports to stabilize under MacOS Sierra, or do I migrate my ports now along with Mythtv 0.28 ?

With every major OS update, there are always a few glitches. You can check the current status of bugs reported to MacPorts that are believed to be related to Sierra at:

https://trac.macports.org/query?status= ... r=priority

If you have the information, I would like to know what failed when you tried to install 0.27 on Sierra.

Craig

[sfatula]

I did not reinstall Macports and then rebuild all of the ports as stated above but just updated to Sierra after I did the ports build under El Capitan.

So, the question, do I leave my mac mini (mythtv backend) "as is" and wait for macports to stabilize under MacOS Sierra, or do I migrate my ports now along with Mythtv 0.28 ?

I believe this may be the source of your issues. There's only a few ways to know, and one of them would be if someone else gets myth0.28 to work under Sierra via macports. You could try and test build ALL ports on your Sierra machine without affecting your current install by using a second macports installation, it's pretty easy. See: https://guide.macports.org/chunked/inst ... ports.html you basically use the install from source section (2.2.2.1 only) and then follow 2.2.4 as this then allows say a /opt/testing instead of /opt/local and it does not interfere if you follow the directions.

Some ports may refuse to build that myth requires. Is myth (and required related software) your only port? If there's not too many, wouldn't take too long to build build myth under your new directory and see what happens under Sierra. It's much harder to then try and run it, it is possible, but, there's a lot of manual setup, and a second copy of the database, and all sorts of ins and outs. If it at least builds though, would probably work better than you have now.

Personally, if mythtv is your only issue, I would just rebuild all ports after re-installing macports. If a port fails, it won't remove it, you'll just retain the old version. Or, check your ports vs the list that pvr4me provided and see if any of your installed ports are on that list, keeping in mind that the list may not be complete.

[gsulshski]

Interesting that I was thinking of this very thing this morning and did the macports migration on my iMac (myth front end only) to make sure that the rebuild of all of the ports would work.
I got numerous errors/warning for certain ports (for example mythtv 0.27 failed (but I don't want this version) and mythv 0.28 worked)

I did not reinstall Macports and then rebuild all of the ports as stated above but just updated to Sierra after I did the ports build under El Capitan.

So, the question, do I leave my mac mini (mythtv backend) "as is" and wait for macports to stabilize under MacOS Sierra, or do I migrate my ports now along with Mythtv 0.28 ?

With every major OS update, there are always a few glitches. You can check the current status of bugs reported to MacPorts that are believed to be related to Sierra at:

https://trac.macports.org/query?status= ... r=priority

If you have the information, I would like to know what failed when you tried to install 0.27 on Sierra.



Craig

I will do this manually for the time being ..on what failed with mythtv-core.27

Not sure if mythtv-core.27 is dependent on qt5-qtwebkit but this port is no longer supported

for mythtv-core.27 specifically.

p5.22-io-socket-ssl@2.38.0_0 failed to install


When I have time, I can look through the terminal and see what other ports had problems and give you more info.



It points to a log file

[pvr4me]

I will do this manually for the time being ..on what failed with mythtv-core.27

Not sure if mythtv-core.27 is dependent on qt5-qtwebkit but this port is no longer supported

for mythtv-core.27 specifically.

p5.22-io-socket-ssl@2.38.0_0 failed to install

When I have time, I can look through the terminal and see what other ports had problems and give you more info.

It points to a log file

Myth 0.27 requires Qt4; Myth 0.28 needs Qt5.

p5.22-io-socket-ssl was updated to 2.38 a couple of weeks ago. There is no bug filed against it currently. Once a while, odd things happen. It is always worthwhile to clean and re-try:

Code: Select all

sudo port clean p5.22-io-socket-ssl
sudo port install <whatever-you-wanted-to-install>

If it fails the same way again, please file a bug and attach the referenced main.log.

Just so you know, the MacPorts project maintains a fleet of buildbots. Every time a change is committed to a port, a build is attempted on every Mac OS version from 10.5 to 10.12. If there is a failure, the committer is supposed to be notified. However, a couple of weeks ago, there were a number of changes going on with the buildbots and notifications were turned off for a while. Perhaps a build error snuck in and wasn't reported.

https://build.macports.org

Craig

[gsulshski]

Greetings,

I was having difficulty running the migration process

Code: Select all

https://trac.macports.org/wiki/Migration

so I decided to build from a clean ports perspective.

1) sudo port -f uninstall installed
2) sudo port install mythtv-core.28 +mariadb+mariadb55+python27+perl5_24

I looped through 1 & 2 above and I got the following error:

Code: Select all

:msg:archivefetch --->  Fetching archive for mythtv-core.28
:debug:archivefetch Executing proc-pre-org.macports.archivefetch-archivefetch-0
:debug:archivefetch Active variants check for archivefetch-type install considers depends_lib depends_run: qt5-qtbase bzip2 exiv2 libass libbluray libcdio libdvdcss libiconv libxml2 fftw-3 freetype lame openssl faac x264 x265 qt5-mysql-plugin qt5-qtscript qt5-qtwebkit taglib zlib py27-mysql py27-lxml py27-urlgrabber p5.24-dbd-mysql p5.24-http-request-ascgi p5.24-lwp-useragent-determined p5.24-io-socket-inet6 p5.24-datemanip p5.24-net-upnp logrotate
:debug:archivefetch qt5-mysql-plugin is installed with the following variants: +mariadb55
:debug:archivefetch   required: mariadb55, forbidden: mysql56
:debug:archivefetch   accepted
:debug:archivefetch p5.24-dbd-mysql is installed with the following variants: +mariadb
:debug:archivefetch   required: mariadb, forbidden: mariadb10_0 mariadb10_1 mysql4 mysql5 mysql51 mysql55 mysql56 mysql57 percona
:debug:archivefetch   accepted
:debug:archivefetch py27-mysql is installed with the following variants: +mariadb55
:debug:archivefetch   required: mariadb55, forbidden: mysql4 mysql51 mysql55 mysql56 percona55
:debug:archivefetch   accepted
:debug:archivefetch logrotate is installed with the following variants: +gzip
:debug:archivefetch   required: startupitem, forbidden: 
:debug:archivefetch   rejected, because required variant startupitem is missing
:error:archivefetch org.macports.archivefetch for port mythtv-core.28 returned: logrotate must be installed with +startupitem.
:debug:archivefetch Error code: NONE
:debug:archivefetch Backtrace: logrotate must be installed with +startupitem.

I tried a workaround ..

1) sudo port clean logrotate
2) sudo port install logrotate +gzip+startupitem
I noticed that it had a broken link but was able to build

3) sudo port install mythtv-core.28

This went through the build process unsuccessfully

Code: Select all

Error: org.macports.destroot for port mythtv-core.28 returned: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/objdump: '/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_multimedia_mythtv.28/mythtv-core.28/work/destroot/opt/local/bin/mythwikiscripts': The file was not recognized as a valid object file.
fatal error: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/otool: internal objdump command failed
Please see the log file for port mythtv-core.28 for details:
    /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_multimedia_mythtv.28/mythtv-core.28/main.log
To report a bug, follow the instructions in the guide:
    http://guide.macports.org/#project.tickets

Any ideas?

I was able to build mythtv 0.28 on my iMac through the migration process (but had problems with unrelated ports that I just cleaned up manually) but I can't seem to build from a clean ports perspective on my mac mini.