Mythweb blank page. No error msg. invalid "skin_url", and empty javascript vars

[dreamcat4 <dreamcat4@…>]

Hi, I've been trying to get mythweb working, and am using your nginx configuration file. From MythTV#8

Have you ever seen this problem with mythweb?

Blank Page: ​https://bbs.archlinux.org/viewtopic.php?id=171645 http://www.mythtv.org/pipermail/mythtv-users/2013-August/352352.html

This is exactly my problem today: ​https://gist.github.com/dreamcat4/31edb92e0b6f08c62cef

It seems like nginx and php-fpm are working OK. Because when I insert some intentional error in the main "myth web.php" file, it will appear in the direct html output, and also the correct error msg the error logs. So whatever the problem is… it seems to be something in mythweb itself. Yet mythweb's .php code is not printing any error messages whatsoever. It seem to be a very bad application in such respect.

The guys on IRC said "use apache instead because that what everyone uses for running mythweb". However after agreeing to try that, using apache seemed just hugely complicated. Many errors. And every web page consulted for help was yet another different but hugely complex-looking way to 'get php working'. My idea of hell. To difficult to understand.

Unfortunately the FreeBSD port does not include working apache configuration in respect to php. And will serve the .php files as txt.

I have previously used nginx+php-fpm to run other php frontends for zabbix and virtualbox on FreeBSD. They have always worked fine. And with simpler config than Apache.

Also tried using the master branch of 'mythweb' files on github. Same problem still (blank page). It is no different.

Any help appreciated. Kind Regards.

[Rob Smith]

It appears that the skin_url define is not being set correctly. Hence why you have urls like src="skin_urlimg/mythtv-logo.png"

This is controlled by the code at: ​https://github.com/MythTV/mythweb/blob/master/includes/skin.php

As for why it's not working. I honestly have no idea. You can try setting ?RESET_SKIN on your urls and see if that helps.

[dreamcat4 <dreamcat4@…>]

I tried doing:

​http://192.168.1.219/?RESET_TMPL=yes Didn't work

​http://192.168.1.219/?RESET_SKIN=yes Didn't work

Before being suggested that, I also tried hand-editing the file "included/skin.php" to ensure the variable was being forced set. And now we define the paths

$tmpl = 'default'; $skin = 'default';

Didn't work

[dreamcat4 <dreamcat4@…>]

I'm not the only individual who has had this same problem.

17:43] < sji> i am trying to install mythweb. I followed the instructions on ​https://github.com/MythTV/mythweb/blob/master/INSTALL. But it still does not work for me. I am using fedora

20. When i go to webpage, localhost all i see is a link on a white page. The link is called "MythTV" and it is linked back to localhost. So what am i doing wrong?

17:49] < sji> I am suing firefox 30, so when i pick the menu "source", it brings up a new window and shows me lots of text, aome of thew text says "<link rel="icon"

href="skin_urlimg/favicon.ico" type="image/x-icon">"

Which he installed on an entirely different platform than me (and with apache, not nginx):

​https://gist.github.com/anonymous/e1112682cfdd8084d001

[dreamcat4 <dreamcat4@…>]

At last, some small progress from expert on #php irc channel:

[21:10] < dreamcat4> Bittarman: so then why does it work for other people ? [21:10] < Bittarman> dreamcat4, it doesnt... [21:10] < Bittarman> unless its defined as a constant somewhere [21:11] < dreamcat4> Bittarman: yes it is: ​https://github.com/MythTV/mythweb/blob/master/includes/skin.php#L53 [21:13] < Bittarman> dreamcat4, that file was not included then [21:14] < dreamcat4> thanks Bittarman !

[dreamcat4 <dreamcat4@…>]

So from that we can conclude that "includes/skin.php" probably, or almost definitely isn't being included.

[dreamcat4 <dreamcat4@…>]

Right. Some more progress.

• First, cd www/mythweb/includes

• When I "corrupt" or mess up the file "init.php", an error shows.
• Therefore, the file "init.php" is definitely being executed.

• When I "corrupt" or mess a file included by "init.php", an error shows.
• Therefore, the included files is definitely being executed too.

BUT NOT

• By the time we get to line 65 of init.php, when "skin.php" is included:
• When I "corrupt" or mess up the file inside "init.php" again (at line 65), an error shows.
• Therefore, the file "init.php" itself is definitely STILL being executed, and execution hasn't quit.
• However skin.php isn't being executed.

Tracking back we find that the last known file to work properly is:

Make sure the database is up to date

require_once 'includes/db_update.php';

Therefore it looks like something may be happening inside there. It is affecting what happens afterwards. In particular to be changing the behaviour of php's "require_once()" function.

[dreamcat4 <dreamcat4@…>]

If i comment out this line in init.php

require_once 'includes/db_update.php';

Then execution gets into the next file on the init list, "session.php".

If i don't change that line, but instead change: "require_once session.php" --> "require session.php".

Then is executed too.

[dreamcat4 <dreamcat4@…>]

Replying to dreamcat4 <dreamcat4@…>:

If i comment out this line in init.php

require_once 'includes/db_update.php';

Then execution gets into the next file on the init list, "session.php".

If i don't change that line, but instead change: "require_once session.php" --> "require session.php".

Correction. Then session.php still ISNT executed.

[dreamcat4 <dreamcat4@…>]

Excerpt From:

http://www.mythtv.org/pipermail/mythtv-users/2010-November/303559.html

Using the echo idea, I found that the module named db_update.php checks the db schema and tries to update it if it is less than 2.

setting('WebPrefer_Channum', null, 1); setting('WebDBSchemaVer', null, ++$db_vers);

For whatever reason, it was not able to update the WebDBSchemaVer to 2 and that was the problem. I manually updated the db (don't shoot me) and now MythWeb appears to be working.

This sounds like it may be the same problem / issue. IMHO (if that is the cause here). Then Mythweb should probably raise an assertion or error message if such a failure is detected.

[dreamcat4 <dreamcat4@…>]

Looks like you guys were told about this in 2010 but failed to make the right kind of fixing:

​https://code.mythtv.org/trac/ticket/8632

"WebDBSchemaVer was missing from the settings table and MythWeb returned a completely blank page in the browser. No meaningful error message was logged. db_update.php doesn't appear to test for the presence of the variable, nor log an error if it is missing."

[dreamcat4 <dreamcat4@…>]

And here are some (fewer) people who were fortunate enough to find the error. And know that they had to hack this:

==========================

​http://www.gossamer-threads.com/lists/mythtv/users/554218

When you go to the mythweb website you will get an error about the db version being newer. I dont recall the exact error but -MY- fix, which is of the brute force method was to edit the file in question and tell it to expect the newer version (4)

vi /var/www/html/mythweb/includes/db_update.php define('WebDBSchemaVer', 4);

Not elegant in any stretch and it could be breaking all kinds of other stuff behind the scenes but I have a now working system. Without a frontend I rely on mythweb to do my scheduling so it was worth the risk

version incompatibility error described above. While the work-around patch to /var/www/html/mythweb/includes/db_update.php shown above worked, I was uneasy about doing that since I had no idea what else may have been changed in the database by mythweb 0.27. Consequently, I restored the database from a backup copy and now everything seems to be OK.

========================== ​http://www.gossamer-threads.com/lists/atrpms/users/16952

However, after a few iterations, I located a parameter within database table "settings" named "WebDBSchemaVer". I changed this from 4 to 3, and so far it works. But I guess this is not the only thing, that has changed in the DB, so I wouldnt recommend other to try it without having a deeper insight, than I have.

/Kenneth

Kenneth:

I had the same problem a few months ago. I think I only modified db_update.php after the downgrade to get mythweb working again. I've included the changes to my db_update file below.

db_update.php:

define('WebDBSchemaVer', 4)

Grant

===========================

[dreamcat4 <dreamcat4@…>]

In db_update.php, when I add this line:

What version does the database think it is?

$db_vers = intval(setting('WebDBSchemaVer')); $db_vers = 4; <---------- THIS LINE if ($db_vers < 0)

$db_vers = 0;

The main page will load and look "OK".

When I remove that line again, we are back to the blank page again.

When I "echo($db_vers);" the output value is "3".

So my conclusion the buggy code occur somewhere in CASE 3 of the switch statement:

case 3:

setting('recommend_enabled', null, false); setting('recommend_server', null, '​http://myth-recommendations.aws.af.cm/'); setting('recommend_key', null, 'REQUIRED');

setting('WebDBSchemaVer', null, ++$db_vers, false);

[dreamcat4 <dreamcat4@…>]

This error may be reproduced in WORKING installations, by temporarily adding the line:

What version does the database think it is?

$db_vers = intval(setting('WebDBSchemaVer')); $db_vers = 3; <---------- THIS LINE if ($db_vers < 0)

And commenting out the last line of case 3 here:

case 3:

setting('recommend_enabled', null, false); setting('recommend_server', null, '​http://myth-recommendations.aws.af.cm/'); setting('recommend_key', null, 'REQUIRED');

setting('WebDBSchemaVer', null, ++$db_vers, false);

[dreamcat4 <dreamcat4@…>]

Replying to dreamcat4 <dreamcat4@…>:

And commenting out the last line of case 3 here: \/\/ setting('WebDBSchemaVer', null, ++$db_vers, false);

[dreamcat4 <dreamcat4@…>]

Problem found: mythbackend wasn't running.

We need a basic error check for that, and to print message before "includes/db_update.php" is executed.

[09:38] < stuarta> might help ;-) [09:39] < dreamcat4> stuarta: OK, it worked! so that tells a lot [09:39] < dreamcat4> if a patch to error out, it should check if mythbackend service is running and quit [09:44] < stuarta> i thought that was already in there. maybe not [09:44] < stuarta> with mythweb, it'll need to try to talk to the backend, with a quick timeout, and then present a nice error message [09:45] < stuarta> but i though it already did. maybe not a nice message bit it did present something [09:47] < dreamcat4> stuarta: i saw such an error message like "backend not running" or something BUT [09:48] < dreamcat4> the message comes too late in execution. you only see it if have already hacked the db_ver from 3 -> 4 [09:50] < dreamcat4> i think we need it to perform the test earlier, before the problem code is run, and print out a worning as a more basic PHP exception [09:50] < dreamcat4> since the skins / template haven't been loaded yet

[Rob Smith]

Should be fixed in master now.