could not compile rocket_http

[eisengrau]

Hello,

I wanted to try out this under Debian Buster (in an LXC container, but that doesn't really matter I suppose...), and got the following fail message:

error: proc macro panicked
--> /root/.cargo/registry/src/github.com-1ecc6299db9ec823/rocket_http-0.4.5/src/parse/uri/parser.rs:119:34
|
119 | let path_and_query = pear_try!(path_and_query(is_pchar));
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
= help: message: called Option::unwrap() on a None value
= note: this error originates in a macro (in Nightly builds, run with -Z macro-backtrace for more info)

error: aborting due to previous error

error: could not compile rocket_http.

To learn more, run the command again with --verbose.
warning: build failed, waiting for other jobs to finish...
error: build failed
make: *** [Makefile:7: build] Error 101

Rust is nightly (installed as per your recommended command):

curl https://sh.rustup.rs -sSf | sh -s -- --default-toolchain nightly

Thank You!

[lnicola]

See #84.

[eisengrau]

Hello Laurentiu,

That was quick, thank you! I ave also noticed the issue, right after i submitted this. I tried running

cargo update -p pear

which got me

Updating crates.io index
Updating pear v0.1.2 -> v0.1.4

Also I have rm -r'd the whole polaris directory, untar'd the source again, and run make install. I got the same error unfortunately :/

Is there a step that I have missed?

[lnicola]

Ah, you also need to update pear_codegen.

[eisengrau]

Awesome, that did the trick! Of course, one should disregard my previous reply about deleting the source folder, since pear and pear_codegen is updated IN that folder before running make.

At the moment it is indexing my (200.000+) music collection, but using around 3,5% CPU only for this... I'll check how it will work around.

[lnicola]

Is that 3.5% of a single CPU or 3.5% overall? I think indexing is kinda' single-threaded, and combined with slow IO like an HDD it's going to take a while.

[eisengrau]

It is 3,5% out of 4 CPU cores allocated to the LXC container (out of 4 physical cores). I have now allocated 2 cores, this time the usage is around average 5%-9%. Guess it depends on the files.

I have tried quite a lot of streaming servers, and I noticed that they are struggle with the indexing of such a large collection (99% mp3's, 1% others, no album art).

The only streaming solution that is fast at this is airsonic (subsonic), which I currently use, and plan to phase out. Of course that piece of software is heavyweight compared to anything else (JRE/Tomcat), it's not in comparison terms of resource usage.

Nevertheless I'll wait until the full directory structure will appear under the GUI, and we'll see. I have also installed the app on my mobile device and looks promising! I presume I'm not the only one open to new personal streaming solutions that are alternative to subsonic.

[agersant]

Thank you @lnicola for providing good support!

[agersant]

@eisengrau I'm always interested in getting feedback from new users so please feel free to open more issues for bugs, suggestions or other thoughts.

As a side note, the indexing by Polaris is orders of magnitude faster if your mp3 files have a Xing header specifying song duration. Without it, we need to do a lore more I/O to determine song durations.

[eisengrau]

Apreciate it guys! I closed this, since the original issue about not compiling was resolved, and I didn't want to get this lost, if someone else might have this too... @agersant

[agersant]

Fixed in #86