Host handler showing up as disabled in panel


#5

Without any console information it’s a bit hard to debug, it’s working fine on my end, but it could have been a small glitch or a real bug. Anyway, if it ever happens again, please check your browser console for any errors. As for your host history, the module will not keep track of hosts when it is disabled, this feature is also off by default and auto-hosts aren’t tracked. Not sure if you had any data before your module got disabled, if so, the table might be corrupted. You can also check your browser console for any errors when clicking the tab.

I also noticed that you’re not on the latest version (2.3.9.1), an update could fix issues like this. Sometimes we make small changes and that don’t make it to the changelog.


#6

Just a quick update on this. The module is consistently disabling its self and not functioning as intended. I’ve yet to update the bot as that requires a restart and I’m consistently having week long giveaway raffles which make it so I can’t reboot or update the bot without everyone that bought a raffle ticket from losing out. Does anything think that this module was updated in the last release? I would hope future changelogs include everything, and with this module behaving so badly it would seem a fix for it would warrant an update in the change log, so I’m assuming it has not been fixed.

I’ve not seen any console errors yet. The module just shows up as disabled every so often, and never seems to work for long before disabling again.


#7

I’ve updated to the latest build, and this issue is still happening. Not seeing any errors, but host alerts module is consistently disabling and never triggering. Wish there was more info I could provide to help debug. It’s possible that it is disabling when the bot reboots, but that’s not something i’m able to test now due to an ongoing raffle that would lose its data.


#8

Can you use the !module enable command to see if it keeps it enabled? I wonder if it’s a bug in the panel. Also, when it shows as disable try using one of the host commands and see if those work.

edit:
If that doesn’t work, please send me your database via a message so I can test.


#9

I used the module command to enable it, and it showed up as enabled but I never saw it function (no bot alerts for hosts)

Now it’s once again not showing up as enabled. I’ll send a copy of my database file to you!


#10

So last night I was finally able to shut down the bot (no week long giveaway at the moment so I can restart without losing data) and update the DB file to set the enabled status of the host module to true. After booting the bot, I opened the web panel and noticed that the hosting module still shows as disabled, even though we updated the DB file. I then opened the DB file again (while the bot was still running) to see if that value had changed, and it was still set to true.

I’ve never modified any of the core files, so this is a vanilla 2.3.9.1 bot. I’ve only made minor updates to the language file for adventures.

Any other debugging steps I can do on my end?


#11

I would say send a copy of the database file, if you haven’t. I am perplexed. Perhaps the edit isn’t taking or the journal mechanism we use is causing some oddities with the editing of the file.


#12

I sent a copy of the DB file to ScaniaTV before, who then modified it to update the module status value. However my bot was live at the time, so that’s why I repeated the same steps last night when I could take the bot offline for a bit.

Is it possible that copying a journal file over when upgrading the bot in the past could have caused this type of issue? Would deleting the journal file and rebooting the bot be of any value? I’m not familiar with how the journal setup is implemented.

It’s an odd bug for sure! :smiley:


#13

There is a good chance with the WAL journal that we use now to improve performance would, in fact, rollback a change. Essentially, Sqlite will look at the WAL to figure out what is “missing” from the database that might not have been written back in. It is not promised to write out either during shutdown (helps performance) as it will load the WAL when it sees fit in doing so.


#14

I upgraded to the latest version of the bot, and the issues seem to persist. During the upgrade I copied over the DB file, but not the journal. Once the bot launched the host handler module once again showed up as disabled. I enabled it and am still not seeing any host alerts.

I also noticed after upgrading that the Stream Elements module (which was enabled prior to the upgrade) was disabled as well. Waiting for a tip event to see if that is working or not now.


#15

StreamElements now requires you to specify your account identification number, if this isn’t specified in the API call, they will return an error and the module will then automatically be disabled. This has been said in the patch notes. You can take a look at this guide to add your account identification number and then re-enabled the module once you’ve done that.

As for you host handler issues, I would recommend creating a new caster oauth token on our main site (PhantomBot | Connect with Twitch) and see if that solves your issues with that module. If the token is bad, the module will disable itself like the StreamElements one. This will be logged as an error too.


#16

Yeah, that’s why I was confused about StreamElements being disabled since I did define my account ID number. (I added that number to my config file weeks before the update)

For the host handler issue. If to oauth token is bad, would the only module to disable be the host handler? Because all my other handlers are working without auto disabling or other issues.


#17

As of right now the only handler that uses your caster oauth is the host module. I have no idea why your modules would disable randomly without any errors being thrown, that doesn’t really make sense. Double check your logs folder for any errors please.


#18

There is a reoccurring error in the logs every 10 min:

[02-08-2018 @ 02:52:33.257 GMT] org.mozilla.javascript.EcmaError: TypeError: Cannot read property “0” from undefined (permissions.js#616)
at org.mozilla.javascript.ScriptRuntime.constructError(ScriptRuntime.java:3951)
at org.mozilla.javascript.ScriptRuntime.constructError(ScriptRuntime.java:3929)
at org.mozilla.javascript.ScriptRuntime.typeError(ScriptRuntime.java:3962)
at org.mozilla.javascript.ScriptRuntime.typeError2(ScriptRuntime.java:3981)
at org.mozilla.javascript.ScriptRuntime.undefReadError(ScriptRuntime.java:3993)
at org.mozilla.javascript.ScriptRuntime.getObjectElem(ScriptRuntime.java:1453)
at org.mozilla.javascript.gen.permissions_js_88._c_anonymous_44(permissions.js:616)
at org.mozilla.javascript.gen.permissions_js_88.call(permissions.js)
at org.mozilla.javascript.ContextFactory.doTopCall(ContextFactory.java:393)
at org.mozilla.javascript.ScriptRuntime.doTopCall(ScriptRuntime.java:3282)
at org.mozilla.javascript.gen.permissions_js_88.call(permissions.js)
at org.mozilla.javascript.Context$1.run(Context.java:490)
at org.mozilla.javascript.Context.call(Context.java:501)
at org.mozilla.javascript.Context.call(Context.java:488)
at org.mozilla.javascript.JavaAdapter.callMethod(JavaAdapter.java:576)
at adapter1.run()
at java.util.TimerThread.mainLoop(Timer.java:555)
at java.util.TimerThread.run(Timer.java:505)

And a few days ago there was this one quite frequently:

[02-06-2018 @ 00:19:55.363 GMT] java.lang.NullPointerException
at tv.phantombot.event.EventBus.post(EventBus.java:64)
at tv.phantombot.console.ConsoleInputListener.run(ConsoleInputListener.java:32)


#19

The first one has been fixed in the last release, as for the last one, it has been fixed in the current nightly.


#20

I do see a way to reproduce the first one however it shouldn’t cause any of your issues.


#21

So last night I generated a new OAuth token to see if that would address the host handler issue, and sadly it did not help. Just in case I screwed something up, here are the steps I followed.

I went to PhantomBot | Connect with Twitch and authorized the connection to generate the key.

I then entered the key in the bot console as follows:

apioauth oauth:XXXXXXXXXXXXXXXXXXXXXXX

Then I re-launched the bot, as entering that command shuts the bot down.

Once the bot rebooted the host handler module was disabled again, so I once again re-enabled it.

I streamed and had many hosts, with no bot reaction.

I’m not seeing any errors in the logs, and the bot console did not appear to show any errors. (at least during boot, I was not able to monitor it during the stream)

Any other debug steps you folks can think of?

Thanks again for the help!


#22

So, when the bot starts, if you have the module enabled:

[02-14-2018 @ 22:08:19.960 MST] Channel Joined [#notillusionaryone]
[02-14-2018 @ 22:08:20.052 MST] illusionarybot ready!
[02-14-2018 @ 22:08:20.252 MST] Connected to Twitch Host Data Feed    <--------
[02-14-2018 @ 22:08:20.786 MST] Connected to Twitch Moderation Data Feed

If not, enable the module, reboot and look to make sure there is not an error:

[02-14-2018 @ 22:11:06.586 MST] Connecting to Twitch WS-IRC Server (SSL) [irc-ws.chat.twitch.tv]
[02-14-2018 @ 22:11:06.824 MST] Connected to [email protected] (SSL)
[02-14-2018 @ 22:11:06.908 MST] Channel Joined [#notillusionaryone]
[02-14-2018 @ 22:11:07.003 MST] illusionarybot ready!
[02-14-2018 @ 22:11:07.252 MST] 
[02-14-2018 @ 22:11:07.252 MST] API OAuth not allowed to gather host data.
[02-14-2018 @ 22:11:07.252 MST] Please obtain new API OAuth at: https://phantombot.tv/oauth
[02-14-2018 @ 22:11:07.252 MST] Now disabling host module.
[02-14-2018 @ 22:11:07.252 MST] 

That doesn’t get written to logs, only to the Console. I am not sure what else to check for other than putting in debug statements into the parser for the WS Host and you run a special jar file to see what it says. I checked mine, and the only way I got the above error was to damage my API key (I put in all 'a’s)


#23

After the latest bot upgrade and updating OAuth things seem to finally been working. PHEW!

I’m seeing host and auto host announcements, which is fantastic. This was quite the journey.

Thanks so much!


#24

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.