#Multiple inconsistent errors with "attribute name must be string"

1 messages · Page 1 of 1 (latest)

light isle
#

This one is a doozy, so buckle up. I've been dealing with the problem for several months now. It is extremely inconsistent and has so far been impossible to track down. There is a similar thread to this here: #1277346956041257074 - but none of the info in that has helped me.

When the issue first started happening, nothing changed. I had Kometa running since the PMM days with a config that worked well. I went to bed one night, and then woke up one morning to find the issue. I ran it again manually, assuming it was some weird hiccup, and it seemed to run okay, so I left it. But over the weeks it started to happen more and more. But each time it seemed to be happening in a completely different place in the kometa process, and it wasn't always a not 'Movie' complaint, it was sometimes things like not 'Show' or other variations of that.

The past few weeks it's been unbearable. Kometa is barely working and I get the error every single day. I've tried using the DBRepair script by ChuckPA - it found zero problems with the database. But I ran the reindexing, vacuuming, etc anyway. Still have the issue. Tried doing the manual method the script is based on using Plex SQLite, same results. I made a copy of the database and combed through EVERY table to see if I could spot malformed tables or items, nothing really stood out.

Cut to today/yesterday. I've spent a lot of time trying to track down this issue, but to no avail. So my only choice left was to nuke Plex and rebuild it from scratch. Even after doing that, I looked through a copy of the database again, and this time was brutal with trimming any media content that had anything that looked even remotely out-of-place (even if it was still valid and working in Plex itself) Note: I didn't edit the database itself, I just used the database to look for weird metadata entries and then removed the related media files in Plex.

crude slateBOT
#

Welcome @light isle!

Someone from <@&938443185347244033> will assist when they're available.

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.

crude slateBOT
light isle
#

Then I setup Kometa from scratch again as well following the guide on the wiki, just in case I had any weird configuration problems. All seemed to be working pretty well, but then the issue started up again. I've only been processing Overlays, and only on 1 library (Movies). I started slow, doing the bare minimum, and then added on one thing at a time (removing the overlays in between attempts). I've been doing this for about 6 hours or so now, and I cannot get a consistent result at all.

I'll post the log from my most recent attempt after this message, but it highlights a very weird scenario. The attribute name must be string error pops up when Kometa tries to load the Library items for the gradient_bottom overlay. However, it isn't an issue for the gradient_top nor any of the other overlays. Surely, I would expect that if there is a single item in my database that is causing this issue, then both the top and bottom should fail, as they are both loading ALL items in the movies library (this is confirmed in the log, they both try to load 1384 items).

On this run, in terms of Plex, all the overlays except gradient_bottom were applied just fine.

crude slateBOT
#

📝 If you want to review this again, cglatot:
:one: Right-click (or long press with phone) on the message that contains the log
:two: Select: Copy Message Link
:three: Use the command: /logscan <message_link> or !logscan <message_link> and paste the value copied from the previous step where you see <message_link> 📝

#
**Rec 01** - ❌ **[ERROR]**

❌ [ERROR]
Error messages found in your attached log.
There is a very strong likelihood that Kometa did not complete all of what you wanted. Some [ERROR] lines can be ignored.
For more information on handling these, [https://kometa.wiki/en/latest/kometa/logs/?h=[error]#error]
1 line(s) with [ERROR] messages. Line number(s): 458

Page 6/7
light isle
#

In this example I'm using the overlay templates from jmxd here: https://github.com/jmxd/Kometa
However, the "attribute name must be string" issue happens even with the default builders.
I have also had completely error-free runs of jmxd's files today too. As previously stated, it's very inconsistent.

I've also cleared the kometa cache between some attempts, and left it alone for some attempts. I couldn't find any patterns. I felt like it was working more often after deleting the kometa cache, but not always the case.

#

This is running in Docker in Unraid. I have any other media changing/adding services disabled (sonarr, radarr, ImageMaid, etc) the entire time when testing.

vocal cedar
#

Ty for being so thorough, it's greatly appreciated

#

I'll try and review soon if nobody beats me to it

light isle
#

No worries, I've done my days in tech support, so know how valuable that is. Also how annoying it is that I can't fix this myself 😭

vocal cedar
#

Can you provide any custom YAML files that you're using (if any)

#

Just so we can see the exact file(s) in question easily

#

If you're using jmxd from the repo directly that's fine, if you have local copies can you attach them here

light isle
#

Oh, final piece of relevant info: I tried running --log-requests as well and it didn't really show me anything useful. It seemed to error out mostly when it was getting the entire Library request response, but since that only shows you the size of the response in bytes, and not actual progress, there was no way to tell exactly which item was causing the issue. (But also, the top/bottom gradient inconsistency throws into question if it even is a single media item(s))

Plex itself also never seemed to have any issues, nor any of my other third party tools (Plex Auto Languages, PASTA, Tautulli, etc). Kometa seemed to be the only thing having problems.

Thought of another potentially relevant bit of info: The issue also sometimes happened when all I was doing was removing the overlays. I'll see if I can reproduce that.

light isle
vocal cedar
#

Thanks

light isle
#

LOL you're going to love this one. I went to run a remove_overlays: true test so I could have the library back to default. But I forgot to hit the save button, so technically it ran the exact same test as in the OP. Except this time, gradient_bottom worked perfectly fine. The whole thing worked fine. NOTHING has changed. I didn't touch plex nor kometa, there are no services that would be interfering with either of them. I even used the same console window I had open to manually run the test. I'll post the log of this one below, though I can't really see why it's different.

crude slateBOT
#

📝 If you want to review this again, cglatot:
:one: Right-click (or long press with phone) on the message that contains the log
:two: Select: Copy Message Link
:three: Use the command: /logscan <message_link> or !logscan <message_link> and paste the value copied from the previous step where you see <message_link> 📝

vocal cedar
#

This may be one for the boss @lavish knoll

#

TLDR after loading in ratingkeys for an overlay:

Traceback (most recent call last):                                                             
  File "/modules/overlays.py", line 574, in compile_overlays                                   
    builder.filter_and_save_items(builder.gather_ids(method, value))                           
  File "/modules/builder.py", line 2422, in filter_and_save_items                              
    if item not in self.found_items:                                                           
       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^                                                            
  File "/usr/local/lib/python3.11/site-packages/plexapi/base.py", line 545, in __eq__          
    return self.key == other.key                                                               
                       ^^^^^^^^^                                                               
  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'
#

a subsequent run doesn't have this error, it's appearing inconsistently

#

cglatot, how often would you say this is happening?

light isle
light isle
vocal cedar
#

have you tried running Kometa on nightly on the off-chance this issue doesn't exist there?

light isle
crude slateBOT
#

📝 If you want to review this again, cglatot:
:one: Right-click (or long press with phone) on the message that contains the log
:two: Select: Copy Message Link
:three: Use the command: /logscan <message_link> or !logscan <message_link> and paste the value copied from the previous step where you see <message_link> 📝

light isle
vocal cedar
#

Can't remember if you're on docker, if not remember to update the requirements

#

Back on my phone again so useless ☺️

light isle
light isle
#

Okay, run on nightly build done. Same as before, haven't changed anything else other than updating the docker to nightly.
This time gradient_top and gradient_bottom errored out, but bottom seems to have a longer Traceback. Looks like some of the other media info related overlays failed too.
IMAX-1080p Overlay gave a different error message this time: Unknown Error: sequence item 0: expected str instance, NoneType found - but the Traceback makes it look like it's of the same origin as the others.

crude slateBOT
#

📝 If you want to review this again, cglatot:
:one: Right-click (or long press with phone) on the message that contains the log
:two: Select: Copy Message Link
:three: Use the command: /logscan <message_link> or !logscan <message_link> and paste the value copied from the previous step where you see <message_link> 📝

light isle
#

Did a second run on the nightly build. Once again, literally nothing different. Different result again. This time, back to gradient_bottom being the only problem.

crude slateBOT
#

📝 If you want to review this again, cglatot:
:one: Right-click (or long press with phone) on the message that contains the log
:two: Select: Copy Message Link
:three: Use the command: /logscan <message_link> or !logscan <message_link> and paste the value copied from the previous step where you see <message_link> 📝

vocal cedar
#

Thanks, I'll wait for Sohjiro or someone else to chime in as I'm not sure what to suggest at this point

light isle
#

I tried a remove_overlays run in the nightly build and it errored. Won't bother posting the whole log as it's the same as every other log, will just highlight the errored entry.

📎 message.txt
crude slateBOT
#

📝 If you want to review this again, cglatot:
:one: Right-click (or long press with phone) on the message that contains the log
:two: Select: Copy Message Link
:three: Use the command: /logscan <message_link> or !logscan <message_link> and paste the value copied from the previous step where you see <message_link> 📝

vocal cedar
#

hm

#

can you try removing the webhooks section from your config.yml and running?

#

or comment it out

#

I don't think that's the cause, I just want to confirm

light isle
light isle
# vocal cedar or comment it out

Ran the same as the other tests (adding the overlay) with both the webhooks and notifiarr sections commented out. Multiple failures again. (I killed the process once it started updating the overlays, as the errors are already logged by that point).

vocal cedar
#

can you post that log for me

light isle
crude slateBOT
#

📝 If you want to review this again, cglatot:
:one: Right-click (or long press with phone) on the message that contains the log
:two: Select: Copy Message Link
:three: Use the command: /logscan <message_link> or !logscan <message_link> and paste the value copied from the previous step where you see <message_link> 📝

vocal cedar
#

ty

#

Have you tried removing the cache file?

light isle
#

Yup, it doesn't seem to make much of a difference. I feel like in the long run it made it error a LITTLE less, but not my much - it definitely still errors out. Again, very inconsistent results.

vocal cedar
#

Cheers, just trying to think of anything that could be at play

#

I've just done 5 back-to-back runs on your files with 0 issues on my end

light isle
#

I also said this in the OP, but this doesn't just happen in Movie libraries, it also happens in TV Shows as well. The error and traceback are the same, but the message will say something like attribute name must be string, not 'Episode' and other such things.

#

yeah, there must be something somewhere. But the lack of consistency (even within a single run) makes me question it being a database entry thing. If that was the case, then it should error EVERY time, not just sometimes. And it should affect both gradient top and bottom, not one or the other, or both, or none, as we've seen.

Maybe it's a database lockout thing, or a networking problem? But I can't see any errors in plex nor in my server about failed requests and that. I've been running all my tests with the Plex Console open on live and no errors/warnings/weird entries that I could see.

vocal cedar
#

if you set cache: false in config.yml does the error persist?

light isle
#

At this point, even if there could be better error handling around that section so that it just skips the problem parts and continues with the rest of the items, that would be great. But right now if it fails, it fails for all items in that overlay category. Or at least if the error handling could show WHAT it's failing on, as right now even the log requests doesn't help with that.

light isle
vocal cedar
#

I'm clutching at straws, Sohjiro may not reply until tomorrow or Monday as it's the weekend.

@meager pebble is more versed than I am at understanding the code-base, so he may be able to interpret what's happening at a deeper level than I can, hopefully he can review this when he gets a chance

light isle
#

yeah I'm in no urgent hurry here. about to head off to bed myself soon anyway

vocal cedar
#

I will say that I've never seen something like this that is so wildly inconsistent 😅

light isle
#

I tried messaging the OP of that post, but they've not responded

vocal cedar
#

Okay so this error message has appeared precisely one time before based on message history

light isle
#

yup, that's the thread I linked

vocal cedar
#

oh

#

rofl

light isle
vocal cedar
#

Based on the previous thread (which I should have read earlier...) I doubt cache is going to do anything here

light isle
vocal cedar
#

No worries

#

Perhaps part of the issue with that pondering is that, based on that other thread, it is the name attribute that is returning funky data, so it wouldn't say "Star Wars" is the name of the item causing the problem

#

We could perhaps stick the ratingkey for the item in instead, which is the internal ID plex uses for the item

light isle
#

I had actually considered forking it and seeing if I could do something to narrow things down more, but it's been a while since I got my hands dirty with python 🤣
And given that it traces the error back to the plexapi library, it might need to be that one that needs updated. I guess it depends on where the error gets obfuscated.

meager pebble
# vocal cedar I'm clutching at straws, Sohjiro may not reply until tomorrow or Monday as it's ...

It looks like it's down in the PlexAPI lib.

We're in Kometa code:

|   File "//kometa.py", line 787, in run_libraries
|     library_status[library.name]["Library Overlay Files"] = library.Overlays.run_overlays()
|                                                             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|   File "/modules/overlays.py", line 63, in run_overlays
|     self.remove_overlay(item, item_title, "Overlay", [
|   File "/modules/overlays.py", line 706, in remove_overlay
|     self.library.edit_tags("label", item, remove_tags=[label], do_print=False)

Last bit of Kometa code, a boring request to reload the item which happens all the time:

|   File "/modules/plex.py", line 1257, in edit_tags
|     obj = self.reload(obj)
|           ^^^^^^^^^^^^^^^^

Which hits the networking layer:

|   File "/usr/local/lib/python3.11/site-packages/tenacity/__init__.py", line 336, in wrapped_f
|     return copy(f, *args, **kw)
|            ^^^^^^^^^^^^^^^^^^^^
|   File "/usr/local/lib/python3.11/site-packages/tenacity/__init__.py", line 483, in __call__
|     elif isinstance(do, DoSleep):
|          ^^^^^^^^^^^^^^^^^^^^^^^

And now we're in the PlexAPI library, and attr, which is expected to be a string, is instead a Movie object.

|   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'

Is there anything odd about these libraries? Are they RealDebrid or some other oddball thing?

light isle
meager pebble
#

Real Debrid is some setup where library items in Plex don't actually exist but are backed by torrents or some nonsense. Just wanted to make sure it wasn't something like that.

light isle
light isle
vocal cedar
#

I'm not trying to have slippy shoulders, but the issue is somewhere between Plex and PlexAPI

#

Just trying to understand if there's something we can add in Kometa to at least identify which item(s) is/are being problematic

#

I don't know if it's worth discussing any of this with plexapi team to try and understand more about it, or if it's just a "this is the error, Plex is bad"

#

I want to help in some way but I don't know how I can at this point 😅

light isle
#

it's just so beyond bizarre

vocal cedar
#

Just out of interest, when you say "nuked Plex", is that a fresh database or deleting the existing libraries and adding new ones again?

light isle
#

deleted everything and setup a whole ass new plex. databases, configs, the docker image itself. Everything. Scorched Earth. (only kept the media files themselves)

vocal cedar
#

Good to know 🙂

light isle
#

was painful losing the watch history 🥲

vocal cedar
#

we have scripts for that 😛

light isle
#

I didn't want to taint the DBs

vocal cedar
#

fair

light isle
#

Tautulli still has the history history from its own logs, so I have that at least.

#

Right, I've been at this for like 10 hours today, so I'm off to bed lol.
Thanks for your help @vocal cedar !
@lavish knoll @meager pebble - let me know if there's anything else you want me to try / provide and I can get to that tomorrow/Monday.

vocal cedar
#

No worries, I've kind of reached the end of my technical ability to help you with this one so hopefully one of the other guys can offer some next steps to try and chase this down.

My current train of thought:
If we can update the overlays.py module to output the ratingKey, we could use that to identify which item is causing issue.
Potential next step beyond that would be to take that item into a brand new library on its own and see if the behavior is seen there too

#

If we can isolate this down to a single item and prove that it works and doesn't work during the same run, perhaps there's something we can take to the plexapi guys to see if there's something on their side that can be done beyond a "Plex returned bad info"

light isle
#

Yeah, I don't even mind deleting media files, it's easy enough to get them again. I just don't know which ones are the problems (if even any of them are. Again, that inconsistency within a single run makes me question this a lot)

vocal cedar
#

This is all spoken from a non-coder guy, so I may be making moot points 😄

light isle
meager pebble
#

Feels like log-requests would output a URL with a rating key in it.

vocal cedar
#

Maybe try that next 🙂

#

docker run ....... --log-requests

light isle
vocal cedar
#

I'd suggest doing a find and replace for your Plex URL and Token, those may be exposed as part of a log requests run

light isle
#

log requests wasnt showing any individual metadata ids

vocal cedar
#

We should maybe review a log with that just to rule it out 🙂

light isle
#

it was something along the lines of /library/allentries or something like that

vocal cedar
#

if we can get the exact URL, then we can look at what we do next

light isle
#

I'll do it tomorrow, bed time for now. But I tried earlier and it wasn't helpful

vocal cedar
#

It may be helpful to someone who knows it a bit better 🤞

meager pebble
#

Just a thought since the last error above is editing tags on a single item, so I figured there's be a single request for that item.

light isle
meager pebble
#

The one I commented on

vocal cedar
#

Let's move forward anyway, we can hopefully get a log-requests log tomorrow and then move forward from there

meager pebble
#

Sure

vocal cedar
#

Bed time for me too, I'll keep an eye on this tomorrow 🙂

light isle
crude slateBOT
#

📝 If you want to review this again, cglatot:
:one: Right-click (or long press with phone) on the message that contains the log
:two: Select: Copy Message Link
:three: Use the command: /logscan <message_link> or !logscan <message_link> and paste the value copied from the previous step where you see <message_link> 📝

light isle
# 
[plex.py:1144]              [INFO]     | Processing Plex All Movies                |
[plex.py:606]               [INFO]     | Loading All Movies from Library: Movies       |
[connectionpool.py:544]     [DEBUG]    | http://192.168.1.47:32400 "GET /library/sections/2/all?includeGuids=1&type=1 HTTP/1.1" 200 48355  |
[connectionpool.py:544]     [DEBUG]    | http://192.168.1.47:32400 "GET /library/sections/2/all?includeGuids=1&type=1 HTTP/1.1" 200 49407  |
[overlays.py:624]           [DEBUG]    | Traceback (most recent call last):       |
#

This is consistent with what I was seeing in all the tests earlier when I had trace requests on (before making the OP here)

#

Really off for bed now. Let me know if there's more you want me to test and I can do it tomorrow. Good night!

vocal cedar
#

enter your plex token at the end

#

you should hopefully get an XML file, if you can copy the contents into a file and post it

light isle
#

Ran it through some validators, and having a manual look through now. Don't see any issues with it so far.

light isle
#

Hmmmmmmmmmmmmmm... the plot thickens.
I cloned the nightly github lcoally on my Windows machine (not where Plex is installed - that's on an unraid server in the LAN). The intention was to make edits to plexapi to get more verbose logging, but I was running some tests just to make sure it was all working and reproducing the same errors.
It ain't reproducing any errors.

I did 3 runs with cache: false (remove overlays, add new overlays, update overlays with a minor change).
Then I updated to cache: true, and ran again (exact same as the previous run, just enabled cache).
All worked flawlessly.

I'm doing a run now on both the Movies and TV Shows library, with the overlays I actually want, so maximum complexity out of want I want from Kometa. Will report back once that finishes.

#

Ran flawlessly as well. Hmmmmmmmmmmmmmm. I need to head out, but will do more testing when I return.

light isle
#

I've run several more tests, and I cannot get it to error when running Kometa on my local PC (still connecting to the same Plex instance on my server).
I tried running Kometa on my server again, and failure right away. There is no difference in Plex, there is no difference in the config files, etc (I copied them over from my PC just in case, even though I originally copied them from my server to my PC).
Going to do a few tweaks and test on my server, then going to see if I can try the Docker version on my PC. Because that's the only differentiator I can think of.

#

The latest log from my non-erroring local PC install, in case that sheds any light.

📎 meta.log
crude slateBOT
#

📝 If you want to review this again, cglatot:
:one: Right-click (or long press with phone) on the message that contains the log
:two: Select: Copy Message Link
:three: Use the command: /logscan <message_link> or !logscan <message_link> and paste the value copied from the previous step where you see <message_link> 📝

light isle
#

This really is the most baffling thing.

#

Did another run, and it errored out again, but slightly different this time? It still seems to be an AttributeError, but from a different call.

crude slateBOT
#

📝 If you want to review this again, cglatot:
:one: Right-click (or long press with phone) on the message that contains the log
:two: Select: Copy Message Link
:three: Use the command: /logscan <message_link> or !logscan <message_link> and paste the value copied from the previous step where you see <message_link> 📝

light isle
#

The last call was /library/metadata/19914/posters - both in the trace logs, and looking at the plex console itself. XML result from that attached.

📎 posters.xml
light isle
#

Running on my PC using Docker seems to work fine as well.

#

Final set of tests is to see if I can get the local script running on the server. If that works as well, then it has to be something unique to the Unraid Docker install.

light isle
#

== Results of more testing ==

My setup is: I have a headless server running unraid. Both my Plex and Kometa are running in docker containers. They are both standard setups. Plex is pulled from linuxserver's repo, and Kometa is pulled from Sohjiro's. Plex reads from local media only, there's no freaky mounting / streaming or whatever.

Today I've spent a ton of time running multiple tests in different setups. For all of these tests, Plex is not changed at all. These tests also use the exact same config and overlay files. The only changes are where Kometa is run from. Version: 2.1.0-build77 (Git: nightly) of Kometa was used in all cases.

  • ❌ Test Set 1: Kometa Docker on Unraid. The OG setup. || This gives inconsistent issues, as documented in this thread. Sometimes it works, but mostly it fails somewhere. The error that comes back is consistent(ish) but where the failure happens is VERY inconsistent. Check the thread for details and logs of this.
  • solved Test Set 2: Kometa Local install on different PC running Windows. || This worked completely fine across all tests.
  • solved Test Set 3: Kometa Docker on different PC running Windows. || This worked completely fine across all tests.
  • solved Test Set 4: Kometa Local install on Unraid. || This worked completely fine across all tests.

This more or less confirms that there is nothing wrong with my Plex setup, databases, nor the media files themselves. There is something unique about the Kometa Docker on unraid. I already completely nuked the Kometa container/image/appdata folder I had yesterday, and was still getting errors. I'll try it again tomorrow, and also see if there are orphaned images that are left behind. Then I'll start digging into why the Unraid Docker is different/special. The docker.img isn't full, and all my other containers are running just fine.

distant current
light isle
#

Here's the docker run command that gets executed on unraid:

docker run
  -d
  --name='Kometa'
  --net='redactednet'
  --pids-limit 2048
  -e TZ="Europe/London"
  -e HOST_OS="Unraid"
  -e HOST_HOSTNAME="redactedhostname"
  -e HOST_CONTAINERNAME="Kometa"
  -e 'KOMETA_CONFIG'=''
  -e 'KOMETA_TIME'='08:00'
  -e 'KOMETA_RUN'=''
  -e 'KOMETA_TEST'='false'
  -e 'KOMETA_DEBUG'='true'
  -e 'KOMETA_TRACE'='true'
  -e 'KOMETA_LOG_REQUESTS'='true'
  -e 'KOMETA_TIMEOUT'=''
  -e 'NO_VERIFY_SSL'='False'
  -e 'KOMETA_COLLECTIONS_ONLY'='false'
  -e 'KOMETA_METADATA_ONLY'='false'
  -e 'KOMETA_PLAYLISTS_ONLY'='false'
  -e 'KOMETA_OPERATIONS_ONLY'='false'
  -e 'KOMETA_OVERLAYS_ONLY'='true'
  -e 'KOMETA_RUN_COLLECTIONS'=''
  -e 'KOMETA_RUN_LIBRARIES'=''
  -e 'KOMETA_RUN_FILES'=''
  -e 'KOMETA_IGNORE_SCHEDULES'='false'
  -e 'KOMETA_IGNORE_GHOST'='false'
  -e 'KOMETA_DELETE_COLLECTIONS'=''
  -e 'KOMETA_DELETE_LABELS'='false'
  -e 'KOMETA_RESUME'=''
  -e 'KOMETA_NO_COUNTDOWN'='false'
  -e 'KOMETA_NO_MISSING'='false'
  -e 'KOMETA_NO_REPORT'='false'
  -e 'KOMETA_READ_ONLY_CONFIG'='false'
  -e 'KOMETA_DIVIDER'=''
  -e 'KOMETA_WIDTH'=''
  -e 'LOW_PRIORITY'='False'
  -e 'KOMETA_PLEX_URL'='redacted'
  -e 'KOMETA_PLEX_TOKEN'='redacted'
  -l net.unraid.docker.managed=dockerman
  -l net.unraid.docker.icon='https://raw.githubusercontent.com/Kometa-Team/Kometa/nightly/docs/_static/logomark-color.png'
  -v '/mnt/user/appdata/Kometa/config/':'/config':'rw' 'kometateam/kometa:nightly'
8ecb8027fb03c7aa4d378502ca9fbe9e04649adaaaaffdb97e42e25d16b3a834

The command finished successfully!
vocal cedar
#

As youve highlighted, when you are running in UnRaid it is the same docker image that is used as is used when you run docker not in UnRaid, so I'm not sure what to suggest here

#

I don't believe the Kometa code has any unRaid-specific code in it that would result in one behaviour in unRaid and another not

light isle
# vocal cedar As youve highlighted, when you are running in UnRaid it is the same docker image...

Yeah, I can understand that. But I also have nowhere else to turn to for help.
Can't go to Plex, as I've pretty much confirmed Plex itself isn't the issue.
Can't go to Unraid, as all my other Docker containers are working (including other ones that interact with Plex like ImageMaid, tautulli, etc).

The only thing I can think of is something on the networking side of things, because that's the only thing I've changed recently on my server (swapped from SWAG to Traefik for reverse proxying, and setup Clourdflare Tunnels). But I don't use that with Plex nor Kometa, and I don't think I made that change when the issue first started happening.

I'm hoping that maybe @lavish knoll might have some ideas how I can at least try to narrow down the issue.

#

Today I'm going to try blowing away the Kometa container, images, config, etc and then rebuild my docker.img in case there is something there. It doesn't seem like there is, but I'm running out of ideas what else to try 😅

vocal cedar
#

Completely understand everything you're saying but I don't think that's going to anything to help you

#

Ultimately, Kometa is using PlexAPI to make a request, and the response to that PlexAPI requests is inconsistently not what PlexAPI expects to see

#

Whether something in the unraid stack is interfering, I can't say.

#

I agree it is odd that if you run Kometa outside of the local server then you consistently don't see the error, perhaps the network traversal path differs than when both images are sitting on the same unraid server.

light isle
vocal cedar
#

When on the same system, inconsistently getting the error during the same run is worrying - the exact same call is being made, PlexAPI just says that what Plex provided doesn't match what it expects sometimes

#

I can't explain that, and I doubt Sohjiro will be able to either as it's the conversation between PlexAPI and Plex that is ultimately telling Kometa that something went wrong

light isle
# vocal cedar I can't explain that, and I doubt Sohjiro will be able to either as it's the co...

It's not necessarily that straightforward though. I have both ImageMaid and Plex Auto Languages setup in the same was Kometa, which both use the PlexAPI python library, and they're working just fine. So while yes, it has some part to play, it's not necessarily the whole part.

I'm not trying to place blame or say it's entirely Kometa's fault (given that it works elsewhere, it's very likely not the case), but I don't really have anywhere else to turn. Even turning to PlexAPI for support, they can likely just say that it works on my other containers, so there's nothing they can do. And even if they could do something, I don't really understand Kometa's codebase and how it interacts with PlexAPI, so I can't have those conversations with them to see what it might be.

I just need someone smarter than me, with more in-depth knowledge of the codebase and how it interacts with PlexAPI/Plex to have a look and see if they can have any ideas of where I can start looking. Cos right now I'm just shooting in the dark. Or even if I can get some pointers to be like "hey, go to PlexAPI and ask them to look at X, Y, Z".

vocal cedar
#

Sure, I'll wait for someone else to chime in as I've exhausted my technical ability to help you with this - hopefully you can figure out what's going on

light isle
# vocal cedar Sure, I'll wait for someone else to chime in as I've exhausted my technical abil...

Thanks. I do really appreciate your time and patience with this.
And I know I could technically just use one of the other methods for Kometa, and that's what I'll end up doing if I can't get a fix. But I would much rather get a fix for this, as the other way is a pretty hacky method and very non-standard. Also makes updating things a much bigger pain in the behind.
Or at least if there is no fix, but I can understand why it's even happening in the first place 😅

light isle
crude slateBOT
#

📝 If you want to review this again, cglatot:
:one: Right-click (or long press with phone) on the message that contains the log
:two: Select: Copy Message Link
:three: Use the command: /logscan <message_link> or !logscan <message_link> and paste the value copied from the previous step where you see <message_link> 📝

#
**Plex Configuration** - Section 2

Using Asset Directory: config/assets
Connected to server plexbox version 1.41.4.9463-630c9f557
Running on Linux version 6.6.68-Unraid
Plex DB cache setting: 2048 MB
PlexPass: True on Public update channel.
Scheduled maintenance running between 4:00 and 8:00
Connected to library TV Shows
Type: Show
Agent: tv.plex.agents.series
Scanner: Plex TV Series
Ratings Source: N/A
TV Shows Library Connection Successful

Page 6/9
vocal cedar
#

No results when searching for that error across the Discord

#

and this one isn't plexapi, it's tmdbapis

#

so that's now two apis that have reported receiving "bad" data from Plex

light isle
#

But why did it work for SO many tests yesterday?? 😭 On my 3 other test cases where it seemed to be working, I did at least 15 runs, and each one was fine

vocal cedar
#

Is your unraid server up to date, has it been restarted recently, just trying to see if your environment is in overall good health

light isle
vocal cedar
#

are any unraid maintenance tasks running at present

#

idk unraid at all so I'm just saying words 😄

light isle
#

nope

vocal cedar
#

are you using the official plex container or one of these third-party ones like lsio

light isle
#

I'll need to rerun the ones on my desktop as well to see if those were somehow just flukes too

light isle
vocal cedar
#

Just to highlight that the lsio Kometa container had some differences from the official Kometa one for a long time

#

So there could be differences in the Plex container too

#

I don't know if the lsio and official plex container can be swapped out easily or if there would be repercussions for doing so

#

but it's maybe worth a shot

light isle
#

the lsio container is the most used one, so you would think if that's the reason then others would be having issues too. And it doesn't look like it.

#

I can try cloning the appdata and use it as a separate install

vocal cedar
#

I mean thousands upon thousands of people use Kometa too and don't have these issues 😄

#

Just saying

#

Just trying to rule out as many things as we possibly can

light isle
#

like I said I will try it anyway, but I doubt that is the case

vocal cedar
#

Up until not too long ago, lsio caused us a lot of headaches

#

we had to give guidance on why people shouldn't use the lsio container

#

someone from the lsio team (I think) came to us and worked with us to iron out the majority of the issues with the lsio image

stiff gazelleBOT
#
LinuxServer (LSIO) Issues

The Linuxserver.io image [linuxserver/kometa] is different to the OFFICIAL image [kometa-team/kometa] in a few ways that cause problems.

It keeps the Kometa files in a different place inside the image compared to official, so when you exec into it you can't just run Kometa, you need to cd into another dir first.

The default run time is 3:00am which coincides with Plex maintenance.

Generally speaking, we suggest you use the official Kometa image instead of lsio. Type !repos for more info.

Thanks for using Kometa
vocal cedar
#

that's the two that are left from the list, which aren't as fundamental as the other issues it had

#

And obviously any update to Plex risks incompatibility issues with third-party images etc, also true for Kometa and any third-party images

#

It's just another avenue to explore, it may not be the culprit

light isle
#

I'm going to do a lot more runs on my windows PC first. That should theoretically see if the case IS the plex install, or something funky on unraid.

vocal cedar
#

Sounds good

#

The only otjher person to report your initial error was also running unraid, FWIW

light isle
#

Okay, I might have found something. I just don't know if it's the right thing lol.
Been looking through my unraid logs and I can see intermittent python segfaults. So got the live unraid log up while also running Kometa from unraid (local, not docker).
I have been able to correlate 2 instances so far where the segfault happens, and the Kometa run just gets killed.

The stickler is, Kometa doesn't error out, it just stops.

[2025-03-03 15:35:40,015] [config.py:1242]            [INFO]     |========================================== Scanning Files ==========================================|
[2025-03-03 15:35:40,015] [meta.py:71]                [INFO]     |                                                                                                    |
[2025-03-03 15:35:40,015] [meta.py:72]                [INFO]     |====================================================================================================|
[2025-03-03 15:35:40,015] [meta.py:72]                [INFO]     |                    Loading Overlay File 0 File: config/overlays/media_info.yml                     |
[2025-03-03 15:35:40,015] [meta.py:72]                [INFO]     |====================================================================================================|
[2025-03-03 15:35:40,016] [meta.py:73]                [INFO]     |                                                                                                    |

That's at the end of one of the runs with the segfault. No error or anything from Kometa's side, it just stops running. And the next line (watching the console live) is just the console waiting for the next command.

I'm running more tests now to try to trigger the error messages we've been seeing and see if there is a segfault also triggers at the same time. Annoyingly, other than the segfault stops, the runs have been running smoothly ¬.¬

#

The segfault will need addressed anyway, but I just don't know if the issues we've been seeing is also caused by it. Will report back when I get more results!

vocal cedar
#

Kometa just stopping is kind of expected

#

It means something external has killed it rather than it gracefully exiting on its own terms

#

So the segfault occuring at the same time makes sense if that will kill the run

light isle
vocal cedar
#

Maybe there's another non-obvious thing happening that is messing with the calls/responses but not in a way that causes Kometa to exit

stiff gazelleBOT
#

antwanchild used !aenh

@light isle, anything else needed here? If not, please type /close and hit enter. Please respond within 24 hours of this message or it will be archived.

light isle
meager pebble
#

The segfaults seem like maybe hardware?

light isle
meager pebble
#

The problem is that it's not reproducible except in your specific setup and even then not always and not always in the same place in the code if it happens, so it really seems unlikely to be a software fault.

About the only thing I can imagine to do would be to festoon one of these code paths with logging and see if you can reproduce it to see what's different between working and failing cases.

light isle
#

Technically not the only person to have had this issue: #1277346956041257074 message

Unfortunately they never came back to confirm whether or not it worked. I did try reaching out to them as well, but no response.

#

I actually completely forgot about littering the code with logging - that's originally what I was going to do when I cloned the repo, but ended up going on the rabbit hole of testing in different environments instead. Will see if I can get to that in the next couple of days.

meager pebble
#

Where is that link? I don't have access to it.

vocal cedar
#

I can access it, it's an old help thread

#

#1277346956041257074 message

#

It was another unRaid user

distant current
distant current
#

That issue was 6 months ago; but was still determined to not be a Kometa issue, and a plexaAPI issue.

crude slateBOT
#

This post has been marked as Resolved and has now been closed.

You cannot reopen this thread - you must create a new one or ask a member of staff to reopen it in #general-chat.

Thanks for using Kometa.