search

Dusk-Labs / dim

Dim, a media manager fueled by dark forces.
GNU Affero General Public License v3.0
3.78k stars 159 forks source link

Various hazard trying to build #232

Open jobs62 opened 2 years ago

jobs62 commented 2 years ago

Hi, i love the project, but i had some issues to build it on my own i want to share if it can help some. I build without docker since i don't have nor like it, so some of it may come from that.

1) ffmpeg path are hardcoded (and non system standard) in dim/src/streaming/mod.rs 2) the database is not build on is own, so need to cat database/migrations/*.sql | sqlite3 dim_dev.db (i may have been warn before) 3) building the ui doesn't like node 17 (to be fair not your problem) 4) compile release build take an absurde amount of ram, and is triggering oom on my 8G system. (debug is fine)

keep the good work, cheerz

eraychumak commented 2 years ago

building the ui doesn't like node 17 (to be fair not your problem)

There was a PR merged that updated node-sass to v6 which is not yet supported for node 17, if that's not the case, may you elaborate?

mental32 commented 2 years ago
  1. ffmpeg path are hardcoded (and non system standard) in dim/src/streaming/mod.rs

it's not designed to be system standard, we're planning on building and shipping ffmpeg releases with extra stuff linked in for hardware accelerated transcoding.

  1. the database is not build on is own, so need to cat database/migrations/*.sql | sqlite3 dim_dev.db (i may have been warn before)

The database and migrations should be all created during the first run so I'm not sure what's happened to you here, could you elaborate more on that?

  1. compile release build take an absurde amount of ram, and is triggering oom on my 8G system. (debug is fine)

Yeah we don't really have any control over that at the moment, we're left to the mercy of the rustc compliler. I suggest using the docker builds for releases.

jobs62 commented 2 years ago

There was a PR merged that updated node-sass to v6 which is not yet supported for node 17, if that's not the case, may you elaborate? It's exactly the problem i had, but not being from a JS background it took me a while to debug

The database and migrations should be all created during the first run so I'm not sure what's happened to you here, could you elaborate more on that? Well, the db was created at my first compilation attempt, but was empty. i'm not sure what happend. i may try again later from scratch to see if its reproductible.

jobs62 commented 2 years ago

OK so, i tried again to build from scratch with the same result (db empty), and i found why ! in dim/src/build.rs, the manifest path is defined as database/migrations/*.sql which is in a shell in extented to database/migrations/20210619211347_dim.sql BUT NOT whene passed as a argument directely to sqlite as in done in the build script. I guess the easiest fix whould to call /bin/sh to extend the path before executing. I hope it make sense.

vgarleanu commented 2 years ago

OK so, i tried again to build from scratch with the same result (db empty), and i found why ! in dim/src/build.rs, the manifest path is defined as database/migrations/*.sql which is in a shell in extented to database/migrations/20210619211347_dim.sql BUT NOT whene passed as a argument directely to sqlite as in done in the build script. I guess the easiest fix whould to call /bin/sh to extend the path before executing. I hope it make sense.

This sounds like a OS quirk, mind telling me what OS youre compiling dim on?

vgarleanu commented 2 years ago

OK so, i tried again to build from scratch with the same result (db empty), and i found why ! in dim/src/build.rs, the manifest path is defined as database/migrations/*.sql which is in a shell in extented to database/migrations/20210619211347_dim.sql BUT NOT whene passed as a argument directely to sqlite as in done in the build script. I guess the easiest fix whould to call /bin/sh to extend the path before executing. I hope it make sense.

We should definitely hardcode the paths to the migrations in the build script without the wildcard match.

jobs62 commented 2 years ago

OK so, i tried again to build from scratch with the same result (db empty), and i found why ! in dim/src/build.rs, the manifest path is defined as database/migrations/*.sql which is in a shell in extented to database/migrations/20210619211347_dim.sql BUT NOT whene passed as a argument directely to sqlite as in done in the build script. I guess the easiest fix whould to call /bin/sh to extend the path before executing. I hope it make sense.

This sounds like a OS quirk, mind telling me what OS youre compiling dim on?

i'm on Debian 10.11

OK so, i tried again to build from scratch with the same result (db empty), and i found why ! in dim/src/build.rs, the manifest path is defined as database/migrations/*.sql which is in a shell in extented to database/migrations/20210619211347_dim.sql BUT NOT whene passed as a argument directely to sqlite as in done in the build script. I guess the easiest fix whould to call /bin/sh to extend the path before executing. I hope it make sense.

We should definitely hardcode the paths to the migrations in the build script without the wildcard match.

that would not be very future proof. would you like me to try to patch it and see if it work for you ?

jobs62 commented 2 years ago

https://github.com/jobs62/dim/commit/545c1271aba6ffe042a1bbf36a0bbbd9a63def4e

here we go if you want

based-template commented 2 years ago
  1. ffmpeg path are hardcoded (and non system standard) in dim/src/streaming/mod.rs

it's not designed to be system standard, we're planning on building and shipping ffmpeg releases with extra stuff linked in for hardware accelerated transcoding.

Even though I really don't know what you have these binary paths hard-coded instead of read from the environment (as you do with 'db_url', it really would be nice if you would mention that if you're going to build from source, you need to have the ffmpeg and ffprobe executables located in the appropriate locations as per the hard-coded references