Anyone seen this error? Seems to be happening when movies are being loaded? Included one regular log and just ran it again with a trace in Docker
#Attribute name must be string, not 'Movie'
raw aspen
broken ridgeBOT
Welcome @raw aspen!
Thanks for being a Kometa Sponsor, we greatly appreciate it! Your ticket will now be diverted to <@&1097919568334311495> and <@&938443185347244033>.
Including meta.log from the beginning is a huge help. Type !logs for more information.
After attaching your log, do not forget to hit the green check boxes when prompted by our bot.
You can press the "Close Post" button above or type /close at any time to close this post.
broken ridgeBOT
You can press the "Close Post" button above or type `/close` at any time to clos...
untold tree
Is this unRaid by chance?
raw aspen
Is this unRaid by chance?
Negative, I did see the thread with this issue before that you where commenting on
Just started a few days ago, I re ran this AM with nightly and trace but same
x86_64 Linux 6.8.0-49-generic
Ubuntu 24.04 noble
Docker version 28.0.1
untold tree
Is it always at the same spot?
raw aspen
No, its at random points but l think. Not 100% becasue not everything runs daily but looks to be diffrent
raw aspen
Is it always at the same spot?
Any thoughts? Or think of anyone else who may know a direction? I deleted the cache last night and re ran just to see. Same result
nocturne slate
Did you do the plex database maintenance? Refresh metadata, clean bundles, optimize?
grave night
The problem here is that there is no clear reason why this would happen, AND it's happening outside Kometa.
| Traceback (most recent call last): |
| File "/modules/overlays.py", line 592, in compile_overlays |
| builder.filter_and_save_items(builder.gather_ids(method, value)) |
| File "/modules/builder.py", line 2447, in filter_and_save_items |
| if item not in self.found_items: |
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ |
That's the last piece of Kometa code. Boring, happens with most likely every collection processed.
Now we're in the PlexAPI library, trying to get the key for the thing for some comparison, again boring stuff that happens regularly.
| File "/usr/local/lib/python3.11/site-packages/plexapi/base.py", line 545, in __eq__ |
| return self.key == other.key |
| ^^^^^^^^ |
Except this time:
attr should be a string, the name of an attribute, but in this case it's a Movie object. How in the world did that thing get a Movie object assigned to it?
What code is it that makes that mistake?
| File "/usr/local/lib/python3.11/site-packages/plexapi/base.py", line 556, in __getattribute__ |
| value = super(PlexPartialObject, self).__getattribute__(attr) |
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ |
| TypeError: attribute name must be string, not 'Movie' |
| |
| Unknown Error: attribute name must be string, not 'Movie' |
If this were happening to me, I'd be either setting breakpoints and stepping through this, OR I'd festoon this code path with logging reporting what all these things are throughout.
It only seems to happen in the wild, though, and is not generally reproducible.
raw aspen
The problem here is that there is no clear reason why this would happen, AND it'...
Yeah, im scratching my head a little with this. I looked in the Verbose PMS server logs and theres nothing glaring going on at the same time. I tried commenting out the movies all together and I get the same trip up with "Episodes" instead
tough orbit
Yeah, im scratching my head a little with this. I looked in the Verbose PMS serv...
I'm the OP of the other thread that had this issue on unraid. In my case, unraid had nothing to do with it, end of the day it's running on a Linux kernel and using docker within that context.
My problem ended up being a faulty CPU. Notably, I had one of the notorious 14th Gen Intels, and looks like I was hit by that degredation.
Are you using a 13th or 14th gen intel CPU? Did you install it before intel released the BIOS microcode to "fix" it?
Check your syslogs for segfaults or other weird errors and trace messages.
If you have another computer/laptop you can install Kometa on, try that. That'll help you determine if it's a server specific problem, or something to do with your Plex / Kometa setup.
raw aspen
I'm the OP of the other thread that had this issue on unraid. In my case, unraid...
Thanks for the info, ill have to dig into it then. I have the 13th Gen Intel Core i9-14900K @ 32x 5.7GHz, I got it probably 6 months ago and it still has the stock bios.
tough orbit
Thanks for the info, ill have to dig into it then. I have the 13th Gen Intel Cor...
Ah yeah, without knowing anything else, I'd probably say the CPU is a likely candidate for the problems then.
How I narrowed it down was by looking in the syslogs and correlating those with when Kometa would crash. The weird thing is that the segfaults did NOT happen when I got the "attribute must be string" errors.
But there were some times that Kometa would just stop in the middle of a run. No error or anything, just stops mid run for seemingly no reason. Those produced segfaults in the syslog at the same time.
Looking at the segfaults I was able to narrow down a few cores that were problematic, so then I pegged those cores to Kometa, and it would either error or crash/segfault every time.
If it does end up being the CPU, make sure to update the BIOS before you install the new CPU.
untold tree
Thanks for the info, ill have to dig into it then. I have the 13th Gen Intel Cor...
Can this be closed?