Is it possible to ADD xattr metadata to already sorted files?
If they do not already have xattr metadata, then the xattr script (fn:xattr) will not do much (since it only works on files that already have xattr)
The --apply metadata option seems to really be to create the .xattr folders for plex, not xattr metadata for additional processing by filebot.
Is the *best* option do a rename to itself? (assuming that will still add the xattr)
aka something like
filebot --q '380207' --db TheTVDB --action move -rename $SourceDir --format "$SourceDir/{fn}"
I have a number of directories that I have sorted that do not have filebot xattr, but I'd like to do some quality pruning where having the metadata on the file would be helpful for quality metrics based on episode number etc.
Thanks.
How to *add* xattr information to existing files ..
Re: How to *add* xattr information to existing files ..
ah poo.. I guess I just needed to search a little differently (search for xattr vs metadata) and I expect this answer I found is likely still valid ..
"Re: Migrate embedded xattr to .xattr folder in Synology
Post by rednoah » 03 May 2020, 17:50
You'll have to process files with Rename again. There's no way to add xattr metadata to files without also going through the matching and rename process."
but will a rename that doesn't actually change the name still add the xattr metadata?
"Re: Migrate embedded xattr to .xattr folder in Synology
Post by rednoah » 03 May 2020, 17:50
You'll have to process files with Rename again. There's no way to add xattr metadata to files without also going through the matching and rename process."
but will a rename that doesn't actually change the name still add the xattr metadata?
Re: How to *add* xattr information to existing files ..
xattr are indeed only written when files are processed as usual, since that is the only point in time where metadata is known. By default, FileBot uses file system xattr to store that metadata for later use, but FileBot can also be configured to store metadata as plain file structure instead in case file system support for xattr is limited.
Re: How to *add* xattr information to existing files ..
xattr are indeed only written when files are processed as usual, since that is the only point in time where metadata is known. By default, FileBot uses file system xattr to store that metadata for later use, but FileBot can also be configured to store metadata as plain file structure instead in case file system support for xattr is limited.
Why not organize files into a new folder structure entirely? Typically, users would separate input and output folder, where files in the output folder only ever end up there via FileBot, and thus all files in the output folder are guaranteed to have been processed by FileBot with xattr metdata being readily available.
Re: How to *add* xattr information to existing files ..
My setup/process is certainly not normal or typical. I have a "shotgun" approach to downloading Anime (and pretty much only English Subtitled Anime), so I get ALOT of files to sort and churn thru.
It is not unusual to see files named weirdly, or have the series name only at the directory level (batch releases for example), some groups (Horriblesubs) have ... interesting metadata in the file (Like all Horriblesub releases have media encoded dates in 2010 for example), don't name the audio/subtitle languages (so it's null in mediainfo) etc.
While I can (and do) use AniDB verified files as a sorting process (because it's 100% going to be whatever is setup in AniDB, which is likely to be highly accurate) .. But it's the stuff NOT in AniDB that I want to sort and compare with what's in my collection to see if it's worthwhile to keep and add (manually) to AniDB. For example, I have a backlog of files since the start of 2020 I haven't parsed and that's currently about 50k files (video/subtitles) to find a way to *accurately* parse. Which looks to be a serious challenge for Anime, even for Series that are simulcast in the US strict mode seems to match about half of the episodes "correctly", and non-strict .. can be a bit interesting
So I am using Filebot to try and sort, prune etc mostly the stuff NOT in AniDB. But when it comes to comparing to what's in AniDB, it would be a bit easier if I could add xattr info that filebot can use to those files so I can do episode comparisons easier as part of determining if I want to keep something that isn't in AniDB and/or isn't in my collection or is a better "Quality" then what I have.
Definitely not a typical setup
I can arrange a process to effectively just move the files to a different structure (so they rename) and then back, I was just hoping there was a way to add them wither via an existing command/script etc.
As I lack any Java/Groovy (or any professional development experience), onboarding to using groovy scripts has been quite slow and frustrating, but I expect eventually I'll get to the point where I can be at least barely competent at that level.
Filebot is a very good tool, 100% worth the cost to license and even with my personal frustration on understanding the "format" and groovy differences, and custom scripts .. It's already helped me on my unique sorting problem. I just have more work to do
In the list of public API's published here: https://www.filebot.net/docs/api/index.html are there methods etc where I could add the metadata using a groovy script without having to perform a rename action?
It is not unusual to see files named weirdly, or have the series name only at the directory level (batch releases for example), some groups (Horriblesubs) have ... interesting metadata in the file (Like all Horriblesub releases have media encoded dates in 2010 for example), don't name the audio/subtitle languages (so it's null in mediainfo) etc.
While I can (and do) use AniDB verified files as a sorting process (because it's 100% going to be whatever is setup in AniDB, which is likely to be highly accurate) .. But it's the stuff NOT in AniDB that I want to sort and compare with what's in my collection to see if it's worthwhile to keep and add (manually) to AniDB. For example, I have a backlog of files since the start of 2020 I haven't parsed and that's currently about 50k files (video/subtitles) to find a way to *accurately* parse. Which looks to be a serious challenge for Anime, even for Series that are simulcast in the US strict mode seems to match about half of the episodes "correctly", and non-strict .. can be a bit interesting
So I am using Filebot to try and sort, prune etc mostly the stuff NOT in AniDB. But when it comes to comparing to what's in AniDB, it would be a bit easier if I could add xattr info that filebot can use to those files so I can do episode comparisons easier as part of determining if I want to keep something that isn't in AniDB and/or isn't in my collection or is a better "Quality" then what I have.
Definitely not a typical setup
I can arrange a process to effectively just move the files to a different structure (so they rename) and then back, I was just hoping there was a way to add them wither via an existing command/script etc.
As I lack any Java/Groovy (or any professional development experience), onboarding to using groovy scripts has been quite slow and frustrating, but I expect eventually I'll get to the point where I can be at least barely competent at that level.
Filebot is a very good tool, 100% worth the cost to license and even with my personal frustration on understanding the "format" and groovy differences, and custom scripts .. It's already helped me on my unique sorting problem. I just have more work to do
In the list of public API's published here: https://www.filebot.net/docs/api/index.html are there methods etc where I could add the metadata using a groovy script without having to perform a rename action?
Re: How to *add* xattr information to existing files ..
1.
Well, the problem with writing xattr without renaming is that you'd have to blindly trust FileBot to match every single file correctly, because what's the point of tagging files if you can't trust that the those invisible tags are 100% correct? But at this point, if you trust FileBot auto-detection to that degree, then you might as well blindly organize all your files. Personally, I'd use the GUI and double-check things before I commit.
A custom script that tags files would be easy to write, but there's no official solution because it's just not a good approach IMHO, especially not if the thing runs unattended. Plowing through thousands of files in the GUI is a straight-forward process, compared to finding 1/1000 non-obviously miss-tagged files.
Note that xattr is not a FileBot thing. Any program can read / write FileBot style xattr metadata.
2.
If you're using AniDB on a large collection, then make sure you're not exceeding the limit, otherwise you might get your self temporarily banned:
viewtopic.php?t=11925
AniDB does have dedicated tools that match files via file hash. If disk I/O comes cheap, then those tools might be more suitable for unattended processing of files overnight.
Well, the problem with writing xattr without renaming is that you'd have to blindly trust FileBot to match every single file correctly, because what's the point of tagging files if you can't trust that the those invisible tags are 100% correct? But at this point, if you trust FileBot auto-detection to that degree, then you might as well blindly organize all your files. Personally, I'd use the GUI and double-check things before I commit.
A custom script that tags files would be easy to write, but there's no official solution because it's just not a good approach IMHO, especially not if the thing runs unattended. Plowing through thousands of files in the GUI is a straight-forward process, compared to finding 1/1000 non-obviously miss-tagged files. Note that xattr is not a FileBot thing. Any program can read / write FileBot style xattr metadata.2.
If you're using AniDB on a large collection, then make sure you're not exceeding the limit, otherwise you might get your self temporarily banned:
viewtopic.php?t=11925
AniDB does have dedicated tools that match files via file hash. If disk I/O comes cheap, then those tools might be more suitable for unattended processing of files overnight.