Understanding AnyDVD's java modifications

Discussion in 'AnyDVD HD (Blu-ray issues)' started by thetoad, Mar 13, 2019.

  1. thetoad

    thetoad Well-Known Member

    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?
     
  2. thetoad

    thetoad Well-Known Member

    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.
     
  3. thetoad

    thetoad Well-Known Member

    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.