Jump to content

Auto Organize - Expanding its functionality


aaronsomek

Recommended Posts

TheUrbanXplorer
16 minutes ago, chef said:

 

 

Was that series auto detected during your test? or did you have to identify it?

 

I'm having some serious issues with the metadata providers right now, and I think this related.

 

I had to identify the series. I create new series myself, because many are already similar in title. Only existing ones are added automatically.
Once the series are created in Emby, the subsequent ones are automatically named correctly. Is always the first episode of a new series.

Link to comment
Share on other sites

9 minutes ago, TheUrbanXplorer said:

I had to identify the series. I create new series myself, because many are already similar in title. Only existing ones are added automatically.
Once the series are created in Emby, the subsequent ones are automatically named correctly. Is always the first episode of a new series.

okay. I've found the code, and I've gone through it to make sure that it is always adding culture specific Metadata requests, and also making sure it is  appending the country code to the request.

 

There might be one other thing that is happening here, but I'm not entirely sure....

It is possible that the only metadata available for this series is in English, and Emby is grabbing what it can from the provider after it has been identified.

This could explain why it wasn't auto detected by name, and why the series folder is being created in English.

Are you experiencing this with all new series, or did it happen specifically with "McLeods Daughters"?

 

Thanks so much for taking the time! :)

 

Link to comment
Share on other sites

TheUrbanXplorer
1 hour ago, chef said:

okay. I've found the code, and I've gone through it to make sure that it is always adding culture specific Metadata requests, and also making sure it is  appending the country code to the request.

 

There might be one other thing that is happening here, but I'm not entirely sure....

It is possible that the only metadata available for this series is in English, and Emby is grabbing what it can from the provider after it has been identified.

This could explain why it wasn't auto detected by name, and why the series folder is being created in English.

Are you experiencing this with all new series, or did it happen specifically with "McLeods Daughters"?

 

Thanks so much for taking the time! :)

 

No, that's unfortunately the case with every new series.
This has only been the case for a few updates. Before it worked. Have unfortunately not paid attention to which version that was.🤣😒

Link to comment
Share on other sites

Version 1.6.0.6

  • Fixed when a file is copying over to the monitored folder sorting happened before it was ready (linux)
  • try to force providers to adhere to the culture.

 

Edited by chef
  • Like 1
Link to comment
Share on other sites

TheUrbanXplorer
On 1/24/2022 at 10:56 PM, chef said:

... and it's fix. sorry about that. Identify was broken, but it is working again here, with a browser cache clear:

Emby.AutoOrganize_v1.6.0.7.zip 134.08 kB · 4 downloads

Sorry, because of family and work I come unfortunately only now to play through that.
Through the update now runs one scan after another in continuous loop, otherwise nothing happens unfortunately.
I have already deleted the database, hoping that there is an error, but with a new database the error remains.
This is what shows up in the log:

 

*** Error Report ***
Version: 4.7.0.21
Command line: C:\Users\Rico\AppData\Roaming\Emby-Server\system\EmbyServer.dll
Operating system: Microsoft Windows 10.0.22000
Framework: .NET 6.0.0-rtm.21522.10
OS/Process: x64/x64
Runtime: C:/Users/Rico/AppData/Roaming/Emby-Server/system/System.Private.CoreLib.dll
Processor count: 10
Data path: C:\Users\Rico\AppData\Roaming\Emby-Server\programdata
Application path: C:\Users\Rico\AppData\Roaming\Emby-Server\system
System.Exception: System.Exception: Object reference not set to an instance of an object.
at Emby.AutoOrganize.Core.InternalFileOrganizationService.PerformOrganization(EpisodeFileOrganizationRequest request)
Source: Emby.AutoOrganize
TargetSite: Void MoveNext()
Link to comment
Share on other sites

2 hours ago, TheUrbanXplorer said:

Hello boss,
Thanks for the update. 😊
I don't know how to say it gently....
The plugin is now working very fast again.... But it uses the original title again.... 🤣

The original title? 

Can I have an example again please. Sorry about that. 

 

The plugin has so many constructor methods in the sorting code, it's hard to know where a user is going to enter the sort method. It drives me nuts! 😆

 

 

Link to comment
Share on other sites

  • 2 weeks later...

chef, what's the metadata provider you are using for tv shows?

I just tried to organize One Piece S20E01 and got this error...

2022-02-09 09:21:37.976 Info Server: http/2 POST https://<domain>/emby/Library/FileOrganizations/abf437bde11af665e65de9b112c48cdc/Episode/Organize?X-Emby-Client=Emby Web&X-Emby-Device-Name=Google Chrome Windows&X-Emby-Device-Id=xxxxxxxxxxxxx&X-Emby-Client-Version=4.7.0.18. UserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/98.0.4758.81 Safari/537.36
2022-02-09 09:21:38.042 Info HttpClient: GET https://api.themoviedb.org/3/tv/37854/season/20/episode/1?api_key=xxxxxxxxxxxxxxxxxxxxxxxxx&append_to_response=images,external_ids,credits,videos&language=de&include_image_language=de,null,en
2022-02-09 09:21:38.071 Info HttpClient: GET https://private.omdbapi.com?apikey=fe53f97e&plot=full&r=json&i=tt0388629&Episode=1&Season=20
2022-02-09 09:21:38.112 Warn App: No provider metadata found for One Piece season 20 episode 1
2022-02-09 09:21:38.113 Error Server: Error processing request
	*** Error Report ***
	Version: 4.7.0.18
	Command line: /opt/emby-server/system/EmbyServer.dll -programdata /var/lib/emby -ffdetect /opt/emby-server/bin/ffdetect -ffmpeg /opt/emby-server/bin/ffmpeg -ffprobe /opt/emby-server/bin/ffprobe -restartexitcode 3 -updatepackage emby-server-deb_{version}_amd64.deb
	Operating system: Linux version 5.4.0-88-generic (buildd@lgw01-amd64-008) (gcc version 9.3.0 (Ubuntu 9.3.0-17ubuntu1~20.04)) #99-Ubuntu SMP Thu Sep 23 17:29:00 UTC 2021
	Framework: .NET 6.0.0-rtm.21522.10
	OS/Process: x64/x64
	Runtime: opt/emby-server/system/System.Private.CoreLib.dll
	Processor count: 4
	Data path: /var/lib/emby
	Application path: /opt/emby-server/system
	System.Exception: System.Exception: No provider metadata found for One Piece season 20 episode 1
	   at Emby.AutoOrganize.Core.InternalFileOrganizationService.PerformOrganization(EpisodeFileOrganizationRequest request)
	Source: Emby.AutoOrganize
	TargetSite: Void MoveNext()
	
2022-02-09 09:21:38.113 Info Server: http/2 Response 500 to xxx.xx.xxx.xxx. Time: 138ms. https://<domain>/emby/Library/FileOrganizations/abf437bde11af665e65de9b112c48cdc/Episode/Organize?X-Emby-Client=Emby Web&X-Emby-Device-Name=Google Chrome Windows&X-Emby-Device-Id=xxxxxxxxx&X-Emby-Client-Version=4.7.0.18

...although S20E01 exists on TVDB: https://thetvdb.com/series/one-piece/seasons/official/20

Anything you can do here?

Link to comment
Share on other sites

AdrianW
38 minutes ago, neik said:

chef, what's the metadata provider you are using for tv shows?

I just tried to organize One Piece S20E01 and got this error...

There's a problem with the tvdb API, any shows with lots of episodes aren't pulling data past a certain point. I have the same issue with SNL and The Simpsons.

I would have thought it would be best to pull data for a specific season, but it seems that Emby tries to pull data for the entire series and then has issues.

Link to comment
Share on other sites

sydlexius
10 hours ago, AdrianW said:

There's a problem with the tvdb API, any shows with lots of episodes aren't pulling data past a certain point. I have the same issue with SNL and The Simpsons.

I would have thought it would be best to pull data for a specific season, but it seems that Emby tries to pull data for the entire series and then has issues.

This has to do with a pagination bug for TMDB v4 API episode data.  I believe that @Luke has an action item to address this?

Link to comment
Share on other sites

2 minutes ago, sydlexius said:

This has to do with a pagination bug for TMDB v4 API episode data.  I believe that @Luke has an action item to address this?

Correct.

Link to comment
Share on other sites

If that bug is the problem then I'm wondering why it organizes just fine on Simpsons S33, or Pokemon S24?
I would expect them to hit that limit as well. Does anyone know at which episode count the problem begins?

Link to comment
Share on other sites

AdrianW
2 hours ago, neik said:

why it organizes just fine on Simpsons S33

The Simpsons hasn't be organising for me, neither has SNL or One Piece.

Link to comment
Share on other sites

2 hours ago, neik said:

If that bug is the problem then I'm wondering why it organizes just fine on Simpsons S33, or Pokemon S24?
I would expect them to hit that limit as well. Does anyone know at which episode count the problem begins?

You could try putting one of the other tv metadata providers at the top of the list for the tv shows library.

Would that work? That particular provider would take presidency over the tvdb?

Edited by chef
Link to comment
Share on other sites

Garbonzo17

Is 1.6.0.5 still the latest?

I only got the zip from this tread, didn't know if there was a github link or something.

asking for no particular reason, other than I thought about it while trying to track down a permissions issue, but I am still not sure what is going on with those.
(the metadata keeps getting readonly perms set and it is making it a pain to edit anything in the unraid share from windows explorer... anything moved via sonarr/radarr seem fine, but ones done within emby seem to cause me grief.)
Anyhoo, I will keep researching that part... (unless anyone can point me in the direction) but was just making sure I was current on AO plugin... and hey, are .srt files supposed to get left behind still... I thought I read something a few pages back that they (along with other subs) were 'handled' or something to that effect...

 

TIA

-G

Link to comment
Share on other sites

2 minutes ago, Garbonzo17 said:

Is 1.6.0.5 still the latest?

I only got the zip from this tread, didn't know if there was a github link or something.

asking for no particular reason, other than I thought about it while trying to track down a permissions issue, but I am still not sure what is going on with those.
(the metadata keeps getting readonly perms set and it is making it a pain to edit anything in the unraid share from windows explorer... anything moved via sonarr/radarr seem fine, but ones done within emby seem to cause me grief.)
Anyhoo, I will keep researching that part... (unless anyone can point me in the direction) but was just making sure I was current on AO plugin... and hey, are .srt files supposed to get left behind still... I thought I read something a few pages back that they (along with other subs) were 'handled' or something to that effect...

 

TIA

-G

 

On 1/27/2022 at 9:33 PM, chef said:

That's it there.

If this is the first time you are running this expanded version, you'll have to delete the fileorganizer.db

 

@neik any way you can post the file path to the db that has to be removed?

  • Like 1
Link to comment
Share on other sites

Garbonzo17

Yeah, for whatever reason that seems to just prove my issue that it ISNT the way the MOVE command is executed.

The media folder on Unraid I had just ran "newperms" command and folders are 777 files in those folders are 666...
for whatever reason the new "moviename" just created upon triggering AO plugin made "moviename" folder with 755 yet the actual movie it moved is 666... the subsequent file (metadata) jpg/nfo were set 644 (expected with the folder at 755)... 

I KNOW this isn't the place to post this... but I am rambling from this point on...
I just am missing something, and every time I think I have my head wrapped around umask something acts different than expected.
I am shooting for 775/664 but at this point the 777/666 would work as it's a secure enough lan with only me editing files..

expected behavior as I have gone back and set my relevant containers to umask=002.

Link to comment
Share on other sites

6 minutes ago, Garbonzo17 said:

Yeah, for whatever reason that seems to just prove my issue that it ISNT the way the MOVE command is executed.

The media folder on Unraid I had just ran "newperms" command and folders are 777 files in those folders are 666...
for whatever reason the new "moviename" just created upon triggering AO plugin made "moviename" folder with 755 yet the actual movie it moved is 666... the subsequent file (metadata) jpg/nfo were set 644 (expected with the folder at 755)... 

I KNOW this isn't the place to post this... but I am rambling from this point on...
I just am missing something, and every time I think I have my head wrapped around umask something acts different than expected.
I am shooting for 775/664 but at this point the 777/666 would work as it's a secure enough lan with only me editing files..

expected behavior as I have gone back and set my relevant containers to umask=002.

😳 I wish I knew about that stuff to help. 

 

Link to comment
Share on other sites

10 hours ago, chef said:

You could try putting one of the other tv metadata providers at the top of the list for the tv shows library.

Would that work? That particular provider would take presidency over the tvdb?

Will try that next time when I organize those files.

9 hours ago, chef said:

@neik any way you can post the file path to the db that has to be removed?

On Linux it's /var/lib/emby/data/fileorganization.db

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...