Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Existing TV titles not marked as available #5142

Open
skorpeyon opened this issue Jul 21, 2024 · 8 comments
Open

Existing TV titles not marked as available #5142

skorpeyon opened this issue Jul 21, 2024 · 8 comments

Comments

@skorpeyon
Copy link

Summary

I'm using Ombi with Emby and Sonarr, and all TV shows I already had on my server before connecting Ombi are showing as "Approved" but not "Available" even when they are shown as complete in Sonarr. I'm not sure where to look for any relevant log information, so if anyone can guide me to that I'm happy to provide it. I did manually request and then fulfill a TV show and that does show up as "Available." This is only occurring with items I already had on my server before adding Ombi to it. The shows are also not showing up in the requests page, so I can't even manually mark them as "Available" and I can't re-request them because they've already been requested.

Ombi Version

4.43.5

What platform(s) does this occur on?

Linux

What database are you using?

SQLite (Default)

Relevant log output

No response

@tidusjar
Copy link
Member

So Ombi will check to see if a TV Show in Sonarr is Monitored. If that is the case they will show as Approved in Ombi.

Regarding availability, once that episode is in Emby then it will show as Available. If you want Ombi to control this then just delete the show from Sonarr, go into the Sonarr Settings inside Ombi and just press the "Submit" button (this will clear out the existing data Ombi has on Sonarr and re-fetch everything). You should see that TV show as no longer available

@skorpeyon
Copy link
Author

That isn't how it is working, though. All monitored episodes are in Emby, and it's not showing as Available. That's my problem. For every TV show I have, it's showing as "Approved" but not "Available" even though all of those shows are indeed available and showing in Emby.

@tidusjar
Copy link
Member

Understood. Just to check, because this has caught a lot of people out. Is the Enabled switch turned on in your Emby settings page in Ombi?

@skorpeyon
Copy link
Author

I had seen that as a fix in another issue post, but just double-checked again and Emby is Enabled.

@tidusjar
Copy link
Member

Ok, can you upload some logs to paste bin or somewhere after you run the scan?

@war3zlod3r
Copy link

I'm having this same problem with Plex and Sonarr with Ombi I have shows that are available in both Plex and Sonarr but ombi is hung up on "Processing Request"

@gihayes
Copy link

gihayes commented Sep 25, 2024

I am having the same problem. I am using Emby. I have summary, screenshots, and logs ready. Should I create a new Issue?

@SippieCup
Copy link

SippieCup commented Oct 8, 2024

I had this just happen. It turns out that the SonarrEpisodeCache ran out of id numbers.

Since it was empty, to fix it I just reset the autoincrement value back to 1, then removed the plex server and re-added it (full sync will just have an HTTP time out and rollback).

I suggest disabling any notification messages that you have, as it'll re-send all availability emails/messages.

logs: https://gist.github.com/SippieCup/cbfd57328cb57568f422aec9d4bd753a

@tidusjar I would suggest moving to unsigned int for more ids as a stop-gap. Although that might break a bunch of foreign keys.

I am not entirely sure how the SonarrEpisodeCache is used, but perhaps keeping the table persistent with a resolvedAt timestamp might be a better approach rather than inserting and deleting rows, then doing upserts on the tvdbid column to stop duplicates.

IMO, even with a large library, it shouldn't be getting up to 2 billion ids. It probably needs some kind of refactoring.

Edit: Did a little more investigating, every sync adds 271,239 row in my case, if we were to persist the data with resolvedAt, the total row size would be 26 bytes vs the 21 bytes it is now. total table size would still only be 7MB in my case. Moving to upsert looks like a decent fix, the lookup operation would be far cheaper than the current create -> read -> delete flow.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants