DJO Maverick

Log of latest media reDBManagerLog.txtcorder tests. Issue now limited to backglass monitor.

Mike, Can't attach files to PM, but here's a sample configuration using most relevant plugins. VPinballX.zip

Can now confirm the current nightly dx and gl specific builds have the exact same issue when using plugins. B2S/PUP content on 2nd and 3rd screens simply don't appear when using DBM recording.

I'm not 100% sure what the use-case for dx or gl specific builds for Windows would be post bgfx, since you can pick any backend you want in it; particularly I'm not sure they're even building gl specific nightlies for Windows at this point. But I'll check against whatever is still being made this evening. This current crop of tests was with dx11 as backend.

Followup: Without plugins on, it appears to have issue with PUP 2.0 as well. Rolling back to PUP 1.5.2 allows DBM to 'see' the content on screen again.

So not sure if you're aware, but DBM has some interesting interactions with 10.8.1. I've been putting some time into testing the plugins on Win64 BGFX. I got PBX to play nicely with them through some trial and error, however, DBM video recorder appears allergic to both flavors of B2S plugin, and the PUP plugin. With either B2S plugin, even though it will launch normally in PBX, the backglass does not load when launched from video recorder. The same is true for any PUP content with that plugin. There are no errors or oddities in the log. Maybe more strangely, if you disable the B2S and PUP plugins, thus using fallback/legacy B2S and PUP, during video recording, it will at least display accurately on the screen, but the recorded video ignores the PUP content and shows the underlying desktop through.

This is an oldie but a goodie that has seemingly raised from the dead. I remember fighting this at length in the past, pointedly on Dark Chaos at that point. It appears to be a bit more general applicability now. When using 10.8 GL (whether windows or exclusive fullscreen, doesn't matter which), loading time is terrible as it will wait for Visual Pinball Foreground Timeout, on just about anything I run. It doesn't appear to have the same issue on DX build. However, without a frontend, GL loads the same table demonstrably faster. It still is loading the backglass faster than DX, even in PBX... and presumably is loading the table in the background, but is just never being brought to the foreground until it times out. The same workaround from long ago is still in my ini (as far as launch command goes), but it is seemingly no longer effectual on GL... log.txt PinballX.ini

Changing the launch command tentatively seems to have solved focusing for the moment, with GL windowed. Still putting it through the paces for a more thorough sampling... Thanks for the workaround. Which leaves the weird behavior with the launch audio stalling loading of tables.

Related: in this same vein, throughout the afternoon I observed several tables flash from the loading video to the editor window with the loading bar still showing, despite them being fast loading tables. All of this with GL windowed. I did not studiously log it all today, however. I know it was said that nothing changed with how tables are being launched in the newer builds, but... Something has seemingly changed nonetheless.

Slight update... so this GL focus issue doesn't seem to be limited to Dark Chaos. And again, this appears new... never had it prior to current builds. I launched BTTF this morning (GL is default build), and when it loaded into the table, it never (ever) focused. I quit it and restarted the game, and THAT time it DID focus, somewhat inexplicably. log.txt

...and I'm back. GL exclusive does not change anything. DX exclusive does cause it to match load times without PBX... however, it instead creates an undesirable behavior where it rapidly brings into focus the editor window and script loading bar for the last half of the loading. log.txt

@scutters I think you found a contributing problem. Packaged launch audio for the table is 57s. Deleting it mitigates the problem, but does not resolve it. Load time is still substantially longer than without PBX (log attached), about ~40 seconds vs 20 without. B2S does seem to come up in more like 9 (I'm in a hurry and didn't have a stopwatch out), which made me wonder if it was, in fact, simply not shifting focus to the player until the timeout in the log. Still unclear when this issue cropped up. When the table first released (which was within the last couple of months), this issue didn't appear to exist, including with the launch audio. I'm going to be out of pocket for a couple of days; look forward to the brainstorms. log.txt

Tried deleting the custom loading video. No effect. log.txt

I do have latest MJR DOF (and have been keeping an eye on whether your PR is ever merged). Disabling DOF Plugin has no impact. First off, all times from open/execute command until playfield is visible and lights begin attract mode movement, and also separately measured when B2S visibly loads in, as that varied. Launched directly from within VPX 64 (GL and DX) - Identical 0:22, and B2S in at 0:09 Launched from PBX - 1:36, B2S in at 1:08 Launched from command line as Scutters instructed (GL and DX) - NEVER completes; B2S still in at 0:09, playfield first visible at 0:20 (about the same as when first visible from within VPX). The player window never achieves focus, at least in the few minutes I was willing to wait. Alt tabbing to the player window focuses it. If alt-tab to the player as soon as playfield is visible, then it completes at about the same time as launching from within the clients.

Table is here: Dark Chaos (apophis 2025) - VPX - Pinball Tables - Virtual Pinball Universe And no material changes in the 'ole ini, but added as well. PinballX.ini

This appears to be a new issue that has come about somewhere in the series of fixes to the table closing issues, but I haven't identified which build yet. Dark Chaos is a demanding table with a relatively slow load time under optimal circumstances. Loading straight from VPX (GL or DX) on my cab takes 18 seconds to playfield visible (20 sec 'til attract lights kick off). It used to launch normally through PBX. On current build, however, it takes obscenely long to load... this log is me launching it and then exiting as soon as attract lights start, so, over one minute and thirty seconds. It is showing a foreground player timeout at about one minute thirty, apparently right before it becomes visible. Looks like perhaps PBX isn't recognizing it's done loading and handing off focus properly? log.txt

So after messing with it further... as to BM, specifically, it looks like it's an issue with that table and all current versions of VPX. Seems to be coin-toss as to when the PUP loads correctly right now on GL or DX. So as to PBX issues, it closes properly like all the others at this point... Cautiously optimistic this bug is resolved, but I'll keep an eye on it. Thanks!

So with the latest version, Blood Machines PUP DMD continues to break on launch for unknown reasons, only launching the overlay. I actually tried it as the first table launched on system startup and it did work, that time only. Immediately after, Batman '66 exhibited the same issue (legacy problem). I restarted Batman and that time it worked. All closed easily at default settings, however, including BM. So to test the idea that it was related to not closing properly, I checked task manager, and no PUP process remained between runs, to no avail. I then killed PBX and observed a few oddities... 1. After having it fail in PBX, going directly through GL version continued to fail 2. Launching in in DX version, however, cleared the problem... 3. ...which led to trying again with GL, where it remained fixed 4. Then I brought back up PBX, which is using GL... and it again messed up on start. I'll experiment more later tonight. Intending to check if it is happening and persisting if first load is on GL without PBX, and also seeing if the same issue exists if that table is set to DX in PBX. log.txt

I had my hopes up for a minute... started well. BM still closing noticeably slower than others, but not as slow. It started properly the first time. I looped back to it at the end after doing the others though, and it glitched the startup again, twice in a row... perhaps suggesting another did not close cleanly somewhere in the sequence, as you said. log.txt

Interesting results with 6.83. Churning through the full suite of mandatory-pup tables here... most of them launched and closed without issue, and closed relatively briskly. Blood Machines is the new problem child of this and the prior build. On attempt 1 and attempt 4 in the log, it again mis-launched the PUP (score overlay without videos). In attempts 2 and 3, it launched appropriately. This did not happen (to my knowledge) in any build before this and the immediately prior one. The PUP DID close down, however, whether it started correctly or not... however it took much, much, much longer for this one table. The DMD screen remained active long after others went dark. The startup hitch actually used to happen on Batman '66 many, many builds back... can't recall if that was mentioned way earlier in this thread or another. Now it only affects Blood Machines. log.txt

...with somewhat inconsistent results. Restarted and retried the two current problem tables... doing Batman '66 first, it APPEARED to close properly. But then doing Blood Machines second caused something slightly different where the PUP failed to load correctly (DMD frame but no videos), and then it failed to shut down correctly as well. log.txt

6.80 is a regression on this issue it seems... Blood Machines and Batman '66 PUPs did not close out properly this time. All I tried before them seemed to be doing fine. log.txt

Happy to report... that latest dll seems to have done the trick! All of the above tables seem to now be closing cleanly and promptly. log.txt

With the new DLL, some significant changes... So most affected tables (Iron Maiden, Futurama, Blood Machines, Die Hard) the PUP now closes properly, though some quicker than others (see some still fall back to kill process). Now, instead, only in Batman '66 the PUP doesn't close, and didn't either attempt... had to kill from task manager for both attempts. Previously that was one that behaved when some others did not... log.txt

Well, as much as hate to stay on the bad news train... 6.73 actually represents a regression on my end. Last build would at least close everything except Iron Maiden reliably. This build goes back to never closing Batman '66 PUP and timing out eventually. log.txt