search

vincentbernat / dashkiosk

Managing dashboards on various displays (especially those running on Android)
Other
365 stars 62 forks source link

Display ID lost after reboot #79

Closed padlefot closed 4 years ago

padlefot commented 5 years ago

Hi all, sorry if this is the wrong place to post this. I do see that this error is probably on the client/receiver end but we have not been able to find a solution as of yet so I thought I would post and ask. If there is another place that is better suited for this, please let me know and I will move it.

So, we’ve built the server manually rather than use the stock docker image for now. One ´ issue came up over the weekend that you may know how to resolve – when we reboot the intel compute stick we use as the receiver, it always comes back with a different display ID. The compute stick is not storing the cookie. We as using Google Chrome with the Porteus Kiosk OS - Do you know how to resolve that? It is probably the most serious limitation I can see for now as the other items are resolved or I can see a way to resolve in the future from outside of DashKiosk itself.

vincentbernat commented 5 years ago

When you access the receiver for the first time, the ID is stored in a cookie as well as in the URL. You can use either of these to keep the ID. If you are able to grab the URL after first connect, ensure you keep using this URL and you should keep the ID. If you cannot, open the receiver in a browser in private mode and use the URL you get there.

phedders commented 4 years ago

Hi Vincent - Could you give a little more info where to get that URL? I've been hunting high and low, doing tcpdumps etc and I'm missing something.... I want to give openlp a url with an embedded ID so that it will get recognised each time it runs.

Thanks!

vincentbernat commented 4 years ago

Open your browser in private mode (on your own workstation), enter the receiver URL and you should get a complete URL with a token. You can get as many as you need as long as you quit private mode between each attempt.

phedders commented 4 years ago

Hey thanks Vincent - That is what I was doing - both FF and Chrome.

If I go to http://IP:8081/ then it just returns http://IP:8081/receiver - I dont get any GET or POST data with the URL. I've checked in the browser debugger, urlsnarf/tcpdump etc

So I think I'm doing something wrong...

phedders commented 4 years ago

For clarity - I'm running the lastest pull from your docker rep. (I love the ease....)

Even with curl or wget:

prh-l@ohcr01:/var/www/html/db$ wget http://10.181.1.4:8081/receiver -O - --2019-11-14 08:25:10-- http://10.181.1.4:8081/receiver Connecting to 10.181.1.4:8081... connected. HTTP request sent, awaiting response... 200 OK Length: 837 [text/html] Saving to: ‘STDOUT’

2019-11-14 08:25:10 (95.1 MB/s) - written to stdout [837/837]

I dont see anything in there that would give me something equivalent to the cookie. Hence I am sure I missed the obvious...

vincentbernat commented 4 years ago

Humm, you are right. Let me investigate a bit.

vincentbernat commented 4 years ago

This is not convenient, but the following steps would work:

Alternatively, you could:

Second method is easier to understand once you did the first method. Previously, you didn't need to go through all these hops to get the appropriate URL, but the "regression" has been introduced in 40fd65a99e643f23fed5fb1d847020248ee56a0f to workaround an issue with the Android client.

phedders commented 4 years ago

Genius - thankyou :) Glad I wasnt going completely mad. I had started to try and work out how to use the cookie data from a private session - but you've beat me to it.

Cheers!

vincentbernat commented 4 years ago

I have included a simpler way in documentation by using chromium --disable-local-storage --incognito.