-
Notifications
You must be signed in to change notification settings - Fork 155
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
When scanning a new folder, 'Extras' Files are first added, then removed by subsequent scans #441
Comments
Extras are supposed to be skipped, not sure why they would have been added in the first place, but without the root folder and full path and scanner logs when they are added the first time, then the subsequent scan, difficult to progress |
I will try to capture that on the next pass. |
Any progress ? Extras folders should be skipped, so not sure why they are added then removed, logs needed to further troubleshooting |
Oh, Right, I'll reproduce it today. But yeah, it's still doing it.
…On Wed, Sep 13, 2023 at 12:45 AM Benjamin Brisson ***@***.***> wrote:
Any progress ? Extras folders should be skipped, so not sure why they are
added then removed, logs needed to further troubleshooting
—
Reply to this email directly, view it on GitHub
<#441 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAB55SG6UH2YU7MNEQW42MDX2FQAFANCNFSM6AAAAAAZPEU2NU>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
Ok here's the latest. I renamed this folder from
If I scan it again, once more (from experience) the media items in the Here's the Scanner Logs for the series in question:
Interestingly, the
And the
Then I re-scanned everything.... Nothing mentioned in any of the logs after the re-scan. |
Root level scan is used for root files and grouping folders and skip the rest as individual folders also get their scanner run independantly and need the scanner to cancel one of them only. Grouping folders are only able to work from the root level scan and this do not get cached so make scan time longer and are a hack I did to have series folder not at root level to still work... Scanner detected the Extras folder during root level call to be skipped, to after load it anyway with no path but correct file number... [_] Twin Star Exorcists (2016) ( 50 files) Need to look at the code...
|
Yeah, the grouping folders are definitely causing it to scan very slowly. It was nice for organizing the files, but I'm seriously considering doing away with the grouping folders.... But even so, the series in question was not in a grouping folder. They were just hanging out in the |
So I was playing a bit more with when the series metadata gets overwritten. Apparently it keeps the watch history.... so it's using the same plex ID.... but when Hama identifies the series, after assigning the ID, it force-overwrites all metadata and ignores the "lock" icon for each field. I'm unclear if this is a Scanner or Agent bug..... It honors the "lock" icon when refreshing metadata or using "fix match". But if I rename the folder, it seems to keep the watch history but reset all metadata. (a previously-edited series title will revert back to anidb "main" title) |
Hama agent provide the metadara, but Plex manages the field lock mechanism The history seem linked to the file and the cache system identifies the file is the same by checksum seemingly It is a different series since the guid used by Hama is different since it used the series I'd and folder name if I recall well Need to look at the scanner behaviour |
So it sounds like the metadata is a Hama issue related to unpredictable guid? Hmmm.... I'll go review Hama code or file a new ticket over there. |
This is confirmed still happening. When adding new files, the |
On the first scan, these
Extras
will either be assigned a season or added to Season 1 (depending on file names). But in subsequent scans, these will be later removed, leaving the "trash" icon.The text was updated successfully, but these errors were encountered: