• AnyStream is having some DRM issues currently, Netflix is not available in HD for the time being.
    Situations like this will always happen with AnyStream: streaming providers are continuously improving their countermeasures while we try to catch up, it's an ongoing cat-and-mouse game. Please be patient and don't flood our support or forum with requests, we are working on it 24/7 to get it resolved. Thank you.

Understanding AnyDVD's java modifications

thetoad

Well-Known Member
Thread Starter
Joined
Aug 3, 2016
Messages
146
Likes
6
So as discussed in the past, my Dune has problems paying titles that want to jump to first play (0xFFFF, -1 or 65535 depending on your numbering system). So I was digging into the code to try and understan this (using jd-gui to decompile the JARs)

I ended up looking at code AnyDVD inserts, and ended up wondering if it can be corect. namely the injected getPSR function

Code:
  public int getPSR(int paramInt)

  {
    if ((paramInt == 31) && (f != Integer.MAX_VALUE)) {
      return f;
    }
    if ((this.g != 0) && (paramInt == 20)) {
      return this.g;
    }
    if ((this.h >= 0L) && (paramInt == 23)) {
      return (int)this.h;
    }
    switch (paramInt)
    {
    case 4:
    case 36:
      int i = RegisterAccess.getInstance().getPSR(paramInt);
      if (i == mtf) {
        i = 65535;
      } else if (i == mtt) {
        i = 0;
      }
      return i;
    case 102:
      return this.b;
    case 103:
      return this.c;
    case 104:
      return this.d;
    }
    return RegisterAccess.getInstance().getPSR(paramInt);
  }

the code that handles PSR4/PSR36 (PSR36 being "backup PSR4, so case statement makes sense) is what confuses me.

it calls the real getPSR function and then cmpares to both the mtt variable and the mtf variable. those variables are defined higher in the class, but are both -1 and don't seem to be modified anywhere. Is this correct? would they be defined (if needed?) at the time this class is injected into the JAR file? Does it make sense tht the i == mtt (top menu?) never gets matched in this case (as if i == -1, the if i == mtf (first play?) will match first.

I'm obviously coming at this from a place of ignorance, I figure its correct, but figure no harm in asking what's going on.

thoughts?
 
Ok, now that I wrote it down and posted it, my rubber ducky debugging https://en.wikipedia.org/wiki/Rubber_duck_debugging has perhaps made me figure it out.

This would enable you to "virtualize" what title is considered first play menu / top menu. so it could be playing title 101 which you want the java code to believe is the first play title so you'd set mtf to 101 in that case. So you'd return -1 (65535) to the caller if it was actually that physical title. similarly for top menu, can virtualize. If not virtualized (because set to -1) will just return whatever the physical title is.
 
now, I'm left wondering if this code was due to my request to virtualize jumping to first play. i.e. you'd make a new title that has the same bdjo as the first play, but change all the jumps to first pay to be to your new title, but want the java code running as the new title to believe its still the first play title, not something else.
 
Back
Top