Hi guys,
Search is not working on OS X. Both, the PMS and OpenPHT are on the same machine, the files are stored on a NAS. It works on PlexWeb and iOS. Any suggestions to fix it?
@yegor:
That’s strange. It works fine for me in OSX Yosemite, where I tested it right now.
It should not matter where in your LAN the files are stored, as long as they are accessible to your PMS server as file shares from the storage device/computer. It also should not matter on which machine the OpenPHT client is running, as the search is made through PMS server interactions anyway.
I started my test by launching VMware workstation on my Win7 PC (which also runs PMS), and starting a virtual machine running OSX Yosemite, wherein I then launched OpenPHT 1.5.0. I then selected the “Search” command in OpenPHT’s main menu, which opened its search page, initially with the right-hand part of the screen blank. I then typed the word “JERK”, which soon resulted in various search results in the previously blank screen part. At the top I had “Movies” results, showing just the Steve Martin movie “The Jerk”, below that was a row of “Episodes” results such as Cheers s7e8 “Jumping Jerks” and others from other shows, and in the bottom section I had results from “Channels” including several videos from “Fox News” presumably with the word “jerk” somewhere in the episode title or description (though I couldn’t see it in some of the abbreviated titles).
This kind of search has ‘incremental’ result updates, so the results displayed are likely to vary as you type more characters into your search string (or when you delete some). And entering any character which makes the search string into something having no match in your library or channels will of course blank out all results, so that the right-hand screen section is as empty as before typing anything.
I should add that the results for this OpenPHT session under Yosemite are identical to the results I get when making a similar test in the Windows version of OpenPHT running natively on the same Win7 system as PMS, or on another Win7 system in my LAN.
Please describe your own test and its results in greater detail.
At present we have very little idea of what happens when you try it.
For all we know it could be anything, ranging from text entry problems to complete system crash !?!
Best regards: dlanor
When I type “boardwalk”, for instance, I see all the available results on all other clients I have, except the OpenPHT – It is just blank, with absolutely no activity. I tried signing out, deleting the device from PlexWeb, signing back – nothing works.
I don’t know what else to describe: it just doesn’t work, no results, nothing, doesn’t matter what I type. I understand what you are referring to, but this doesn’t have anything to do with scenarios you are describing.
I remember this happened before on PHT: deleted some kind of preference file, restarted the App, and it started working.
Thanks for following up, dilator!
@yegor said:
When I type “boardwalk”, for instance, I see all the available results on all other clients I have, except the OpenPHT – It is just blank, with absolutely no activity. I tried signing out, deleting the device from PlexWeb, signing back – nothing works.
So you are typing the words straight into the search text box of PHT and it doesn’t respond at all even if you wait for half a minute or so… And it’s the same regardless of what search text you type. Right ?
That’s very odd, and something I can not replicate here (not yet anyway).
For me it just works, and this is the same on all the platforms where I use OpenPHT or RasPlex (the same program for Raspberry Pi). So that includes emulated OSX and native Win7 plus RasPlex on both RPi1 and RPi2 models.
I remember this happened before on PHT: deleted some kind of preference file, restarted the App, and it started working.
I hope you can remember which file that was, so we can try to figure out what happens that causes this error.
One file you can try it with is the “guisettings.xml” file that is stored in the “userdata” subfolder inside the main appdata folder of OpenPHT. You should find that file in your system stored as:
“~/Library/Application Support/OpenPHT/userdata/guisettings.xml”
I find it easiest to use the “Go to folder…” command of ‘Finder’ with the path string “~/Library/Application Support/OpenPHT/” in order to access the contents of OpenPHT’s appdata folder, whether to tweak some settings (below “userdata/”) or add some skin folders (below “addons/”).
The “guisettings.xml” file controls most things having to do with GUI interactions of the program as well as some other stuff.
So you should be aware that if you do delete this file, then you will have to reconfigure OpenPHT from scratch the next time you launch it, as it will behave as if that was the first launch since installation.
(And restoring a backup of that file after a test will probably not work, due to invalidated tokens…)
Thanks for following up, dilator!
You’re welcome, but my username is “dlanor” not “dilator”
(auto-correct… ? 
)
Btw: I just realized that we haven’t discussed possible ‘skin’ issues.
Please verify if you are using the default “Plex” skin or some custom skin for the program.
(Either way, it will default to the “Plex” skin if you delete the “guisettings.xml” file.)
Best regards: dlanor
Hi dlanor, and yes, your username was autocorrected 
I just deleted the guisesettings.xml, restarted the app… it still isn’t working. Everything is default, no skins, nothing extra.
I launched and checked the official PHT: the search works perfectly, displays the results instantly.
There is definitely a bug in OpnPHT.
Thanks again for providing your time!
Searching with OpenPHT on OSX Mavericks works here (files are stored on NAS and share is mounted on Mac Mini via AFP). You can see the files in browse mode but search just turns up nothing? Weird
This is very strange indeed, as the search works fine for me in OpenPHT under emulated OSX Yosemite.
But I guess I should test it under OSX Mavericks as well… (I do have such a virtual machine too)
----- Some tests later -----
I have now installed OpenPHT 1.5.0 under OSX Mavericks and performed exactly the same tests as before, with exactly the same successful search results. So for me this bug is not visible at all.
I see some possible differencies that may be involved in our getting so different results. One is of course that my tests are done in emulation under VMware (though it’s hard to see why emulation would make it work better).
Another possible difference is that both my Mavericks and Yosemite systems are 64-bit, so I haven’t tested the 32-bit version of OpenPHT for OSX. So if you guys are using the 32-bit version the bug could be specific to it.
A third possible difference is that my library is shared through SMB, not NFS. But since the library is accessed through PMS the physical storage and sharing methods should be resolved by PMS, not by the playback clients.
Best regards: dlanor
@yegor said:
There is definitely a bug in OpnPHT.
Definitely not a bug, ‘Search’ works fine in El Capitan and Yosemite.
Regards
@NedtheNerd said:
Definitely not a bug, ‘Search’ works fine in El Capitan and Yosemite.
Well, I found the reason…
I started by removing the OpenPHT completely and reinstalled from scratch which didn’t make any difference. I then compared the two folders of PHT and OpenPHT within Library/Application Support on my Mac mini and replaced the .db files, one by one, in OpenPHT userdata/Database folder with the exact files from the exact location of PHT folder.
After every replacement, I started the OpenPHT and tried Search. Nothing made difference until I replaced the PlexServerCache4.db. and… it started working perfectly. I then compared the two .db files and found out that the OpenPHT file is missing a chunk of code. I have absolutely no knowledge in all this, thus have no idea why this happens.
I also installed the OpenPHT on my MacBook Pro and the Search worked just fine. Checked the .db file on MBP and found that it actually generated the extra code missing on my Mac mini. I attached the two .db files so you can see what I am referring to (added OpenPHT and PHT to the file names). Both systems are running El Capitan 10.11.2.
Download OpenPHT PlexServerCache4.db here
Download PHT PlexServerCache4.db here
Hope this helps.
@yegor :
I see. So it comes down to a broken database file of OpenPHT used for caching information from the PMS server, which information is apparently crucial to the search operations.
I’m glad you were able to pinpoint the error this way, but I must still agree with @NedtheNerd that this is not due to a definite bug in OpenPHT. If it were, then the new installation you just made should also have suffered from the same problem.
That database error could be due to variations in PMS server behaviour though, which would be all the more likely if you’ve been using any PlexPass-only versions of PMS. Those are really preview beta versions, not released to the public until beta tested by PlexPass members, often resulting in bugfixes for the public releases. (I only use the public releases of PMS myself, despite having lifetime PlexPass membership.)
I strongly suspect that if you had installed official PHT instead of OpenPHT at that time, and used it the same way, it too would have been fed faulty data from PMS, resulting in the same database errors. But hopefully this problem is now behind us (possibly due to server updates, whether manually by you or due to automatic PMS bundle updates from Plex Inc).
Best regards: dlanor
