profile
viewpoint
If you are wondering where the data of this site comes from, please visit https://api.github.com/users/aljungberg/events. GitMemory does not store any data, but only uses NGINX to cache data for a period of time. The idea behind GitMemory is simply to give users a better reading experience.
Alexander Ljungberg aljungberg SlevenBits Ltd. London, UK http://www.slevenbits.com

aljungberg/pyle 14

Use Python for sed like shell one-liners.

aljungberg/LPKit 12

A collection of generic views, controls & utilities for Cappuccino.

aljungberg/deepDropUpload 9

Example for dragging files from the desktop to any CPView in a Cappuccino app running in a browser.

aljungberg/hhc 9

The most compact way to express a number in a URL.

aljungberg/cappbot 7

A bot to augment GitHub issues with lifecycle automation, paper trail, issue state, voting, and to make GitHub pull requests equivalent to full issues.

aljungberg/Cappuccino-datepicker 6

A cappuccino implementation of NSDatePicker

aljungberg/cappuccino 5

Web Application Framework in JavaScript and Objective-J

aljungberg/cappuccino-timeago 4

Convert dates to strings such as "14 minutes ago". Port of jQuery's timeago plugin for Cappuccino.

aljungberg/aristo 3

Aristo Artwork Files

aljungberg/Revetment 3

Extra secure, encrypted, deduplicated, compressed backups against any SFTP (SSH) host.

issue commentScreenly/screenly-ose

Screenly-Ose running on Balena - after upgrade asset not showing

Just linking to this same issue on the balena forum for reference https://forums.balena.io/t/screenly-ose-running-on-balena-after-upgrade-asset-not-showing/264521

jtinfotv

comment created time in 21 hours

issue commentcappuccino/cappuccino

macOS 11 Will Not Launch Unsigned ARM Binaries

Milestone: Someday. Label: tools. What's next? A reviewer should examine this issue.

enquora

comment created time in 4 days

issue commentcappuccino/cappuccino

"LIKE" Predicate Operator Incorrectly Implemented

Milestone: Someday. Labels: #accepted, #needs-patch, Foundation. What's next? This issue needs a volunteer to write and submit code to address it.

aksuska

comment created time in 4 days

issue commentcappuccino/cappuccino

Async/await syntax

Milestone: Someday. Label: Objective-J. What's next? A reviewer should examine this issue.

OCTAGRAM

comment created time in 4 days

issue commentcappuccino/cappuccino

steps to add node support are not working

Milestone: Someday. Label: tools. What's next? A reviewer should examine this issue.

bamwu

comment created time in 4 days

issue commentcappuccino/cappuccino

A CPBox containing a CPColorWheel fails nib2cib conversion

Milestone: Someday. Labels: #needs-patch, tools. What's next? This issue needs a volunteer to write and submit code to address it.

cacaodev

comment created time in 4 days

issue commentcappuccino/cappuccino

nib2cib incompletely converts NSImageView instances

Milestone: Someday. Labels: #needs-info, tools. What's next? Additional information should be added as a comment to this isuse.

enquora

comment created time in 4 days

pull request commentcappuccino/cappuccino

removed: Flash support

@mrcarlberg flash is removed from the major browsers. can we move this forward?

daboe01

comment created time in 4 days

issue commentcappuccino/cappuccino

macOS 11 Will Not Launch Unsigned ARM Binaries

-#new +tools

enquora

comment created time in 4 days

issue commentcappuccino/cappuccino

"LIKE" Predicate Operator Incorrectly Implemented

-#new +Foundation +#needs-patch +#accepted

aksuska

comment created time in 4 days

issue commentcappuccino/cappuccino

Async/await syntax

-#new +Objective-J

OCTAGRAM

comment created time in 4 days

issue commentcappuccino/cappuccino

steps to add node support are not working

-#new +tools

bamwu

comment created time in 4 days

issue commentcappuccino/cappuccino

A CPBox containing a CPColorWheel fails nib2cib conversion

-#new +tools +#needs-patch

cacaodev

comment created time in 4 days

issue commentcappuccino/cappuccino

nib2cib incompletely converts NSImageView instances

-#new +tools +#needs-info

enquora

comment created time in 4 days

issue openedScreenly/screenly-ose

Screenly-Ose running on Balena - after upgrade asset not showing

Hi

I have run Screenly Ose on Balena succesfully earlier. Now I upgraded to release 61cb3e6. Upgrading went well and all assets ( web pages, jpg images, videos and youtube videos) are running correctly but one asset ( https://yle.idid.fi ) is showing white page and log shows this image image unable to get git branch and latest version from github

Then I flashed only screenly ose to memorycard and that page is working correctly on that but not with balena.

I have new class 10 fast memorycard…

So any help where might be the problem in Balena

Environment

  • Raspberry Pi Hardware Version: Pi3+
  • Raspberry Pi Network Setup: built-in WiFi
  • Screenly OSE Version: N/A

created time in 4 days

issue commentcappuccino/cappuccino

Autoresizing masks of CPBox subviews are ignored after running nib2cib

Milestone: Someday. Labels: #accepted, regression. What's next? A reviewer should examine this issue.

cacaodev

comment created time in 6 days

issue commentcappuccino/cappuccino

Key Path Operators Not Supported on Child Key Path

Milestone: Someday. Label: #new. What's next? A reviewer should examine this issue.

aksuska

comment created time in 6 days

issue openedcappuccino/cappuccino

Key Path Operators Not Supported on Child Key Path

At least when loaded from cib, the following key path generates an exception: collectionKeyPath.@sum.valueKeyPath but this usage is canonical in Objective-C. The error is "CPInvalidArgumentException: [CPArray addObserver:forKeyPath:options:context:] is not supported." In this case, the KVC implementation should ignore the intermediate observation as the preceding key should always produce an array (or set if you support those operators, but same issue).

created time in 6 days

issue commentScreenly/screenly-ose

cant connect via browser when in a network without internet access

@iDazai

Ok, lets get the docker stuff out of the way in a very simplified way:

  • docker in general needs internet to pull images from dockerhub (ex: FROM balenalib/rpi-raspbian:buster)
  • docker-compose allows you to create these containers based on images and customize with YAML files (ex: Dockerfile.viewer)

If you look over the script, lets look at these lines:

sudo -E docker-compose \
    -f /home/pi/screenly/docker-compose.yml \
    -f /home/pi/screenly/docker-compose.override.yml \
    pull

sudo -E docker-compose \
    -f /home/pi/screenly/docker-compose.yml \
    -f /home/pi/screenly/docker-compose.override.yml \
    up -d

What this is doing is saying ok docker-compose i want you to use this file (hence the -f reference) to build these containers. If you open up those .yml files, you can see what each one does, how it calls the dockerfiles to build the containers, etc. You can get a pretty good idea just by looking them over. The first step is pulling these images, which if you dont have them locally, they go out to dockerhub registry to download them. The up step is just bringing them up (starting them up, like turning them on) and the -d flag just means do it in the background.

So, if you look at some of the files, for example nginx dockerfile needs alpine image, it is a very tiny image because the OS is very small, but it is running the nginx web server all on its own in that tiny image. Other images are being pulled from raspbian or even screenly. This is dockerhub screenly account which holds ready made and ready to pull images: https://hub.docker.com/search?q=screenly&type=image

Ok, so now that you have a little overview of what is going on, think about the process initially, you must have internet in order to get these images and build the containers. After they are locally stored and built, you are simply bringing them up. Maybe, in your specific offline situation, we simply need to comment out and skip the pulling part since they are already on the device, and just use the up -d section. This may work only if the original building of images and pulling etc was completed 100%, so if you type docker container ls -a this needs to show ALL containers required for screenly to function, these are:

  • screenly_srly-ose-server_1
  • screenly_redis_1
  • screenly_srly-ose-websocket_1
  • screenly_srly-ose-viewer_1
  • screenly_srly-ose-celery_1
  • screenly_srly-ose-nginx_1

Now, focus on that upgrade_containers.sh script, if you look it over, it simply gives the system the environment variables it needs for the screenly dockerfile to compose properly, such as the MY_IP, VIEWER_MEMORY..., DOCKER_TAG, etc.. any of the export variables. Ok, so then we already know that when the Pi is offline, we need the MY_IP env variable so this is when you need an active network device that will respond to that route command so that the MY_IP ends up with the default IP address of the Pi, and passes that on to the container. This is the tricky part though, remember we skipped the "pulling" of the images, if you just bring the images up, and nothing is changed, the MY_IP variable wont get the new offline IP, so this is where your testing happens because I dont have an offline network to be testing all this but simply know how it should theoretically work. The reason the pull should work, is because the images are offline and locally downloaded so the device no longer needs to go out to the internet to get them, so one important step is that we need the containers now to have the new modified IP address that you gave it through the script. So, in general, as I tested, if you do everything properly to begin with, and end up with a working screenly-ose, pulling the device offline would still allow it to work, you just need a way to get that new IP address to show on the splash screen after it has been put offline, which is completely doable, again, just trial and error for the specific steps are on your end.

I am not an expert on the inner workings and all of the CLI of docker and docker-compose, but I hope I gave you an idea of how it is all put together in an overview way.

So, in the end you write about seeing the new internet offline IP address, do you sort of understand now why the splash screen showed this IP after running the rebuild script?

magno23

comment created time in 8 days

issue commentScreenly/screenly-ose

cant connect via browser when in a network without internet access

I did it exactly as you described. New SD card, latest Raspbian OS lite, bash install, restart. After that restart, while still on the internet, I can't access that srly-ose-nginx site. I download the upgrade_containers.sh change it to my internal DNS server and connect to the no internet subnet. I have an internal IP, can ping the DNS from the Pi, but somehow SSH is disabled. So I have to bring up the console on the pi (which I shouldn't be able to, according to another issue) and execute bash upgrade_containers.sh (also tried it after stopping all containers) and I get this:

`Pulling redis ... error Pulling srly-ose-server ... error Pulling srly-ose-websocket ... error Pulling srly-ose-nginx ... error Pulling srly-ose-celery ... error Pulling srly-ose-viewer ... error

ERROR: for srly-ose-websocket Get https://registry-1.docker.io/v2/: read tcp 192.168.10.175:58920->23.22.155.84:443: read: connection reset by peer ERROR: for redis Get https://registry-1.docker.io/v2/: read tcp 192.168.10.175:58914->23.22.155.84:443: read: connection reset by peer ERROR: for srly-ose-celery Get https://registry-1.docker.io/v2/: read tcp 192.168.10.175:58918->23.22.155.84:443: read: connection reset by peer ERROR: for srly-ose-viewer Get https://registry-1.docker.io/v2/: read tcp 192.168.10.175:50422->52.55.168.20:443: read: connection reset by peer ERROR: for srly-ose-nginx Get https://registry-1.docker.io/v2/: read tcp 192.168.10.175:58916->23.22.155.84:443: read: connection reset by peer ERROR: for srly-ose-server Get https://registry-1.docker.io/v2/: read tcp 192.168.10.175:58922->23.22.155.84:443: read: connection reset by peer ERROR: Get https://registry-1.docker.io/v2/: read tcp $RPi:58920->23.22.155.84:443: read: connection reset by peer Get https://registry-1.docker.io/v2/: read tcp $RPi:58914->23.22.155.84:443: read: connection reset by peer Get https://registry-1.docker.io/v2/: read tcp $RPi:58918->23.22.155.84:443: read: connection reset by peer Get https://registry-1.docker.io/v2/: read tcp $RPi:50422->52.55.168.20:443: read: connection reset by peer Get https://registry-1.docker.io/v2/: read tcp $RPi:58916->23.22.155.84:443: read: connection reset by peer Get https://registry-1.docker.io/v2/: read tcp $RPi:58922->23.22.155.84:443: read: connection reset by peer screenly_srly-ose-server_1 is up-to-date screenly_redis_1 is up-to-date screenly_srly-ose-websocket_1 is up-to-date screenly_srly-ose-viewer_1 is up-to-date screenly_srly-ose-celery_1 is up-to-date 7222a1843721_screenly_srly-ose-nginx_1 is up-to-date`

You said that this script should be run offline, can you tell my why it tries to communicate with a public ip address then? Get https://registry-1.docker.io/v2/: read tcp $RPi:58914->**23.22.155.84**:443: read: connection reset by peer

Another weird thing I noticed. After I ran the update_container.sh with the internal DNS configured and then changed to the internet subnet again and I ran the rebuild_container.sh. Suddenly, I saw the Screenly splash screen with the internal IP (with no internet access). Hard for me to grasp the inner workings of it...

magno23

comment created time in 8 days

issue commentScreenly/screenly-ose

Feature Request: ADD CEC Control...

Calling for testers on this. I've written a script that gathers some diagnostics that will help us assess how well CEC is implemented across monitors.

To participate, please take the following steps:

  • Run $HOME/screenly/bin/run_upgrade.sh and select the developer version
  • Run $HOME/screenly/bin/cec_test.sh and post the result

count on me, already installing, will post the results ASAP

unmanagedtn

comment created time in 8 days

fork manyoo/Polyskel-Swift

Straight Skeleton algorithm, ported to Swift from the Polyskel Python library

fork in 9 days

issue commentScreenly/screenly-ose

cant connect via browser when in a network without internet access

@magno23 , I experienced the same but it was because after the reboot of the Pi, the device and containers had not all fully loaded and the cache on the browser was not letting static data get updated, I simply opened up an incognito window and everything showed properly fine. Also, yes I thought about it and it all makes sense now with regards to the problem and the solution for offline is to build the containers in the way I suggested.


@iDazai Since you said you had a new SD card I assume it was a fresh install of Raspian OS lite, and thus you essentially ran the bash install script and indeed got all the latest files from the repo, so after this completes I assume you restarted the Pi, this needs to happen so that system properly finishes installation. If you reboot the Pi, then waited until everything loaded and tested it was working while on the network with internet access, then you would have shut it down, moved it over to the offline network (still need dhcp/dns on that offline network), then edited the upgrade_containers.sh script to include the gateway/router IP address instead of google's, then after this completes and you should have restarted the Pi and it would have worked. If you are getting container errors, I would first stop all containers: docker container stop $(docker container ls -aq) then, if that fails or gives an error, I would restart the docker service which in the past has fixed any errors for me when trying to deal with docker: sudo systemctl restart docker.service then after that finishes restarting the docker service and you are back at console prompt, try to run the edited upgrade_containers.sh script again and see if this time it works and you get the new offline network IP address which would then properly show the IP on the splash screen upon reboot and pass the routes to each container and all should work offline.`

magno23

comment created time in 9 days

issue commentScreenly/screenly-ose

cant connect via browser when in a network without internet access

I did it on a new sd card just now. This time it didn't take long on installing docker and during the installation I already saw the screenly splash screen with the IP address (on the internet subnet). What I experienced though, is that the response of the RPi is super slow. For example after a ping I can't type in another command because it seems like it didn't finish that process. CTRL+C doesn't help either.

After some time I got this error on the RPi: The server encountered an internal error and was unable to complete your request. Either the server is overloaded or there is an error in the application.

After another SD card flash, changed my keyboard layout, installed fail2ban, etc... I put it on the subnet without internet access. Previously I downloaded the upgrade_containers.sh and changed the DNS-Server, but I got the following error:

Error response from daemon: Cannot restart container 7825aa791bf1: driver failed programming external connectivity on endpoint screenly_srly-ose-nginx_1 (327f5b5031a5b312520a490677c17f54593746c02d4c8fc5703e3c7f9172e53b): Bind for 0.0.0.0:80 failed: port is already allocated

Some other remarks: The Image screenly/srly-ose-viewer:latest-pi4 always restarts. I can ping the DNS from the pi. 1st time I could connect via SSH. After a reboot I couldn't anymore. After another reboot I was able to SSH into it again.

I don't know what else I'm supposed to just make it work.

magno23

comment created time in 9 days

issue commentScreenly/screenly-ose

cant connect via browser when in a network without internet access

@ealmonte32 i think you are close to a solution I did what you said, connect the Pi to the internet and ran rebuild_containers.sh no errors, then connected the Pi to my network with no internet access and ran 'upgrade_containers.sh' with '8.8.8.8' replaced for my DNS server Now when i boot screenly it shows the screen with the IP to mage content and after a couple of secconds my page is displayed as intended. If i connect via browser from my computer this is the page that i get this page1 if i go for example into settings and then again to schedule overview, the page show like this page2

magno23

comment created time in 9 days

issue commentScreenly/screenly-ose

Screen going black

@shaqaruden The final code I wrote on the post above should be 100% good to go, you should not need to lower the soft limit to 50%, you can put it back to 75%, 50% might be too low.

shaqaruden

comment created time in 10 days

issue commentScreenly/screenly-ose

Screen going black

I am testing this on one Pi for now. I set my soft limit to 0.50 and left the hard limit @ 0.90. I have applied the code and restarted and so fa so good.

Thanks @ealmonte32

shaqaruden

comment created time in 10 days

issue commentScreenly/screenly-ose

cant connect via browser when in a network without internet access

*** Update & possible solution***

I just realized something after posting the above.. I was looking at some error I was getting on one of the containers and going through my troubleshooting I realized, the first "URL" the viewer tries to open is the local hostname of the container, for example below is what happens when you restart the viewer container and you have lets say one asset to load, in this example I have the screenly weather widget URL:

Loading browser...
Generating asset-list...
Current url is http://srly-ose-nginx:80/splash-page
Current url is http://srly-ose-nginx:80/static/img/loading.png
Showing asset https://weather.srly.io?lang=en&24h=0&wind_speed=0 (webpage)
Current url is https://weather.srly.io?lang=en&24h=0&wind_speed=0
Sleeping for 60

As you can see, the URL the Pi is the local hostname of the container at that moment, but that made me realize, when you move the Pi from your network with internet, to the network without internet, the IP changes, your whole DNS and DHCP stuff changes, but the containers were made with the old IP info.

This also reminds me, if you run the rebuild_containers.sh that has to be done with the device on the internet network.

Then, after you do that and all containers are 100% latest and online and working, when you move it to the network without internet, you need to run the other non-image-rebuilding script: https://raw.githubusercontent.com/Screenly/screenly-ose/master/bin/upgrade_containers.sh

Which you then need to replace the 8.8.8.8 IP with the IP of your local DNS/gateway/router so that the new local IP of the Pi gets inserted into this container building, so instead of 8.8.8.8 on this script, use your 10.213.8.254 which will allow the route to go through and pick up the local IP of the Pi since it is not needed to go out to google's DNS but rather locally on your subnet.. get me?

This whole thing is pretty much a networking situation that you need to go piece by piece and pick up the areas where offline and containers already built conflict..

magno23

comment created time in 10 days

issue commentScreenly/screenly-ose

cant connect via browser when in a network without internet access

Ok, just a few thoughts:

Based on your pastebin data, you dont seem to have the screenly/srly-ose-nginx:latest container up and running, this is what runs as the web server, thus serving the data, this is not to be confused with the srly-ose-server container. If your nginx container is not running, this explains why you cannot reach the IP address of the Pi.

<br> Then, this container below was restarting after all the others were online for 8 minutes, did you do that intentionally through docker container restart, because if you didnt, then the logs would show what error is causing the container to not start:

0d370b610168 screenly/srly-ose-viewer:latest-pi4 "/usr/bin/entry.sh b…" 25 minutes ago Restarting         screenly_srly-ose-viewer_1

To get logs from this specific container just type: docker container logs screenly_srly-ose-viewer_1 <br>

with regards to the nameserver/resolv.conf, I assume you are obfuscating this, but just to make sure, from the Pi, are you able to ping the name server? not from your PC, but from within the Pi itself, if you ssh into the Pi and from there try to ping your nameserver, which from your previous pastebin I believe your gateway for this was 10.213.8.254 , so I will assume this is the router/AP that does not have internet access, but this router/AP does need to have a route to the NTP server obviously so that from the Pi that is in this same network can access that route to would look something like: Pi --> (router/DEVICEACCESS AP) --> arp table contains address of NTP server thus Pi --> router --> NTP server

Does it look something like that?

magno23

comment created time in 10 days

issue commentScreenly/screenly-ose

cant connect via browser when in a network without internet access

@ealmonte32

I installed the latest Raspbian Lite from January 11th 2021. I also activated/installed SSH, VNC and fail2ban. Then I installed Screenly OSE with Dev/Master branch. No to the "manage your network" and "full system upgrade". This is what I saw after the installation:

20210224_094319

After first reboot I saw nothing. After second reboot I see the attached "Site can't be reached"

20210224_102556

I can also bring up the console. On another issue I saw that I shouldn't be able to do this? On some reboots it just shows me the screenly splash screen and then nothing else. When I bring up the console and I enter the user id, it won't jump to the password authentication. I can ping the pi on the internal network, but I can't connect to the web interface. It just says connection failed.

dockercontainer: https://pastebin.com/SenZ9Hyi resolv: https://pastebin.com/FTGNtxTs systemctl: https://pastebin.com/E1wM0Zys timesyncd: https://pastebin.com/RAXFW7Zr

I try to run the install script again and see if it changed something.

magno23

comment created time in 10 days