But that's the problem. The errors occur running 32-bit OS + 32-bit Java + 32-bit native libraries. Se my initial post.

Just for my understanding.

My OS (Vista) and Java are 32-bit.
I downloaded the 32-bit lib files and filebot-r4619.jar.xz - 2016-11-26 11:05:12.
Is the jar 64-bit or why do I need 64-bit Java? That was not the case so far.

After I downloaded the 64-bit files 7-Zip-JBinding.dll fpcalc.exe gcc_s_seh-1.dll jnidispatch.dll MediaInfo.dll I receive FileBot 4.7.5 (r4619) JNA Native: java.lang.UnsatisfiedLinkError: Native library (com/sun/jna/win32-x86/jnidispatch.dll) not found in resource path ([file:/D:/Portable%20Applicat...

Hi, with the same actual lib files I receive before the update FileBot 4.7.5 (r4603) JNA Native: 4.0.1 MediaInfo: 0.7.88 7-Zip-JBinding: 9.20 Chromaprint: 1.1.0 Extended Attributes: OK Script Bundle: 2016-11-26 (r465) Groovy: 2.4.7 JRE: Java(TM) SE Runtime Environment 1.8.0_111 JVM: 32-bit Java HotS...

Thanks!

Great! Thanks! I receive FileBot 4.7.5 (r4581) JNA Native: 4.0.1 MediaInfo: 0.7.88 7-Zip-JBinding: 9.20 Chromaprint: 1.1.0 Extended Attributes: OK Script Bundle: 2016-11-18 (r461) Groovy: 2.4.7 JRE: Java(TM) SE Runtime Environment 1.8.0_111 JVM: 32-bit Java HotSpot(TM) Client VM CPU/MEM: 2 Core / 24...

Hi,

how can I get the sysinfo (runScript 'sysinfo') from the command line?

Kind regards,

Sheldon

I guess you changed something because with r4020 the mismatch is gone. Great! Thanks!

But probably this normalization doesn't take place if the request is sent from the command line like above.

This is what happened. The command java -Dunixfs=false -DuseExtendedFileAttributes=true -DuseCreationDate=false -Djava.net.useSystemProxies=false -Dsun.net.client.defaultConnectTimeout=10000 -Dsun.net.client.defaultReadTimeout=60000 -Djna.nosys=true -Dapplication.deployment=portable -Dapplication.an...

After some research i found the culprit that causes the problem and it's not FileBot in the first place.
So consider this to be solved! Sorry for bothering you!

It should lead to no result but it leads to the show "After the Catch". That's the issue!
I didn't change the data at TheTVDB so far to be able to show the bug to you.

Sorry, my post was wrong.
I use s>=2 && s <=2 && e>=5 && e<= 5.
and this leads to "After the Catch."
That's the problem.

Yes, that's the right show. Thanks for your hint.
i know that the TheTVDB data can be modified. I did this already for other shows.
The problem is with FileBot. FileBot must not return wrong data in this case. But it does!

Yes, that's right! But I mentioned already that this data at TheTVDB is wrong.
After the Black is currently in season 2. They defined it to be season 1.
So you have to search for season 2 and their episode numbers (see my example) to get the wrong result (After the Catch).

I thought the series is set by the -q option. Do I have to add it to the filter as well? What is the difference?

The result of the list command is redirected to the output file.
The renaming is not done via Filebot. I fetch the name from the output file

Yes, you do because we did this already several times. But anyway. -list --db %2 --q %3 --lang %4 --filter %5 --format %6 --log OFF > %7 %* %2 = thetvdb %3 = After the Black %4 = en %5 = "s=2 && s<=2 && e>= 5 && e <= 5" %6 = "{n} - {s.pad(2)} - {e.pad(2)} - {t}...

Nope! You know my command already but here you are. java -Dunixfs=false -DuseExtendedFileAttributes=true -DuseCreationDate=false -Djava.net.useSystemProxies=false -Dsun.net.client.defaultConnectTimeout=10000 -Dsun.net.client.defaultReadTimeout=60000 -Djna.nosys=true -Dapplication.deployment=portable...

But I didn't set the -non-strict option in my command.

Sorry, but no! Whatever logic you apply the only correct result in this case is no result. Everything else is wrong.
This is not a matter of taste but a matter of logic.

Hi, I recognized a new matching problem with r3995. The shows After-the-Black-S02E03 After-the-Black-S02E04 After-the-Black-S02E05 are matched to After-the-Cash-S02E03 After-the-Cash-S02E04 After-the-Cash-S02E05. One reason migtht be that at TheTVDB the current season 2 is wrongly defined as season ...

That's clear! But r3966 being followed by r3894 is a bit confusing. So r3894 it is!

So this

filebot-r3894.jar 2016-04-22 35.9 MB 44 weekly downloads i

is the current version?

Hi, something seems to be wrong with the recent jar verson numbers. Please check! FileBot.jar 2016-04-22 35.9 MB 146146 weekly downloads i filebot-r3894.jar 2016-04-22 35.9 MB 44 weekly downloads i filebot-r3884.jar 2016-04-20 35.9 MB 22 weekly downloads i filebot-r3883.jar 2016-04-20 35.9 MB 11 wee...

Thanks!