"Disc is region free" ...means what?

[James]

@James or @Pete can any of you step in, this back and forth debate of is/isn't setting behavior has gone on long enough.

Pete & I already have explained everything.

 

[markfilipak]

Well, I already told you, what the "region free" in the dialog box does

You have never done that. You've written some trivial IF-clauses supposedly highlighting what AnyDVD DOES NOT do, without addressing what the settings do, and then you said that what Pete wrote was definitive. I think you've spoken, and what you've written is okay, but it appears you cannot resist continuing to browbeat me. Why? Let it go, James. I want to let it go, too.

 

[Ch3vr0n]

Enough is enough, you want to let it go. Good, case closed and topic locked. You don't believe or want to believe the lead developer (James) and staff (Pete), that's your right, but they know exactly what they're saying. They're coding the damn thing.

Sent from my Nexus 7 with Tapatalk

 

[James]

You have never done that.

I even quoted it for you in the post, you replied to. In case, you have missed it.

 

[Pete]

I'd like to sum this up, because this thread is ridiculously long and full of text. I only read about 20% of it, I don't have the time for the whole thing.
For this thread to be of any use to users looking for answers to the topic, I'll write this summary.

General advice (this goes for any kind of support inquiry or other troubleshooting means): keep your questions short, omit superfluous lines or nobody will read it.
Actually, same goes for replies (and this one is going to become too long again, in hopes for not leaving any aspect out).

Summary:

Yes, the whole region fixing thing is confusing, especially if you're primed with knowledge about DVD region coding.
Forget DVDs, they work differently.

AnyDVD's dialog should maybe be improved by simply adding a line "please tell me (AnyDVD) what region this disc is from, because I have no clue", so the users know for a fact, that they are being asked for an information instead of being provided one.

• It is important to know, that Blu-ray discs DON'T have some field stored somewhere, that contains the disc's region.
  
  
• Blu-ray discs have insanely complex code (totally cracking a nut with a sledgehammer) written in binary Java - typically more than 100,000 lines of source code, just for flashing a few buttons for you to click on.
  Somewhere in this code there is a snippet, that *queries the Player's region code*. What then happens with that information is usually very complex - the examples used throughout this thread were explanatory only. Reality is more like "store some boolean value in some variable, set up more stuff on the disc and have some other thread (yes, it's multi-threading, folks!) pick it up later and launch some other classes, that will eventually read some playlist number from some database and then first play some trailers, etc.....".
  And this is - again - simplifying it.
  
  
• The point is: AnyDVD can't eradicate this "region check", it's simply too complex.
  
  
• What it can do is replace that simple query for the player's region code. But it has to know what region it is supposed to put there.
  
  
• please don't think of the situation "region mismatch" as the player refusing to play the movie.
  It's really more like the code on the disc simply deciding to show selected folks, including you, a different movie. The movie "region mismatch", not available in theatres, available exclusively on disc only for you.
  The player also thinks, it's just playing some movie then, it always strives to please you.

I've seen some of this Java. It looked pretty skeletal to me. I didn't see anything that looked like procedures, but the tool I was using might not have exposed them. But I suspect that the Java is interpreted. That would make it MPU-independent and BD drive manufacturers would only need to include an interpreter and an entry point (which would probably take a simple command line of text). Compiled code (i.e., machine code) just doesn't make sense from an engineering standpoint.

Though this makes no difference regarding the actual topic, I want to clarify this, too.
I don't know, what you saw, when you say you've seen it and it looked skeletal and nothing procedural.
You likely didn't see the Java code, maybe some file containing definitions or so, which will eventually be read by Java.
The only way to "see" BD-J (the Java code on Blu-ray discs) with human eyes, is to use a decompiler, that will turn the binary into something close to what might be similar to the original source code, but usually not so much.

Java (and I don't mean JavaScript, that's a different thing) is never interpreted.
It is always compiled into a "machine-code", the so-called Java byte-code. While it's not a machine code for which an actual CPU exists, it still is a series of low level instructions performing the most basic of operations.
Why I'm opposing the word "interpreted": almost all existing Java machines load the Java classes and then immediately transform each byte-code instruction into native instructions for the local CPU to execute. Because Java byte code is so "machine like", this translation happens pretty much in an instant. This happens only once for each class.
And from then on that translated machine code is directly executed on the CPU, so there is no interpreting going on, ever.
This is why Java executes nearly as fast as real natively compiled C++ code.