• 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.

The Tunnel - Season 2 not ripped properly

thetoad

Well-Known Member
Thread Starter
Joined
Aug 3, 2016
Messages
146
Likes
6
So I've ripped The Tunnel - Season 2 and its not ripped properly.

0) it seems to remove the java code in totality (which isn't bad, just impacts the rest of the playback), but also leaves it behind. It removes the 1GB file that contains the jar with the extra/needed class that the java code uses for security measures

so the rest applies only to HDMV code as that's all that remains

1) It doesn't remove the PSR20 check in the first play movie object

2) the first play move object jump's to title (8/9 depending on disc) which tries to jump to title 65535 (which doesn't exist, changing it to 0 or changing the first play to same as top menu gets it to top menu). So no where to jump to, so it just hangs (at least can press top menu button and get there)

3) with that, I haven't play tested to see if it now picks the right playlists, but it doesn't play the "trailers" anymore up front (don't know if that was played by the java code, before handing it back off to the HDMV code, perhaps the way its security works is that the java code played with registers and the HDMV code picks a playlist based on said registers). perhaps getting rid of the java code got rid of the trailer playback.

the above analysis applies to all 3 discs.
 
So I've ripped The Tunnel - Season 2 and its not ripped properly.

0) it seems to remove the java code in totality (which isn't bad, just impacts the rest of the playback), but also leaves it behind. It removes the 1GB file that contains the jar with the extra/needed class that the java code uses for security measures

so the rest applies only to HDMV code as that's all that remains

1) It doesn't remove the PSR20 check in the first play movie object

2) the first play move object jump's to title (8/9 depending on disc) which tries to jump to title 65535 (which doesn't exist, changing it to 0 or changing the first play to same as top menu gets it to top menu). So no where to jump to, so it just hangs (at least can press top menu button and get there)

3) with that, I haven't play tested to see if it now picks the right playlists, but it doesn't play the "trailers" anymore up front (don't know if that was played by the java code, before handing it back off to the HDMV code, perhaps the way its security works is that the java code played with registers and the HDMV code picks a playlist based on said registers). perhaps getting rid of the java code got rid of the trailer playback.

the above analysis applies to all 3 discs.
Can you please post AnyDVD logfiles of these discs? Thank you!
 
Context: This is a disc image I imaged in linux (ddrescue -b 2048, as was having some hard time reading) on a non bus encrypted disc (otherwise wouldn't have resulted in playable m2ts files) and then mounted within a windows VM with dvdfab's virtual drive. (Basically, I've been using other tools to do my bluray decryption and a lot of my own hand spun fixes, as one can see based on above) but wanted to experiment with a new workflow with a windows VM and anydvd to see if it could make my life easier for harder discs (such as screenpass based ones). I don't think the windows VM should really change anything in this case.

edit: updated with all logs. and updated initial log as it was from a broken iso (doesn't change my analysis)
 

Attachments

  • AnyDVD_8.2.1.0_Info_E_THE_TUNNEL_SEASON_02_DISC_01.ziplog
    1.4 MB · Views: 13
  • AnyDVD_8.2.1.0_Info_F_THE_TUNNEL_SEASON_02_DISC_02.ziplog
    1.8 MB · Views: 3
  • AnyDVD_8.2.1.0_Info_G_THE_TUNNEL_SEASON_02_DISC_03.ziplog
    1.8 MB · Views: 2
Last edited:
The Vietnam War - 10 Disc series suffers in the same way with the jump to title 65535, though it patches out PSR20 correctly (HDMV code of the resulting rips looks very similar)
 
1) It doesn't remove the PSR20 check in the first play movie object
Regarding that: according to your log files, you don't have region code removal active in AnyDVD, so the result is to be expected.

About the other phenomena, can you please create AnyDVD log files from your copies, for me to compare to the original?
 
hmm, you are correct. I don't recall every unchecking the remove region code box. but it was unchecked. Is that the default?

Can I just upload the MovieObject.bdmv file (I don't have them ISOd up yet, in practice as these have the java code excised, that's all that should matter)
 
unchecked bd region removal is default yes
 
Poldark - Season 3 behaves the same way. Ex: Disc 1 first play title jumps to title 12 which sets up the registers for the playlists, but then tries to jump to playlist 65535 (as with the other PBS titles recently)
 
and finally understand it. Instead of jumping to 65535, it should be jumping to the first play movie object. There isn't a title that corresponds to it (perhaps hence why the 65535?). I create such a title, replace the jump title 65535 to my new title (14) and everything seems to play perfectly (Seems, as fingers are crossed that the right playlist was chosen)
 
and finally understand it. Instead of jumping to 65535, it should be jumping to the first play movie object. There isn't a title that corresponds to it (perhaps hence why the 65535?). I create such a title, replace the jump title 65535 to my new title (14) and everything seems to play perfectly (Seems, as fingers are crossed that the right playlist was chosen)

65535 is the first play title.
The behaviour is really correct - Screen Pass starts up normally with firstplay, checks whether all registers had been set up, if not - does its thing and then starts over by jumping to the firstplay title (65535).
AnyDVD leaves this basic behaviour intact, but modifies the "does its thing" part.

So technically, there's nothing wrong.
Your trouble must have a different cause, I'll try to find out.
 
OK, did some testing now.
Using The Tunnel Season 2, disk 1

I'll just go through your original post and summarize:

0) it seems to remove the java code in totality (which isn't bad, just impacts the rest of the playback), but also leaves it behind. It removes the 1GB file that contains the jar with the extra/needed class that the java code uses for security measures

Yes, that is correct and the way it should be. And no, it doesn't impact the rest of the playback.
This disc was originally authored without BD-J.
Java has only been added for Screen Pass, which makes an enormous fuss about setting a handful of GPR registers.
AnyDVD takes BD-J completely out of the picture and replaces it with a single movie object, that simply sets up the GPRs, then restarts with first play (as the BD-J code would have done as well).

So what AnyDVD did, was to replace BD-J with a simpler HDMV object, that does - effectively - exactly the same thing as the original BD-J. Just without the whole checking for decryption fuss.

1) It doesn't remove the PSR20 check in the first play movie object
OK, that has been clarified, your region code removal was switched off.
That is the default setting, because region code removal usually requires user interaction to identify the region of the disc and most people don't require removal.

2) the first play move object jump's to title (8/9 depending on disc) which tries to jump to title 65535 (which doesn't exist, changing it to 0 or changing the first play to same as top menu gets it to top menu). So no where to jump to, so it just hangs (at least can press top menu button and get there)

As I already wrote in the previous post: jumping to 65535 (first play) is the correct behaviour.
The reason for this is, that the Screen Pass guys add their junk after the disc has been authored. So they add a couple of checks at the beginning of the firstplay mobj, do their thing first, and then need to restart firstplay, to be sure the "original" firstplay commands get executed. Hence the jumping to firstplay again.
(There are some discs, where the jump goes directly to a different title, those probably had a very simple firstplay object to begin with).

3) with that, I haven't play tested to see if it now picks the right playlists, but it doesn't play the "trailers" anymore up front (don't know if that was played by the java code, before handing it back off to the HDMV code, perhaps the way its security works is that the java code played with registers and the HDMV code picks a playlist based on said registers). perhaps getting rid of the java code got rid of the trailer playback.

Yes, of course, if you modify it to jump direclty to title 0 (menu), then it will skip the trailers. You told the disc to go directly to the main menu.


All that said - I tested it on 4 different players (3 settop models and PowerDVD 16).
It played fine on all of them.

So I can only conclude, that your player is the problem here (Dune, was it? That one is known to be touchy).
The HDMV code is very simple - I don't see any excuse for a player to hang.
Maybe the Dune guys didn't implement the "jump to firstplay" correctly? It is a valid command, but it is rarely used, except by Screen Pass protection and, for the same reasons, by BD+ (both add code after authoring).

A workaround might be (something you should be able to do with BDEdit): add a new title and assign the HDMV-Mobj that firstplay points to.
Then have "AnyDVD's" mobj jump to that instead of to 65535. It should execute the same commands then and maybe not confuse your Dune.

But I'm hesitant to make this a general workaround, because you can probably see, that the MovieObject #0 queries PSR4 (title number) and stores is in GPR593.
In this case, I'm pretty sure, it is only being stored, so the Screen Pass BD-J code knows later on what title to jump to when done (65535=firstplay).
Since that code is not being used any more, there should be no side effect.
But it is possible, that a disc goes haywire, if that PSR4 does not point to 65535 as expected. Unlikely, though.

So, if you want to try that, please do and report.
If it works, then, we'll think about whether there's a safe way to implement it in AnyDVD.
 
so, 65535 is first play? ok, learn something new (bdedit has always listed 0 as top menu, didn't realize 65535 is first play, as bdedit didn't give it a title #).

If that's the case, I'll experiment a bit more (stick a play playlist in the first play movie object as the first vm command and see if it plays multiple times through).

The workaround you describe is exactly what I did above :)

As you mentioned bd+, I'm now wondering if that's the same problem I'm having with the bd+ titles that I mentioned in my other thread (patti cakes et al).

thanks for the in depth explanation.
 
I've created a small test case that duplicates the behavior, i.e.

object 0 - plays a playlist 'a' jumps to title 1
object 1 (title 1) - plays a playlist 'b' jumps to title 65535

plays playlist a and b in order, but doesn't keep on playing them.

It be interesting (but perhaps difficult, especially for the java code?) an valuable (to at least me, but perhaps other players suffer from this bug) if you could catch every jump title to 65535 and replace it with either a either a jump object (to same object as first play title) or to a new title you create that is the same object as first play title. While I can easily fix this manually for HDMV code, I don't have the tools or knowledge (at least yet) to rewrite the java code (along with all the signing that might have to be done) to get it to work for java code.

I'm going to report it to dune, but I really doubt I'll get any positive response. I figure they don't even have the source code to the bluray playack engine but just shipped whatever sigma provided them.

Is this something that you guys view within anydvd's purview (i.e. fixing discs to play on buggy players) or outside of it?

if it is, I have other fix concepts I can throw your way as well (Recent fix: Gotham S3 has huge PNGs that cause multiple players to hang trying to load, however resave them with highest PNG compression, reducing their size by over 50% and everything is good)

anyways, just wondering what your guys thoughts on this is. My guess is that you would have to interpose on BDLocator which might be difficult (not just stubbing out a function, but a whole class?)
 
The workaround you describe is exactly what I did above
Are you sure?
The way I understood it, you replaced the jump to 65535 (FP) by a jump to 0 (menu) - therefore skipping the initialization and the trailers.

What I meant was a bit more like:
  1. add a new title, HDMV, set the associated MovieObject to the same one used by FirstPlay (I think it was 0)
  2. change the original jump to 65535 to a jump to the newly created title in step 1
That combination should run normally and also play all trailers.

plays playlist a and b in order, but doesn't keep on playing them.
That seems to confirm my suspicion.

As you mentioned bd+, I'm now wondering if that's the same problem I'm having with the bd+ titles that I mentioned in my other thread
Likely yes, if Dune really has trouble jumping to firstplay.
Because the same thing happens with BD+ discs.

I'm going to report it to dune, but I really doubt I'll get any positive response. I figure they don't even have the source code to the bluray playack engine but just shipped whatever sigma provided them.
Dune sales certainly benefit heavily from people using AnyDVD, so I think, they should be willing to listen.
The Dune player has been known to hang occasionally for years now on discs that otherwise play fine on other players.
Now, with a precise bug report including a clear analysis of the cause (which didn't exist before), I'd assume, they would be inclined to get this fixed.

Is this something that you guys view within anydvd's purview (i.e. fixing discs to play on buggy players) or outside of it?
Generally yes - as long as it doesn't fix playback for a few discs on a certain player at the expense of breaking playback for other discs entirely.

If you can confirm, that you tried the exact workaround I described here (not only change the jump destination, but also replicate firstplay through another title) and playback on your Dune was fine (including all the trailers, etc...), we can consider it.
 
Originally, I did the jump to main title (and currently my only fix for BD+ discs that no longer work).

But then when taught me what 65535 meant (And also confirmed in libbluray, but now wondering if it handles 65534 for resume now right as well, though I see resume in a bunch of bdj titles, always thought it was a bdj function, not a more basic function) I changed my fix to create a new title with the same movie object (though in practice just switching the jump title to a jump object with the right object probably would have been good enough, assuming dune supports jump object, didn't try it) and it seemed to work correctly, and I mentioned, I can make the fix easily for hdmv code, but can't make it for java code easily (though learning)

If you build a fix, I'm willing to test.

I tried following up with Dune, but don't really know how to get to their technical side, the sales side I was reaching was essentially like "old product that we dont sell anymore, sorry". You guys might have better connections.
 
I'll tweak my test later to have 2 set of movieobject/index one that has 2 (65535 and 1) titles for 2 objects and 1 jumps to 65535 and the other that has 3 titles (65535, 1, 2) to 2 objects (65535 and 2 are the same object) are and 1 will jump to 2 instead of 65535

I'll upload them both so you can verify and perhaps give to other people with Dune's (also might be a useful test for others in future with different players, "if you don't see these videos play in order, your player is broken in this way, enable this feature of anydvd...."
 
so I'm also going to experiment with patti cakes. decompiling 03001.java I see that 65535 is mentioned a few times, a few important times seem to be

dg.java: public static final int dr = 65535; (though doesn't seem to be used anywhere else, unless I missed it)

ds.java: this.requiredTitle = 65535; (ds extends ln)

o.java has it twice, but don't see anything else using it)

if I had to guess ds.java is the important one and I'll try changing it via bytecode editing to point the new title I create that points to the same object as first play. though, as noted this is mostely shooting in the dark, the best way is to wrap bdlocator, but that's more involved than my java modification ability enables at this time.

though digging into it deeper, 88888.jar seems to be where the bd+ code is, and this line concerns me

cj.java: if (RegisterAccess.getInstance().getPSR(4) == 65535)

i.e. would changing the title to something not 65535 will change PSR4 to something that is not 65535 and hence cause that line to fail?

further see other access to PSR4 and comparisons against 65535 in other parts of the bd+ code.
 
Last edited:
This is going to be my full test case, just want to run it by you guys. 2 constructed folders, t1 with 2 titles (first play and another) and the t2 with 3 titles (first play, the other and a 3rd with the same object as first play).

my expectation is that on the dune t1 should die, and t2 should keep flipping between the 2 titles.

reasonable test?
 
and tested. t1 dies after first play through. t2 repeats as expected. My Main Q now is what would need to be done to get it to work with java. You probably also want to handle PSR4 in hdmv code.
 
PBS's Masterpiece - The Collection suffers in the same way (i.e. they are doing the same thing with all their releases) At least its easy enough to fix with bdedit now.
 
Back
Top