Live Update

Live Update 4.0.1

No permission to download
Ugh. I for some reason thought XenBlock was a PE style and Russ was looking into it for you.

Sorry @Russ. I will take a look at that template error shortly. What version do you have installed?
 
Ugh. I for some reason thought XenBlock was a PE style and Russ was looking into it for you.

Sorry @Russ. I will take a look at that template error shortly. What version do you have installed?

I was scratching my head with your response a little haha :D

I'm running that 4.1.0 RC5, happens on a default style.
 
Just a little update @Chris D, none of my check boxes were checked (Tab Icon / Tab Title / Notifications API), I went to the page and checked them and the error instantly cleared. When I unchecked them all the error didn't come back.

Other users were reporting the same error on PE when I accidentally left debug on just as a heads up.
 
Last edited:
I've upgraded from 4.01 to 4.1rc5 (de-install, re-install) and all the functionality that was there before works, but I can't get the new browser notifications to work at all.
Set them on for new users and turned them on for my own settings but I never get asked permission to grant notification by the browser.
Tried in Chrome, Firefox and Safari. Even tried on a different Xenforo install, but no luck.

I know that browser notifications do work because I've turned them on for twitter.com and get the expected "permission" pop up from the browser.

Any clues as to what I could be missing?
 
Hmm... if I manually permit the site to send notifications, they start to appear.
When I switch it back to "ask" it never asks....
 
My forum is working from https://www.domain/community/ with the favicon located at https://www.domain/favicon.co.

The browser network console kept throwing an error: a request from Live Update (4.0.1) with a wrong favicon path, i.e. https://www.domain/community/favicon.co.

The error went away after changing "favicon.ico" to "https://www.domain/favicon.ico" in liveupdate_page_container.

Is this the proper way to fix it?
 
Will be doing this in a few minutes after a bit more testing :)

View attachment 127699
View attachment 127700

I really wish I had more information available than just the number of conversations/alerts, but this will do I think :)

I noticed that TAZ asked me if I would allow notifications and then had notifications like the ones shown here. How do I do this on my site?

This is the version I installed:

https://github.com/chrisdeeming/LiveUpdate/releases/tag/4.1.0-rc5

But my site is not asking me if I will allow notifications when I visit it in Chrome. Is there something else I should do?
 
That version should have it, though I think it needs to be enabled in the options

I think I found the problem. Even though under options I have "Notifications API" checked as a default user option, existing users who registered before I installed the addon still have it unchecked in their preferences. Is there any way for me to enable it for all members?
 
Sadly, I had to uninstall this addon today. I think our server is just too busy for it. Nginx was spewing errors, unable to get a connection to php at random times throughout the day. We had the timer set to 30 second updates. My server tech says this:

---------------------
Hello,

The liveupdate issue isn't with nginx it's with PHP as your are piping so
many requests to it and it's not designed for that.

So you can either optimize the plugin to squeeze more traffic, add more
server capacity or write it in a different language designed to handle
these types of concurrent requests such as nodejs with websockets.

---------------------

I guess I could try upping the timer to 2 minutes or something. Anyone else have this issue?
 
What is your forum size? Traffic, users, etc? What server are you running it on? Specs? I'm curious...I use this on a site on a VPS
 
I think one issue is the number of requests made exponentially increases with the number of open tabs.

I have a plan in mind for this but ultimately the only other mitigation is increasing the polling time. I've seen some sites go as low as 5 seconds. If someone has 10 tabs open then one user is making 120 requests every minute. 30 seconds is the default but even 60 or more isn't unreasonable.

If that still doesn't help, that's unfortunate but honestly it's the first time I've heard of anyone having to give up on it due to performance issues.

Keep watching the resource as I will work on a solution for the future.
 
This addon throws me some errors.

ErrorException: Undefined index: is_admin - library/XenForo/Visitor.php:417
Generiert durch: Unbekanntes Benutzerkonto, Heute um 17:51 Uhr
Stapelverfolgung
#0 /var/www/html/pattayaforum.net/www/forums/library/XenForo/Visitor.php(417): XenForo_Application::handlePhpError(8, 'Undefined index...', '/var/www/html/p...', 417, Array)
#1 /var/www/html/pattayaforum.net/www/forums/library/XenForo/Session.php(274): XenForo_Visitor::setup(10532, Array)
#2 /var/www/html/pattayaforum.net/www/forums/library/XenForo/Controller.php(293): XenForo_Session::startPublicSession(Object(Zend_Controller_Request_Http))
#3 /var/www/html/pattayaforum.net/www/forums/library/XenForo/Controller.php(306): XenForo_Controller->_setupSession('Index')
#4 /var/www/html/pattayaforum.net/www/forums/library/XenForo/FrontController.php(350): XenForo_Controller->preDispatch('Index', 'LiveUpdate_Cont...')
#5 /var/www/html/pattayaforum.net/www/forums/library/XenForo/FrontController.php(134): XenForo_FrontController->dispatch(Object(XenForo_RouteMatch))
#6 /var/www/html/pattayaforum.net/www/forums/index.php(13): XenForo_FrontController->run()
#7 {main}
Benötigter Status
array(3) {
["url"] => string(56) "https://www.pattayaforum.net/forums/index.php?liveupdate"
["_GET"] => array(1) {
["liveupdate"] => string(0) ""
}
["_POST"] => array(4) {
["_xfRequestUri"] => string(30) "/forums/find-new/1651830/posts"
["_xfNoRedirect"] => string(1) "1"
["_xfToken"] => string(8) "********"
["_xfResponseType"] => string(4) "json"
}
}
 
The errors here aren't actually occurring in any of the Live Update code. They're actually happening early on in the request before it actually gets to the Live Update code. And, even so, there is no "code" as such in this add-on that would cause anything like this.

I have seen something similar before but it isn't clear what the actual cause was. It could be something that's incorrectly extending the setup of the Visitor object, for example.
 
There a bunch of this errors.
Starting with many where live update is in.
Later comes some others where Feature threads are mentioned.
 
Top Bottom