New nag screen.

[Kneit0r]

A new nag overlay appeared.

[cremor]

I also got a account selection screen every time I opened the app for the last few weeks. But a few days ago it stopped again. So I assume YouTube fixed something on their side.

[menotuu]

so,its from youtube not from the webos app?

[bebach8]

Every time when app is used there is screen for account selection. It does not go away like cremor wrote above.

[cremor]

Yeah, it also returned for me a few days ago. Seems like YouTube is testing something.

[Dibrom2]

Yep same here, I get this too and it seems consistent, doesn't go away or isn't intermittent. Can't test whether it happens also with standard YT app because all my TV's run YTAF. Thank you for starting the thread about it so I know it's not just me.

[gartnera]

Here's some rough javascript that automatically presses enter (middle button) if that screen is detected. Not exactly sure how/where to integrate it into this project properly though. I only tested it in the chrome inspector console.

function triggerEnterEvent(type) {
    const keyCode = 13;
    const which = 13;
    const event = new KeyboardEvent(type, {
        bubbles: true,
        cancelable: true,
        key: 'Enter',
        code: 'Enter'
    });

    Object.defineProperty(event, 'keyCode', { get: () => keyCode });
    Object.defineProperty(event, 'which', { get: () => which });

    document.activeElement.dispatchEvent(event);
}

setInterval(() => {
    if (document.activeElement && document.activeElement.classList.contains('ytLrCarouselAccountTile')) {
        triggerEnterEvent('keyup');
    }
}, 100)

Update: note that this doesn't differentiate between the automatic account selector pop up and the normal account switcher. The automatic account switcher seems to pop up after like an hour of inactivity so you do need to keep running this in the background forever. Or maybe run it in a mutation observer idk.

[cremor]

@gartnera The re-appearing account selection screen might be annoying, but there are cases when you do want to select/switch an account. So if something like this is added then it must not be enabled by default. Or it has to differentiate between the new annoying screen and the older, manually opened, screens.

[Kneit0r]

@gartnera The re-appearing account selection screen might be annoying, but there are cases when you do want to select/switch an account. So if something like this is added then it must not be enabled by default. Or it has to differentiate between the new annoying screen and the older, manually opened, screens.

No, this can be safely removed, it's an added nudge to get people to create an account, you can just log in like before, nothing has changed, just this nuisance is pushed. It's a script that runs at startup, and if you exit the app, and restart it, it dissapears.

[cremor]

Ok, sorry. I missed that this only runs once on startup.

[bebach8]

Ok, sorry. I missed that this only runs once on startup.

It runs at every startup, even if app is loaded in TVs memory. If you use YTAF and switch to any other app (LiveTV, Jellyfin, Emby, basicaly anything) login selection screen appears again when you return to using YTAF. Before this started to happen when you paused video in YTAF application you could go to LiveTV watch something and return to YTAF and it resumed paused video without problem. This is not how you could use app anymore because when you switch back to YTAF it shows account selection screen and everything is reset.

[Dibrom2]

Try this out - https://github.com/NicholasBly/youtube-webos/actions/runs/16094657777

Made some changes to autologin that should auto log you in throughout using the app instead of only at startup. However there is no delay to this so you might see the page very quickly disappear or not see it at all. Let me know how it goes 👍

Been testing this all week and can report it works sometimes but equally as much it doesn't work other times. I've been trying all sorts of different things to try and narrow down when it doesn't work vs when it does work, but none of this testing has revealed the cause to me.

I've tried starting YTAF using the GUI menu tile button; I've tried starting it via a Quickstart custom remote button (I use numerical button '7' to do this); I've tried kickstarting it using the Launch button in webOS Dev Manager on a connected computer, but none of these methods seem to be the determining factor in when it will work vs when it won't.

I simply do not have the technical know how, the diagnostic tools or the coding knowledge necessary to troubleshoot this any further. I have tested it on multiple screens (3 different models) running two different releases of webOS, but even that seems to make no difference to the behaviour either. All three screens all behave the same way with regard this issue on YTAF startup with the nag login menu screen.

I have thought of one thing that if it could be implemented code-wise, then it might solve the problem. There is a very old freeware program called PTFB (Push the Freakin' Button!) which is nothing more than a system tray resident application that does what it says in the name in simulating mouse button presses for annoyances just like this one. An option within PTFB is called 'Allow action to repeat?'

It basically means, if the trigger for a button push is met, then continually press the required button over and over again repeatedly until the trigger goes away. In PTFB the default action is a single once only button press. The optional selection is 'Allow action to repeat?'

I'm not a coder, so I have no idea if this is even possible to implement. It's just the only thing I can think of after a week of testing that might solve the problem and make the modification work reliably. HTH

[NicholasBly]

Been testing this all week and can report it works sometimes but equally as much it doesn't work other times. I've been trying all sorts of different things to try and narrow down when it doesn't work vs when it does work, but none of this testing has revealed the cause to me.

While doing all my testing on the LG webOS Simulator 24, I have realized that auto login sometimes doesn't work on the actual TV and my newest feature, the 2x speed modifier works on the simulator perfectly but does not on the TV. TV is LG G4. For the auto login, I believe the issue is that the TV is injecting the userscript extremely early, likely before YouTube app even loads, and the auto login isn't able to detect the login screen properly, as it only checks if there's a login screen when the body class changes (i.e., a video is loaded, and you exit out of a video, it checks because the page is now different). Basically launching the app, the script doesn't see a login screen, so it doesn't do anything, then the YouTube app loads into the login screen which was just skipped, and it won't login because the body hasn't changed. For now I think the solution is to delay the autologin by a few seconds at startup. However I can't guarantee it's a perfect solution because everyone has different LG TVs with different processors and slower networks so the app might take longer to load than others.

I will primarily be testing on the TV itself for these two issues which will be a lot slower because I am in another room pushing updates to the TV. Extremely annoying that the LG simulator itself is not even closely related to the actual TV. Thanks for your patience, hopefully I have a fix to test within the next couple days.

[Dibrom2]

While doing all my testing on the LG webOS Simulator 24, I have realized that auto login sometimes doesn't work on the actual TV and my newest feature, the 2x speed modifier works on the simulator perfectly but does not on the TV. TV is LG G4. For the auto login, I believe the issue is that the TV is injecting the userscript extremely early, likely before YouTube app even loads

Even as a coding logic free numpty who knows nothing of what you do, it is my gut feel based on nothing I can actually quantify or prove, that this assessment is right.

I only say this because I have noticed that when the network is operating particularly quickly and without delay or hesitation with a very low Ping number, is when the YTAF app loads quickly and the login screen never appears. By contrast, it is when there is a 1000-1500ms estimated black screen delay before the YT loading screen with the logo appears before the app starts properly, is when the login screen will for sure always appear and not go away automatically.

I know this is an incredibly crude description of what's going on, but it's all I can provide by way of help.

FWIW I do use DNSBench and have configured my TVs to use the fastest possible local DNS servers for the connection they are using, so I believe I'm doing all I can to make the connection as fast as possible for them, but clearly it's still not good enough. All TVs I test on are directly connected via CAT5/6 cable and have their wifi receivers switched off.

[NicholasBly]

@Dibrom2 Feel free to test this version for auto login. I tweaked a couple things. Increased the rate to 15 seconds from 10 on startup and tweaked the button press, as I missed a keypress event. Also, I have realized that some versions of webOS have different button codes, so I will have to figure out how to make the script identify which webOS version it is, and use the correct button codes. That might also be the issue itself for some people.

https://github.com/NicholasBly/youtube-webos/actions/runs/16241196708

[Dibrom2]

Testing now. Early signs are good. Working so far on both a webOS 6.5 TV and webOS 24 one. Will keep testing over several more days before reporting back.

[NicholasBly]

Testing now. Early signs are good. Working so far on both a webOS 6.5 TV and webOS 24 one. Will keep testing over several more days before reporting back.

Looks good on the webOS simulator. Detects the account selector screen and presses the scroll wheel / enter key to bypass it.

[Dibrom2]

Sad to report after a few days that this fix still doesn't work reliably. It's better than before most certainly, but still only works maybe 50% of the time. I'll definitely take a fix that works 1 out of every 2 Youtube starts over no fix at all, don't get me wrong, but it's not a reliable solution. Worse still is that I still have no idea why this is, nor what combination of starting methods is causing the issue.

[manuelgrabowski]

For what it's worth, it has been 100% reliable for me in the last seven days – I'd guess on average it had to kick in around three to five times per day. This is on an OLED55BX9LB with webOS 5.6.1.

[NicholasBly]

Sad to report after a few days that this fix still doesn't work reliably. It's better than before most certainly, but still only works maybe 50% of the time. I'll definitely take a fix that works 1 out of every 2 Youtube starts over no fix at all, don't get me wrong, but it's not a reliable solution. Worse still is that I still have no idea why this is, nor what combination of starting methods is causing the issue.

I've tested it on LG G4 and it doesn't work at all. But I test it on webOS simulator and it works 100% of the time. Both running the same software. Been brainstorming why this is the case, don't really know for sure. I think my next step is writing more code that performs the button presses, waits half a second, and check whether the login screen is still active, and try another set of button codes if it hasn't bypassed the login screen yet. I'll have to figure out if I can SSH to my TV to read the logs to see why it's not working.

[Kneit0r]

It seems to be a time based trigger, when at first it pops up, i exit the client by pressing and holding the back button. I then start it again, and the nagg screen is gone.

Same as with that other one, that appears at the right side of the screen, pausing the video, nagging you to log in, which also seems to be on a timer.

Maybe you could look if it indeed updates a timestamp somewhere, possibly a cookie, and edit/update it beforehand at startup?

Put in a js whatcher script perhaps that on an interval updates the variable it checks, or something like that?

[NicholasBly]

Same as with that other one, that appears at the right side of the screen, pausing the video, nagging you to log in, which also seems to be on a timer.

Now this I've never heard of. Would you be able to take a picture of it next time it happens? That's insane.

[Kneit0r]

Same as with that other one, that appears at the right side of the screen, pausing the video, nagging you to log in, which also seems to be on a timer.

Now this I've never heard of. Would you be able to take a picture of it next time it happens? That's insane.

https://github.com/webosbrew/youtube-webos/issues/195

[NicholasBly]

Alright might have got something. Within local storage in-app there's a key called "yt.leanback.default::AUTONAV_FOR_LIVING_ROOM"

Default value is: {"data":{"guest":true,"<account_id>":false}}

While having the popup login screen, I changed the account value to true, killed the app, reloaded, and it signed me in instantly. I'll try logging in tomorrow to see if that's the case. Pretty exciting.

[NicholasBly]

Here's a test build that modifies this value from false to true, if you want to test - https://github.com/NicholasBly/youtube-webos/actions/runs/16397815649

Once it runs once, restart the app, and it should save. Check to see if the login screen appears again after this point

[Kneit0r]

Here's a test build that modifies this value from false to true, if you want to test - https://github.com/NicholasBly/youtube-webos/actions/runs/16397815649

Once it runs once, restart the app, and it should save. Check to see if the login screen appears again after this point

I use a fork, will see if i can add your code to it and test it, let you know. Edit: oh, you made an .ipk, can't you just make a commit instead? Edit: nvm found it. Edit: trying your auto-login.js, but i think my test tv is to old, need to add it to the C1 see if it works there.

[Dibrom2]

For what it's worth, it has been 100% reliable for me in the last seven days – I'd guess on average it had to kick in around three to five times per day. This is on an OLED55BX9LB with webOS 5.6.1.

Perhaps it's a webOS version thing? I don't have any screens old enough to be running webOS 5, so I can't test this.

Same as with that other one, that appears at the right side of the screen, pausing the video, nagging you to log in

I concur, I've never seen this nag screen before either

Here's a test build that modifies this value from false to true, if you want to test

Testing now in webOS 6.5.2-41 (kisscurl-koli)

[NicholasBly]

Just opened up webos simulator today and nag screen is showing, even with the AUTONAV_FOR_LIVING_ROOM value set to true. However when I kill the app and reload, the nag screen is gone. Not entirely sure what the approach is here but a more permanent solution would likely be trying different button codes based on the webOS version.

[Dibrom2]

Only tested in webOS 6 for now, but it appears to be working after the initial nag screen showing once. After initial power on (disconnected from wall socket) and starting YTAF, the login nag screen appears straight away. Press OK and it goes away and doesn't seem to come back again for as long as the TV maintains a connection to power even if turned off (standby). If the TV is connected to a timer switch like mine is for power disconnection overnight, then the login nag is back again once the next morning when power is restored. My webOS 6 screen is not OLED, so there is no issue with running it through a timer switch to cut power overnight.

[NicholasBly]

Alright, just put out a new test version. From my research, key codes 13 and 28 are both readily provided online as the enter key, so it seems based on the webOS version, we can try sending both keys if the first attempt isn't successful.

I also tested a different method where the javascript code selects the active element (your profile icon, which is selected by default) and then perform a click on it, however it does not work, at least for me.

It's also very likely that the AUTONAV_FOR_LIVING_ROOM key does absolutely nothing, as from testing, I set the value to false after seeing the nag screen, refreshed app, and it went away on next boot. I'll keep looking at it and probably end up removing it entirely if there is no effect.

Auto Login test update:

• Auto Login enables/disables AUTONAV_FOR_LIVING_ROOM key by Auto Login checkbox state

• Auto Login looks for both WEB_PAGE_TYPE_ACCOUNT_SELECTOR (nag screen) and WEB_PAGE_TYPE_ACCOUNTS (clicking your profile icon on the top left, for testing purposes only, will be removed for the final release)

• Sends keycode 13 (enter key), waits 500ms, and checks if the login screen is still there. If it is, sends keycode 28 (other enter key code on some webOS versions)

• Should completely bypass the login screen now 🤞🤞🤞

https://github.com/NicholasBly/youtube-webos/actions/runs/16409994826

[Dibrom2]

By way of encouragement, may I just say you're DEFINITELY closing in on the solution to bypassing this login screen nag. This latest test release is by far the most successful at getting rid of the nag screen automagically most of the time. I can't put any solid numbers on it, but my gut is telling me it works maybe 85-90% of the time.

• Sometimes the screen just doesn't appear at all - perhaps YT in these instances isn't calling for the nag, I really don't know one way or another
• Other times you can tell YT is trying to push the nag because there's a bit of a black screen delay before the video tiles appear
• A third way of witnessing the nag skip is that it appears very briefly, almost as nothing more than a momentary flicker before disappearing again and then the video tiles show
• A fourth thing I've seen is that the nag screen appears fully rendered on the screen and then after maybe 1-1.5sec, almost as I'm about to push my thumb down on the remote scroll wheel, it disappears all of its own and the video tiles pop up

So far, the only time I've seen the nag screen not be cancelled automatically is after a TV power cycle. By that I mean full disconnection from cable power source. Not standby 'off' (red light still on), I mean pull the plug out of the wall and let all the capacitors drain charge kinda OFF. After such an instance and calling on YTAF to start up, I will get the nag screen pop up and it won't be cancelled.

If I have to live with this ongoing, then I can do so easily. It is far better to have the nag killed 90% of the time, than not at all.

For reference, the testing was done on both webOS 6.5 and 24. YTAF is called through a pre-programmed, long press quick menu button (7) on the remote. All testing screens are connected to internet by cable (no wifi) and all available customising check boxes in the config screen (green button) are checked and enabled.