Boxset Error Report in server log

[GB Utah 4]

2016-02-04 12:22:39.1824 Info Auto Box Sets: Executing Automatic BoxSet creation.  Found 209 potential box sets.
2016-02-04 12:22:39.1980 Error Auto Box Sets: Error removing box set member F:\Movies\M-P\Mission Impossible\Mission Impossible 3.avi
	*** Error Report ***
	Version: 3.0.5821.0
	Command line: C:\Users\admin\AppData\Roaming\MediaBrowser-Server\System\MediaBrowser.ServerApplication.exe
	Operating system: Microsoft Windows NT 6.2.9200.0
	Processor count: 2
	64-Bit OS: True
	64-Bit Process: True
	Program data path: C:\Users\admin\AppData\Roaming\MediaBrowser-Server
	Application Path: C:\Users\admin\AppData\Roaming\MediaBrowser-Server\System\MediaBrowser.ServerApplication.exe
	Value cannot be null.
	Parameter name: id
	System.ArgumentNullException
	   at MediaBrowser.Server.Implementations.Library.LibraryManager.GetItemById(Guid id)
	   at MediaBrowser.Server.Implementations.Collections.CollectionManager.<RemoveFromCollection>d__2f.MoveNext()
	--- End of stack trace from previous location where exception was thrown ---
	   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
	   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
	   at AutoBoxSets.Plugin.<UpdateBoxSet>d__1e.MoveNext()
	
2016-02-04 12:22:39.1980 Error Auto Box Sets: Error removing box set member F:\Movies\M-P\Mission Impossible\Mission Impossible 2.avi
	*** Error Report ***
	Version: 3.0.5821.0

I've just had my server log spammed with these. I didn't count, but I suspect every file that has a collection ID. The files are present and there doesn't appear to have been any change to the actual boxset/collection, but sending the Error Report for what it's worth.

[Luke 37057]

Hang tight, a new version of the plugin is soon to be released that will not do any removing anymore. Thanks.

[ebr 14910]

You can try installing the dev version of the plug-in which should not cause those messages.

 

There could be another issue underneath, however since the plug-in thinks those items are not valid.

[ginjaninja 533]

Would be good ....if the plugin gets an affirmed response of not valid for a tmdb collection id, emby/plugin would remove that collectionid from all objects where that metadata is not locked...

 

Currently users end up with ghost collection ids that never get fixed ....even by a refresh of the movie object.with no chance of any metadata coming later as tmdb has defined that id as not valid.

 

Sent from my GT-I9505 using Tapatalk

[Luke 37057]

that's what we've been doing the whole time but then we have to answer questions on an almost daily basis about why content is getting removed from collections. the only way to make it stop is just to not do it anymore.

[ginjaninja 533]

that's what we've been doing the whole time but then we have to answer questions on an almost daily basis about why content is getting removed from collections. the only way to make it stop is just to not do it anymore.

Really? As someone who treats the central providors as master for all metadata except primary image, im noticing regularly how emby does not always respect the providors.

 

"The content is getting removed because the collection id once upon a time came from tmdb but now it is no longer valid on tmdbid. You have not fixed your metadata and you are using a plugin which treats tmdb as master for tmdbids."

 

the nub of the suggested design is good imo.... Just user clarification/expectation and protection functionality.

 

Afterall what about those users, who are a significant portion, who just want to treat the providors as master for a subset of their metadata.

 

As for the others they can lock their metadata to prevent emby and its plugins 'knowing better'.

 

Suggestion: Maybe if the metadata locks were instanced at a global level with lower down eg object, metadata locks taking preference all user expectations/requirements could be satisfied safely and clearly.

 

A Global lock on tmdbcollectionid could be on by default...and users could choose to unlock:a failsafe to avoid unwanted/unexpected metadata loss.

 

Services (emby and its plugins) changing metadata on objects would (by convention initially or sophisticated access control later perhaps) have to respect the metadata locks at the global, (media folder perhaps), and object level.

 

The lock values could be some or more of.....

"No changes allowed",

"changes from blank allowed",

"all changes except something to blank",

"all changes allowed" (warning risk to metadata loss).

 

Sent from my GT-I9505 using Tapatalk

[Luke 37057]

The issue is clearly visible all over the forum though. Even  you have to admit that you recognize it's causing people headaches.