krpano 1.19-pr15 / pr16

  • I'm sorry to hear this about the LG browser's video mode, but not surprised. How did you determine it?

    By testing and logging ;-).
    The browser itself is just a 'full-hd' application, it doesn't utilize the 4k resolution of the TV. You can see that also by normal browsing when looking at the pixel raster. I assume this is done for performance reasons, webpage rendering in 4k would make the TV browser even slower ;-).
    This is at least the case a 2015 and a 2016 LG TV model that I've tested, maybe newer ones or TV browsers from other manufacturers are better here...

    That browser also crashes on panos with large cubeface sizes, so is really not much use.

    With multires any sizes should be possible.

    But by using the TV as a 4k 3D monitor, we should still be able to show interlaced stereo from web pages.

    Yes.

  • Hi!

    I'm experiencing some strange things with this version. Is it possible that because of the changes in encryption this viewer only accepts js/xml files encrypted with this, current version of krpanotools?

  • I'm experiencing some strange things with this version. Is it possible that because of the changes in encryption this viewer only accepts js/xml files encrypted with this, current version of krpanotools?


    No, the viewer itself is fully backward-compatible.

    That means loading files with older encryptions is always possible, only the other way doesn't work - when encrypting files with the new encryption method from 1.19-pr15/pr16, then they can't be loaded in older versions.

    But when there is a problem, please post a link to an example or send it directly to me.

    Best regards,
    Klaus

  • Klaus,

    I finally have more datapoint to submit.

    I’ve “upgraded” to pr16 and this issue still persists.

    I’m 99.99% sure what is happening here is that the system( encrypt ) command on line 25 of the code I posted in my prior/original post is erring at seemingly random times.
    I know the file that I’m trying to encrypt does exist, because of the if(file_put_contents) qualifier and the fact that the file remains because of the if ( $theoutput ) qualifier for the unlink statement. And I know the file is a valid XML file because I’ve run them through several XML validators which return the file as “clean”.

    The random description is warranted because this error CAN happen with any of 700+ tours we have that leverage the same code-set. And this can happen once and then won’t be experienced again for several days by a user. Or it might happen several times in a row.

    This error is the one place I can’t really handle for an error ( I don’t think ) because the -out=stdout echoes/writes to the file polluting the xml that could be echoed after the attempt to encrypt.

    The issue seems to be most prevalent on mobile devices, from my own testing. However I have reports of the error happening on desktop Chrome and Safari. No one has reported the error in FireFox.

    When a sess_ref cooke is available ( basically a session ID ) I’m able to back trace the error to my analytics capturing database.
    The user agents that I can directly link/verify to an error are:
    Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/65.0.3325.181 Safari/537.36
    Mozilla/5.0 (Linux; Android 8.0.0; SM-G955U1 Build/R16NW) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/66.0.3359.106 Mobile Safari/537.36
    Mozilla/5.0 (iPhone; CPU iPhone OS 11_2_1 like Mac OS X) AppleWebKit/604.4.7 (KHTML, like Gecko) Version/11.0 Mobile/15C153 Safari/604.1
    Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/65.0.3325.181 Safari/537.36
    Mozilla/5.0 (Macintosh; Intel Mac OS X 10_6_8) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/49.0.2623.112 Safari/537.36

    I personally have witnessed the error on iPhone 7+ under Safari & Chrome but can’t seem to view the error under FireFox or Edge, on this same device.

  • Dear Klaus,

    we've updated to the latest version, now the issues with the gyro are thankfully gone. However, it seems that some default behavior is changed perhaps? So far we had a code that changed (switched) the enabled property of the gyro plugin after it became available, because that's how the gyro function could be enabled automatically on startup. With the new version it seems that this changed, as our code now results in disabling it automatically.

    It's not a big issue as it was a 1-minute fix for us, just thought I'd ask if I diagnosed this correctly, as the documentation still says that the plugin is not enabled by default.

    Or maybe there's a different reason to this phenomenon, one I didn't think of?

  • Hi,

    The random description is warranted because this error CAN happen with any of 700+ tours we have that leverage the same code-set. And this can happen once and then won’t be experienced again for several days by a user. Or it might happen several times in a row.

    Sorry, but for me that sounds more like a server-side problem...
    What happens on your side when there a two requests to the same file at the same time?
    Do you do some file locking and checking for locked files to prevent any runtime conflicts?
    E.g. one PHP request process might currently write a file, while another one reads the same file...

  • Hi Klaus,

    After upgrading all the plugins to new version I get the following error which prevents anything from loading (Chrome Console Windows 10):


    Uncaught TypeError: Cannot read property 'split' of null
    at eval (eval at embedpano (krpano.js:10), <anonymous>:1:243311)
    at gd.a.registerSetterGetter (eval at embedpano (krpano.js:10), <anonymous>:1:41299)
    at Cf.G.registerplugin (eval at embedpano (krpano.js:10), <anonymous>:1:243263)
    at E (eval at embedpano (krpano.js:10), <anonymous>:1:213903)
    at gd.c.processUpdates (eval at embedpano (krpano.js:10), <anonymous>:1:224436)
    at Object.F.updateplugins (eval at embedpano (krpano.js:10), <anonymous>:1:140080)
    at yf (eval at embedpano (krpano.js:10), <anonymous>:1:30741)
    at d (eval at embedpano (krpano.js:10), <anonymous>:1:251169)

    When looking at the Sources tab in chrome dev tools on a beuatyfied version I get the following:


    l.registerSetterGetter("bgborder", function(a) {
    a = a.split(" ");
    var b = parseFloat(a[0]);
    isNaN(b) && (b = 0);
    l.border = 0 < b;
    l.borderwidth = b;
    l.bordercolor = parseInt(a[1]);
    a = parseFloat(a[2]);
    l.borderalpha = isNaN(a) ? 1 : a;
    l.mergedalpha = !1
    }, function() {
    return C.borderwidth + " " + Od(C.bordercolor) + " " + C.borderalpha
    });

    I've tried various edits in my html and xml files to debug, but have not found the issue, so help is needed :)

    The reason I've tried upgrading from pr14 was the android gyro bug.

  • According to the error you're setting 'bgborder' from a textfield to 'null' - but that must be from somewhere from a custom JS call or JS code, via the krpano XML APIs it wouldn't be possible to set a real JS-null to it.

    That means look in your JS codes for a 'bgborder = null'.

    Best regards,
    Klaus

  • Hi,

    That's just it, there is not a single js code on the whole site which contains "bgborder" at all, only krpano xml files *unsure* .

    Another possiblity would be a set(bgborder,get(xxx)) or copy(bgborder,xxx) where xxx is an undefined object.
    That means check your xml files for all 'bgborder' usage or post here a link to your example.


    you must catch such cases in your getters

    Of course - in the next release this case will be captured, it was unfortunately forgotten there, but with a correct xml code the problem wouldn't happen too.

    Best regards,
    Klaus

  • Hi Klaus,

    It seems that the output of the Protect tool has changed in this version (or maybe in pr14).

    As recently as pr13, the JavaScript output included the createPanoViewer function, and now it instead includes the embedpano function. While they're of course similar, they're not exactly the same.

    My question is: was this an intentional choice, or is this a bug in protect?

    Settings:

    • HTML5
    • FLASH
    • Branding Free
    • Limit Domains (*.example.com)




    Thanks!

  • Hi

    Quote

    While they're of course similar, they're not exactly the same.

    They are exactly the same ;-).
    The 'embedpano(obj)' function was a simple wrapper for 'createPanoViewer(obj).embed()'.

    The createPanoViewer() function was decrepated since version 1.17 and not documented anymore since that version.
    In version 1.19-pr15 large parts of the internal structure were changed and during that also the old createPanoViewer() function finally removed.


    Quote

    My question is: was this an intentional choice, or is this a bug in protect?

    That means that was intentional and that is not related to the protect tool, that's part of the core structure of the krpano viewer file.

    But if you still need the createPanoViewer function for some reason, here a wrapper for it:


    But I would recommend porting to the direct usage of the embedpano() function. That should be relatively easy in the most cases.

    Best regards,
    Klaus

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!