Problems getting the latest dev version to run on Windows

[Dola-Shuvi]

Good day,

Recently the way to launch the development version of nuclear has been changed to using Docker. While Docker certainly is very useful on Linux it's causing me some major headaches on Windows. Here are some of the problems I'm facing currently:

• Docker on Windows and Mac is behind a login wall and can only be accessed via a direct link or an external package manager. This is especially annoying as signing up isn't even required to run Docker.

• Docker and VirtualBox are incompatible as Docker requires Hyper-V to be enabled which breaks VirtualBox. I require VirtualBox to work on cross-platform compatibility for one of my own projects. This forced me to use Docker-Toolbox which uses VirtualBox for its virtualization.

• Incredibly slow setup/build times. This image speaks for itself.

• Errors everywhere. This is a log after running docker-compose up dev when the initial setup and errors are done.

Here is some additional information on my Docker environment. Perhaps anyone can see something wrong with it. If possible a way to run the development version without needing docker would be very appreciated.

[nukeop]

The old way of running the dev environment is still available, it's just no longer mentioned in the readme. Perhaps it should. The only thing that's different is that lerna needs to bootstrap the packages.

For reference:

$ npm i -g lerna # or use locally installed lerna with npx
$ lerna bootstrap
$ cd packages/app
$ npm run:watch
$ npm run electron:dev # in another console window

I took care to ensure that the program still builds on all platforms despite the architecture changes. Well, at least it does in CI (Travis and Github action).

[nukeop]

Btw, no need to wait that long. It should run in seconds. If it doesn't, let me know immediately. The CI tests and builds the whole program within 5 minutes and that's on small machines and including startup times.

[Dola-Shuvi]

Thanks for the quick reply! Great to hear that the old way of running is still present. Everything except running npm run watch seems to work fine. It throws this error, complains about fonts and fails to compile. Other times it simply gets stuck around ~67% of the module building step.

[nukeop]

Nice catch. I fixed this earlier on production config but forgot to do it for dev. Pull the newest commit and it should work for you now.

[Dola-Shuvi]

That commit did indeed fix the dev version. It launched within 20 seconds. There does seem to be an error related to LastFM somewhere though that keeps the app from running properly.

[nukeop]

Yeah, looks like I didn't think of everything. It might be a bit unstable for the next few days while I'm working out how to integrate the formerly separate packages back. I will try to fix this today but there might be more problems.

[Dola-Shuvi]

Things like this happen sometimes when restructuring projects at this scale. I'll try finding any major issues within the next few days and once it has somewhat stabilized we can close this.

I can also confirm above error on Linux.

[nukeop]

Nice, thank you for the help.

[nukeop]

Most of the problems should be gone now. There are still some minor issues connected to queue items but they mostly affect displaying e.g. loading state and the main functionality should be intact. Let me know and reopen if there's still something wrong on your end.

[Dola-Shuvi]

Running the dev version works perfectly now. The only issues I found so far are:

1. A crash from removing a track from the queue Log Fixed

2. Local library not loading thumbnails (this has happened since a while ago but I cant remember around when it started) Image

3. Using the current track menu in the queue to add a song to a playlist duplicates said playlist and makes it undeletable while also adding the first song in queue instead of the currently playing one Log

4. Using the current track menu in the queue to download a song causes the first song in the queue to download instead of the current one

5. I can also confirm #385. This along with 3. and 4. should be caused by the same problem as they are very similar. I can not confirm that this is caused by autoradio.

6. And #377 which is also the cause for #466

Also sometimes webpack hangs at around 67% when building modules but a simple restart of npm run watch fixes that and seems to be caused by webpack.

I should have probably opened a new issue for some of these.

[nukeop]

Number 1 is fixed

[Dola-Shuvi]

Works like a charm! I did notice however that we are currently exceeding the YouTube api quota. Roughly 41% of requests for streams failed when I tried to load up a playlist. Once I switched to my own API key that went away. If the userbase grows further an upgrade of the quota might be required unless people start using their own keys.

[nukeop]

I'll keep this in mind. I'll look at the other items today after work and see what we can do about them.

[nukeop]

Can't reproduce the first half of number 3, but I did reproduce and fix the problem with the first item of the queue being incorrectly passed as the current item. So I guess number 4 is taken care of as well.

Maybe you could provide your config json? At least the part with the playlists.

[Dola-Shuvi]

Issue 3 seems to be caused by playlists using the older format without a UUID. Only those were affected. After generating new UUIDs and manually editing the config everything works now. Perhaps checking if playlists have a UUID and generating a new one if they don't could be a solution.

With commit f43012b3aa6e26e549d23d1173f29c329a6b8db4 issue 3, 4 and 5 can be considered solved. All of those work as intended on my end.

[nukeop]

Good, I'll keep this open for a while to track the rest.

[Dola-Shuvi]

Closing this as all problems listed above were fixed.