Could be a bug. Create an issue on Github (http://github.com/screenly/screenly-ose) with steps how to reproduce the issue.
We've made a fair amount of changes since then, and there were also a fair amount of changes upstream in regards to how this works.pHeoz wrote: ↑Sat Dec 23, 2017 11:44 pmHi,
I worked on Screenly OSE in 2014. Back then, I could 'pkill x' and then 'startx' to restart the player. Now, the 'startx' command is gone. How can you restart the player (= turn back on the GUI) once you've killed it ?
I noticed that when I run 'pkill x', video assets will keep playing, but webpages will fail because uzbl cannot access the GUI.
So, what's the new way to proceed ?
mchlwllmthms wrote: ↑Mon Jan 29, 2018 11:13 pmWhat the hell is going on?
The new updates to OSE have been an absolute nightmare! Am I the only one having trouble with this?
Many of the updates required me to completely re-install new images from scratch (a complete PITA because my Pi's are all over town). Even fresh installs are having connectivity issues and despite being able to SSH to them, can't get the web interface to show up (also come to find out the newest release has the web server listening on port 80 instead of 8080!... why??)
Static IP's seem to be impossible to set properly using the new network-manager package and most of my RPis are disappearing from the networks entirely or still just showing up with dhcp leased ip addresses.
Some of my older RPi's won't even run the new release.
This has been a total mess... anybody else been through this have some ideas?
So, where on this page: https://www.screenly.io/ose/#upgrade does it link to release notes or even indicate which version thevpetersson wrote: ↑Tue Jan 30, 2018 8:04 amIf you're using your Screenly OSE devices in a commercial environment like that, I strongly recommend that you read all the release notes (which can be found here https://github.com/Screenly/screenly-ose/releases) prior to upgrading your devices such that you can plan it upgrades accordingly.
Code: Select all
$ bash <(curl -sL https://www.screenly.io/install-ose.sh)
That script will always upgrade to the latest stable relase.
The Raspberry Pi is a hardware platform. Education is one use case (which the Foundation is passionate about), but hardly the only which is evident by this forum and ecosystem at large.mchlwllmthms wrote: ↑Thu Feb 08, 2018 6:10 pmSomething you all need to keep in mind is that the raspberry pi is still an educational platform with a lot of inexperienced users and we're not all devs who know how to navigate all the ins and outs of releases and resin and docker and reverse proxies and source codes and github... OSE is an awesome product and has been very beneficial to us, but right now it's a mess for me even using the pre-configured custom images.
Networking is left untouched from upstream Raspbian (with exception of the WiFi captive portal). We have done this to ensure that we divert as little as possible in the networking stack. The only difference really is that we install Network Manager. Other than that, the upstream documentation for networking shall apply.mchlwllmthms wrote: ↑Thu Feb 08, 2018 6:10 pmSoooo.... you've gotten rid of screenly network manager so we're no longer setting static IP in the /boot/network.ini file... fine... I'd just gotten used to that, but I didn't like the implementation, so good. https://www.screenly.io/blog/2018/01/19 ... available/ says custom ethernet connection config should be done in /etc/network/interfaces, which only results in "unable to resolve local IP address" and no connection to network. /etc/network/interfaces header says "For static IP, consult /etc/dhcpcd.conf"... okay, so I can set static IP in dhcpcd.conf like I used to do? no problem. Revert the /etc/network/interfaces file and instead update dhcpcd.conf file with static IP settings -> nope, just a dhcp leased address. Again, this is using a custom OSE image downloaded from the Paradise City release entry on this page: https://github.com/screenly/screenly-ose/releases
If the image writing was successful and a laptop is on the same network as Pi, then everything should be in fine. Is the problem still urgent? Let's figure it out if that problem is not solved yet.
Excuse me for my quick question. the problem was that the format of my video was wrong. with a mp4 video all is goodvpetersson wrote: ↑Thu Mar 08, 2018 10:22 am
You'd have to be more specific than that. Normally it works out-of-the-box.
What exactly are you having issues with?
Hi, can you donithyadeepthi wrote: ↑Wed Mar 14, 2018 6:26 amHi ,
When I'm downloading a video through Screenly, I get this error sometimes 'Server Error: Command '['youtube-dl', '-e', u'https://www.youtube.com/watch?v=y7yvxdCU9Cg']' returned non-zero exit status 1'. Sometimes this gets fixed after a reboot, but the problem comes again.
Also, getting this error while trying to move an asset to the active list 'Server Error: Invalid file path. Failed to add asset. '
Have you ever experienced this problem. Could you please help me to sort this out?
This is the model I use: Raspberry Pi 3 Model B Rev 1.2
Code: Select all
sudo journalctl > foobar.txt
Stefan_Rasp wrote: ↑Sat Mar 24, 2018 2:38 pmHi Guys,
I'm new to Raspberry and Screenly, so I hope this isn't a stupid question.
I have worked on code and change something, and now I would like to try if the changes work on my Rasp.
My problem now is: how can I make a IMG bottable to run on Raspberry?
Thank you in advance
The resin-wifi-connect portal is mostly to help ‘common’ setups. For more ‘complicated’ setups (and I guess hidden SSIDs would fall into this bracket), you can still use a regular WiFi setup. In short, at boot resin-wifi-connect checks if there is an existing network connection. If there is one, it will simply skip that step.threepwood wrote: ↑Sun Apr 15, 2018 8:02 pmHi all,
I'm looking to configure Screenly for a hidden WiFi network and am failing via the new resin portal. We've previously configured this via wpa_supplicant.conf in older builds, but this no longer appears to work in the Paradise City release. Is there a way of configuring a connection to a hidden SSID via resin, or should I be going about this in a different way, please?
Many thanks in advance!
.For custom Ethernet configuration and advanced configurations, you can either use nmcli by hand on the device, or configure networking through /etc/network/interfaces
threepwood wrote: ↑Mon Apr 16, 2018 11:07 amThanks for your reply @vpetersson, much appreciated!
My findings from some testing -
If I place a populated wpa_supplicant.conf file into the boot partition of a plain stretch image, at first boot the Pi automatically connects to the hidden network without any additional configuration changes.
If I place the wpa_supplicant.conf file on the boot partition of the Screenly image, the wpa_supplicant.conf file gets placed into /etc/wpa_supplicant as expected, but WiFi does not connect - at first boot I see the portal page, advertising the temporary Screenly network for configuration. Ifconfig reports the Screenly IP address 192.168.42.x.
The blog page for the Paradise City release states.For custom Ethernet configuration and advanced configurations, you can either use nmcli by hand on the device, or configure networking through /etc/network/interfaces
My linux knowledge is pretty basic, so I'm learning as I go, but I have seen multiple references warning against editing /etc/network/interfaces as it's deprecated in Stretch. I have had success with nmcli but haven't worked out if this method will cause WiFi to auto-reconnect if the connection drops. If nmcli is the way to go with hidden SSIDs, that's absolutely no problem - my aim is to nail down a solid way of deploying a Pi running the latest and greatest Screenly build in a consistent manner.