id summary reporter owner description type status priority milestone component version severity resolution keywords cc mlocked 10787 0.25 MythWeb on OS X broken karog JYA "This is in reference to #10600 which got inexplicably locked. See it for the symptoms of MythWeb failing miserably on OS X. I have developed a patch as described below which I tried to comment in #10600 but could not. Not sure why this was Priority: minor and Severity: medium since it totally breaks mythweb on OS X. Nonetheless, there are two problems here, both related to moving the bindings files into mythtv. The first is that on linux, the bindings files were moved into /usr/share/mythtv/bindings/php. This path as well as /usr/local/share/mythtv/bindings/php are added into include_path in mythweb.php so that they may be found. But this fails on OS X as the files are only included in various MythTV application bundles like MythFrontend.app. This problem can be fixed by the end user doing: {{{ cd /usr/local/share mkdir mythtv cd mythtv ln -s /path-to/MythFrontend.app/Contents/Resources/share/mythtv/bindings bindings }}} where /path-to/ is appropriately set. This solves the problem of finding the bindings files. The second problem of all the fatal errors is because of the changes to includes/class_autoload.php to also search include_path in order to account for the above paths. The prior code used to look for classes in the '''classes''' dir and then various other '''classes''' dirs inside of other specific dirs relating to the current module. This new section of search code was inserted after seaching '''classes''' and before searching the others '''classes''' subdirs. As a consequence, when trying to load something like Channel.php (note the upper case C) for the url /MythWeb/tv/list which should be found in /MythWeb/modules/tv/classes, instead channel.php (note lower case c) in /MythWeb/modules/tv gets incorrectly loaded since that path is the current module path for /tv/list and gets automatically put on include_path. And that is searched before the correct file would be found in the subsequent searches of subsidiary '''classes''' dirs. OS X has a case independent file system whereas linux is case dependent so that is why this fails on OS X and not linux. I do not know why this new search component was inserted in the middle of the multiple paths it used to search. But I tried moving this new search part below all the older searches and this seemed to fix the problem. I have attached a patch file for consideration. The probematic changes are about 17 months old. I have been running MythWeb on OS X for 0.24 for a long time and never had the need to update it. When I switched to 0.25 recently, I got the newer MythWeb and that is when I noticed the problems. But they have been around for a long time." Patch - Bug Fix closed minor unknown Ports - OSX 0.25-fixes medium Duplicate OSX MythWeb 0