Server Version#: 1.32.8.7639
Player Version#: ANY
Previously if you did a search and there was an alt title in the Original Title field, the title was searchable and could be found… however, now, Original Titles are ignored, the only way to get an alt title to be searchable is to put it at the end of the Sort Title field. Defeats the purpose of the Original Title field.
Have you tried optimizing your database, which should rebuild search indexes? Or restarting PMS? I’m running a slightly newer server version (1.40.0.7775), but have no issues searching by original title, and haven’t on previous versions:
Database is optimized, plus it’s part of my Scheduled Tasks which is done weekly… PMS is restarted daily. This is a recent thing. I used to be able to as well. The basics aren’t solutions.
The basics are where you start when someone doesn’t explain what they’ve tried to resolve the problem so far. You never said exactly when it started, so it could have began since the last scheduled maintenance.
Do your server logs show any warnings/errors around the time you initiate the search (the line will contain GET /hubs/search?query=)?
After enabling EnableDatabaseTrace in preferences.xml (or the registry on Windows), I’m seeing the following query being run against my database, which returns the expected movie id based on its original title:
select distinct metadata_items.id from metadata_items
join fts4_metadata_titles_icu on metadata_items.id=fts4_metadata_titles_icu.rowid
left join media_items on media_items.metadata_item_id=metadata_items.id
left join media_parts on media_parts.media_item_id=media_items.id
where
fts4_metadata_titles_icu.title match 'Cidade* De* Deus*' and
metadata_items.library_section_id in (2) and
metadata_items.metadata_type=1
order by metadata_items.title_sort collate icu_root asc, metadata_items.originally_available_at asc, metadata_items.id asc limit 100;
As one potential test, if you run the above query, modified for your specific search query and library section id, against your database using Plex SQLite, does it come back with any results? If not, it’s definitely seems like something is wrong with the database/your search indexes that optimization isn’t fixing.
I appreciate you taking the time to detail what steps I can take to identify what it might be. Unfortunately, I’m too busy to do all of that. That’s why I’m seeking tech support, That way they can request specifics from me and I can provide those logs. Then I’m not going a on wild goose chase. But again, thank you for taking the time, that might identify a problem or it might not. And that’s the issue. That’s why Plex has employees who can look at logs and determine the issue.
These forums are community based. While I can understand you wanting direct employee support, that’s not a guarantee. I hope you can understand my point of view here - a user asks a question on community forums, and after engaging with a community member who is willing to help, says they’re only looking for direct help from an employee, doesn’t supply their server logs, and says they don’t want to be led on a wild goose chase. I can again understand not wanting to post your logs for any random person to see (and especially being unwilling to run queries against your database provided by some guy on the internet), but there’s not a legion of Plex employees ready to answer support questions - most employees who post here are probably spending their spare cycles looking at posts, and being unwilling to troubleshoot with anyone but an employee is antithetical to the spirit of these forums.
As I said multiple times, I’m so appreciative of the effort. I simply do not have the time to chase a problem that’s simply an exercise in possibly identifying the problem without a solution.
I’m stating a problem I can reproduce. And you are correct, I am not willing to post my logs in a public forum. I’m vague because I don’t know exactly when it started. I’ve seen this problem years ago, it was fixed, then broke again, then fixed and now it’s broken again. So I can’t pinpoint when it started this time. My updates are set on automatic so I rarely know when there’s been an update to know if I’m on one side of the problem or the other.
I’ve also been down many roads with support and understand that many times the logs do not show the information they need. That’s the reason I don’t go on wild goose chases. I need to know the specific things they need. Not me wandering around in the dark with a flashlight.
If you understood how many times I’ve hit that wall with Plex Support you would understand my refusal to chase anything anymore. I will troubleshoot everything I can, but when it comes to the code, I don’t believe that’s on me to dig around.
Please know, I really appreciate the time you took to explain how this works, tho I’m fully aware. I would just like search to work as it was. If a Plex employee has the time to look at a log I can send via DM, that would be great. If not, the Sort Title field works in its place. So there’s a workaround.
A follow up with more detail…
If I add a new file, do not touch the Original Title field and there’s an original title there, and I search it, it will find that title. if I edit the title, or even just lock the field, the Original Title is no longer searchable.
For Example, there’s a film called Tomorrow at Dawn… the Original Title is Demain dès l’aube… When I did a search for Demain dès l’aube it showed up… I edited the Original Title, simply by hitting the lock button. It was then no longer searchable. Refresh, analyze, nothing worked to bring back the search of the Original Title.
This partially explains why this has been so intermittent over the years. It only happens if the Original Title field is edited.
I can partially confirm that behavior, but for me, optimizing the database fixes everything, regardless of whether the original title has been locked or edited. I did the following tests:
| Action | Search Result |
|---|---|
| Untouched original title | Success |
| Lock unmodified original title field | Failure |
| Lock modified original title field | Failure |
| Change original title, but keep unlocked | Failure |
| Unlock unmodified original title field after locking it | Failure |
| Unlock modified original title field after locking it | Failure |
| Optimize database after locking unmodified original title | Success |
| Optimize database after locking modified original title | Success |
| Optimize database after modifying unlocked original title | Success |
| Optimize database after locking and then unlocking unmodified original title | Success |
| Optimize database after locking and then unlocking modified original title | Success |
So there’s definitely a general issue with searching for locked original titles, but for you, optimizing the database doesn’t resolve it, while it does for me.
Thank you for taking the time to confirm that. Something deeper is going on that’s triggering this in the first place.
Looking at things on my end, I’m wondering if the size of my library (600TB) has anything to do with optimizing the database not correcting this. I know my scheduled tasks have been in a backlog that it’s been catching up on every night ever since I moved everything to new servers, and that could be preventing these from fixing.
But I’ve manually run Optimize Database and it still wasn’t correcting like yours did. And if it gets triggered by editing the Original Title field, it’ll just keep repeating.
Hoping a staffer can send this info to the devs so they can reproduce it on their end and see if they can fix what’s triggering it.
Bump… I need a staff member to troubleshoot this on their end since it’s reproducible.
There is an open issue for this with the development team
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.
