Cyan Screen on Launch #516

Closed
opened 2017-08-30 09:11:19 +02:00 by gyroninja · 6 comments
gyroninja commented 2017-08-30 09:11:19 +02:00 (Migrated from github.com)

If you launch LBRY when your working directory isn't in lbry-app then the application says at a blank cyan screen.
My current work around is just creating a start script which changes the working directory to there and starts it up.

If you launch LBRY when your working directory isn't in lbry-app then the application says at a blank cyan screen. My current work around is just creating a start script which changes the working directory to there and starts it up.
tzarebczan commented 2017-08-30 09:28:13 +02:00 (Migrated from github.com)

What working directory are you referring to? Can you be more specific? I can provide a different solution tomorrow when I'm at my PC

What working directory are you referring to? Can you be more specific? I can provide a different solution tomorrow when I'm at my PC
gyroninja commented 2017-08-30 10:51:34 +02:00 (Migrated from github.com)

If you are running it via node_modules/.bin/electron app, you have to have your working directory be the root directory of the git repo. If you have packaged it up, you have to have your working directory be /dist/linux-unpacked.
This is likely due to it just not being able to find assets that it assume will be located in the working directory.
I don't really need a different solution, but would rather see this bug fixed.

If you are running it via `node_modules/.bin/electron app`, you have to have your working directory be the root directory of the git repo. If you have packaged it up, you have to have your working directory be `/dist/linux-unpacked`. This is likely due to it just not being able to find assets that it assume will be located in the working directory. I don't really need a different solution, but would rather see this bug fixed.
lyoshenka commented 2017-09-05 15:17:55 +02:00 (Migrated from github.com)

@gyroninja how are you packaging it? for the unpackaged version, it makes sense that this is a bug. for the packaged version, it should create an installable file (a .deb or .dmg or similar) that gets installed by the system. I'm not sure where /dist/linux-unpacked is coming from.

If you run node_modules/.bin/electron app but with full paths to the binary and the app dir, does this bug still happen? If it's just about relative paths in the command, its easy to fix. If the paths are absolute and it still errors, then its something we need to fix in electron.

@gyroninja how are you packaging it? for the unpackaged version, it makes sense that this is a bug. for the packaged version, it should create an installable file (a .deb or .dmg or similar) that gets installed by the system. I'm not sure where /dist/linux-unpacked is coming from. If you run `node_modules/.bin/electron app` but with full paths to the binary and the app dir, does this bug still happen? If it's just about relative paths in the command, its easy to fix. If the paths are absolute and it still errors, then its something we need to fix in electron.
gyroninja commented 2017-09-06 12:23:06 +02:00 (Migrated from github.com)

I don't know how many times I need to explain it when it is so simple.
No, I'm not installing it from a dpkg.
dist/linux_unpacked is created when it creates the package
Whether the command uses full or relative paths doesn't matter.

Like I have said in every post so far, the bug is from having the wrong working directory. The bug very likely stems from using a resource that it assumes exists it the working directory. Since the working directory is not where it is expected, it can not find the resource and hence fails to load.

I don't know how many times I need to explain it when it is so simple. No, I'm not installing it from a dpkg. dist/linux_unpacked is created when it creates the package Whether the command uses full or relative paths doesn't matter. **Like I have said in every post so far, the bug is from having the wrong working directory. The bug very likely stems from using a resource that it assumes exists it the working directory. Since the working directory is not where it is expected, it can not find the resource and hence fails to load.**
lyoshenka commented 2017-09-06 14:22:54 +02:00 (Migrated from github.com)

I was asking because I'm having trouble reproducing this. I've never seen the linux_unpacked dir and I don't know how it is created. It would be helpful if we knew what OS you're on and what commands you ran. It would be even more helpful if you submit a PR fixing this issue. We're happy to tip LBC for dev work. 😄

I was asking because I'm having trouble reproducing this. I've never seen the `linux_unpacked` dir and I don't know how it is created. It would be helpful if we knew what OS you're on and what commands you ran. It would be even more helpful if you submit a PR fixing this issue. We're happy to tip LBC for dev work. :smile:
gyroninja commented 2017-09-10 06:59:41 +02:00 (Migrated from github.com)

Okay, I went ahead and diagnosed and resolved the issue I was getting. You were probably having issues reproducing this because the code which caused this error was being avoided. (There was a return inserted to the beginning of the function which errors to temporarily disable it)

Okay, I went ahead and diagnosed and resolved the issue I was getting. You were probably having issues reproducing this because the code which caused this error was being avoided. (There was a return inserted to the beginning of the function which errors to temporarily disable it)
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: LBRYCommunity/lbry-desktop#516
No description provided.